• "Jonathan M Davis" <jmdavisProg gmx.com> Feb 29 2012
• Jacob Carlborg <doob me.com> Feb 29 2012
• Mike Parker <aldacron gmail.com> Mar 01 2012
• Jacob Carlborg <doob me.com> Mar 01 2012
• =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> Mar 01 2012
• =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> Mar 01 2012
• Jonathan M Davis <jmdavisProg gmx.com> Feb 29 2012
• deadalnix <deadalnix gmail.com> Mar 01 2012
• =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> Mar 01 2012
• Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Mar 01 2012
• Jacob Carlborg <doob me.com> Mar 01 2012
• "Rene Zwanenburg" <renezwanenburg gmail.com> Mar 01 2012
• "Kapps" <opantm2+spam gmail.com> Mar 01 2012
• "Jonathan M Davis" <jmdavisProg gmx.com> Mar 01 2012
• "Martin Nowak" <dawg dawgfoto.de> Mar 01 2012

"Jonathan M Davis" <jmdavisProg gmx.com> writes:

package functions are currenly non-virtual.

The spec claims that "all non-sta­tic non-pri­vate non-tem­plate mem­ber
func­
tions are vir­tual," which would mean that package is supposed to be virtual. 
But from what I recall, the plan is to leave package as non-virtual. So, is 
that indeed the case and the spec needs to be fixed, or is package going to be 
made virtual at some point?

- Jonathan M Davis

Jacob Carlborg <doob me.com> writes:

On 2012-03-01 01:53, Jonathan M Davis wrote:
 package functions are currenly non-virtual.

 The spec claims that "all non-sta­tic non-pri­vate non-tem­plate mem­ber
func­
 tions are vir­tual," which would mean that package is supposed to be virtual.
 But from what I recall, the plan is to leave package as non-virtual. So, is
 that indeed the case and the spec needs to be fixed, or is package going to be
 made virtual at some point?

 - Jonathan M Davis


Is anyone even using "package"? I've basically never used it.

-- 
/Jacob Carlborg

Mike Parker <aldacron gmail.com> writes:

On 3/1/2012 4:26 PM, Jacob Carlborg wrote:
 On 2012-03-01 01:53, Jonathan M Davis wrote:
 package functions are currenly non-virtual.

 The spec claims that "all non-sta­tic non-pri­vate non-tem­plate
 mem­ber func­
 tions are vir­tual," which would mean that package is supposed to be
 virtual.
 But from what I recall, the plan is to leave package as non-virtual.
 So, is
 that indeed the case and the spec needs to be fixed, or is package
 going to be
 made virtual at some point?

 - Jonathan M Davis


 Is anyone even using "package"? I've basically never used it.


I use it. Primarily for utility declarations shared among modules, but 
not intended for the outside world. For example, DerelictGL's extension 
loader. Incidentally, before reading this I just finished refactoring 
another project to use some package-protected stuff. But I've never had 
a need (yet) to override anything with package protection outside of the 
same module.

Jacob Carlborg <doob me.com> writes:

On 2012-03-01 14:43, Mike Parker wrote:
 On 3/1/2012 4:26 PM, Jacob Carlborg wrote:
 On 2012-03-01 01:53, Jonathan M Davis wrote:
 package functions are currenly non-virtual.

 The spec claims that "all non-sta­tic non-pri­vate non-tem­plate
 mem­ber func­
 tions are vir­tual," which would mean that package is supposed to be
 virtual.
 But from what I recall, the plan is to leave package as non-virtual.
 So, is
 that indeed the case and the spec needs to be fixed, or is package
 going to be
 made virtual at some point?

 - Jonathan M Davis


 Is anyone even using "package"? I've basically never used it.


 I use it. Primarily for utility declarations shared among modules, but
 not intended for the outside world. For example, DerelictGL's extension
 loader. Incidentally, before reading this I just finished refactoring
 another project to use some package-protected stuff. But I've never had
 a need (yet) to override anything with package protection outside of the
 same module.


I see, I see. I guess it's more used in Java because it's the default.

-- 
/Jacob Carlborg

=?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:

On 01-03-2012 08:26, Jacob Carlborg wrote:
 On 2012-03-01 01:53, Jonathan M Davis wrote:
 package functions are currenly non-virtual.

 The spec claims that "all non-sta­tic non-pri­vate non-tem­plate
 mem­ber func­
 tions are vir­tual," which would mean that package is supposed to be
 virtual.
 But from what I recall, the plan is to leave package as non-virtual.
 So, is
 that indeed the case and the spec needs to be fixed, or is package
 going to be
 made virtual at some point?

 - Jonathan M Davis


 Is anyone even using "package"? I've basically never used it.


I use it. It's useful when you wish to create higher-level wrappers 
around stuff. (Interestingly, I only ever use package for constructors.)

-- 
- Alex

=?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:

On 01-03-2012 11:34, Rene Zwanenburg wrote:
 On Thursday, 1 March 2012 at 07:45:24 UTC, Jonathan M Davis wrote:
 On Thursday, March 01, 2012 08:26:00 Jacob Carlborg wrote:
 On 2012-03-01 01:53, Jonathan M Davis wrote:
 package functions are currenly non-virtual.
 The spec claims that "all non-sta­tic non-pri­vate >




 func­ tions are vir­tual," which would mean that package > is


 be virtual. But from what I recall, the plan is to leave > package as
 non-virtual. So, is that indeed the case and the spec needs > to be


 or is package going to be made virtual at some point?
 - Jonathan M Davis




 Is anyone even using "package"? I've basically never used it.


 Well, it's the sort of thing that's more useful with larger programs,
 so I
 question how much it's being used, but it definitely can be useful.
 std.datetime will likely be using it in the near future, since I'm
 working on
 breaking it up into a package (leaving std.datetime to then import
 everything
 in the package).

 But regardless, it's currently broken:

 http://d.puremagic.com/issues/show_bug.cgi?id=143

 - Jonathan M Davis


 I agree, virtual package function would be nice. ATM, as a workaround we
 use a package function which forwards the call to a protected function,
 and give the constructors package protection so only classes in the same
 package can inherit from it. That works, but it's not perfect.


I'd go further and say that's completely ridiculous. The language should 
not impose such stupid semantics on you because of a visibility modifier.

-- 
- Alex

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Thursday, March 01, 2012 08:26:00 Jacob Carlborg wrote:
 On 2012-03-01 01:53, Jonathan M Davis wrote:
 package functions are currenly non-virtual.
=20
 The spec claims that "all non-sta=C2=ADtic non-pri=C2=ADvate non-te=




 func=C2=AD tions are vir=C2=ADtual," which would mean that package =




 be virtual. But from what I recall, the plan is to leave package as=




 non-virtual. So, is that indeed the case and the spec needs to be f=




 or is package going to be made virtual at some point?
=20
 - Jonathan M Davis


 Is anyone even using "package"? I've basically never used it.


Well, it's the sort of thing that's more useful with larger programs, s=
o I=20
question how much it's being used, but it definitely can be useful.=20
std.datetime will likely be using it in the near future, since I'm work=
ing on=20
breaking it up into a package (leaving std.datetime to then import ever=
ything=20
in the package).

But regardless, it's currently broken:

http://d.puremagic.com/issues/show_bug.cgi?id=3D143

- Jonathan M Davis

deadalnix <deadalnix gmail.com> writes:

Le 01/03/2012 01:53, Jonathan M Davis a écrit :
 package functions are currenly non-virtual.

 The spec claims that "all non-sta­tic non-pri­vate non-tem­plate mem­ber
func­
 tions are vir­tual," which would mean that package is supposed to be virtual.
 But from what I recall, the plan is to leave package as non-virtual. So, is
 that indeed the case and the spec needs to be fixed, or is package going to be
 made virtual at some point?

 - Jonathan M Davis


I think virtuality and package should have nothing to with one another. 
package is supposed ot express visibility, not change behavior.

=?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:

On 01-03-2012 11:12, deadalnix wrote:
 Le 01/03/2012 01:53, Jonathan M Davis a écrit :
 package functions are currenly non-virtual.

 The spec claims that "all non-sta­tic non-pri­vate non-tem­plate
 mem­ber func­
 tions are vir­tual," which would mean that package is supposed to be
 virtual.
 But from what I recall, the plan is to leave package as non-virtual.
 So, is
 that indeed the case and the spec needs to be fixed, or is package
 going to be
 made virtual at some point?

 - Jonathan M Davis


 I think virtuality and package should have nothing to with one another.
 package is supposed ot express visibility, not change behavior.


100% agree.

-- 
- Alex

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/1/12 10:12 AM, Alex Rønne Petersen wrote:
 On 01-03-2012 11:12, deadalnix wrote:
 Le 01/03/2012 01:53, Jonathan M Davis a écrit :
 package functions are currenly non-virtual.

 The spec claims that "all non-sta­tic non-pri­vate non-tem­plate
 mem­ber func­
 tions are vir­tual," which would mean that package is supposed to be
 virtual.
 But from what I recall, the plan is to leave package as non-virtual.
 So, is
 that indeed the case and the spec needs to be fixed, or is package
 going to be
 made virtual at some point?

 - Jonathan M Davis


 I think virtuality and package should have nothing to with one another.
 package is supposed ot express visibility, not change behavior.


 100% agree.


Same here, though importantly the compiler can use the information to 
optimize away virtuals that cannot be overridden.

Andrei

Jacob Carlborg <doob me.com> writes:

On 2012-03-01 11:12, deadalnix wrote:
 Le 01/03/2012 01:53, Jonathan M Davis a écrit :
 package functions are currenly non-virtual.

 The spec claims that "all non-sta­tic non-pri­vate non-tem­plate
 mem­ber func­
 tions are vir­tual," which would mean that package is supposed to be
 virtual.
 But from what I recall, the plan is to leave package as non-virtual.
 So, is
 that indeed the case and the spec needs to be fixed, or is package
 going to be
 made virtual at some point?

 - Jonathan M Davis


 I think virtuality and package should have nothing to with one another.
 package is supposed ot express visibility, not change behavior.


Currently we don't have a "virtual" keyword, meaning everything would 
need to be virtual.

-- 
/Jacob Carlborg

"Rene Zwanenburg" <renezwanenburg gmail.com> writes:

On Thursday, 1 March 2012 at 07:45:24 UTC, Jonathan M Davis wrote:
 On Thursday, March 01, 2012 08:26:00 Jacob Carlborg wrote:
 On 2012-03-01 01:53, Jonathan M Davis wrote:
 package functions are currenly non-virtual.
 
 The spec claims that "all non-sta­tic non-pri­vate 
 non-tem­plate mem­ber
 func­ tions are vir­tual," which would mean that package 
 is supposed to
 be virtual. But from what I recall, the plan is to leave 
 package as
 non-virtual. So, is that indeed the case and the spec needs 
 to be fixed,
 or is package going to be made virtual at some point?
 
 - Jonathan M Davis


 Is anyone even using "package"? I've basically never used it.


 Well, it's the sort of thing that's more useful with larger 
 programs, so I
 question how much it's being used, but it definitely can be 
 useful.
 std.datetime will likely be using it in the near future, since 
 I'm working on
 breaking it up into a package (leaving std.datetime to then 
 import everything
 in the package).

 But regardless, it's currently broken:

 http://d.puremagic.com/issues/show_bug.cgi?id=143

 - Jonathan M Davis


I agree, virtual package function would be nice. ATM, as a 
workaround we use a package function which forwards the call to a 
protected function, and give the constructors package protection 
so only classes in the same package can inherit from it. That 
works, but it's not perfect.

"Kapps" <opantm2+spam gmail.com> writes:

On Thursday, 1 March 2012 at 07:26:01 UTC, Jacob Carlborg wrote:
 On 2012-03-01 01:53, Jonathan M Davis wrote:
 package functions are currenly non-virtual.

 The spec claims that "all non-sta­tic non-pri­vate 
 non-tem­plate mem­ber func­
 tions are vir­tual," which would mean that package is 
 supposed to be virtual.
 But from what I recall, the plan is to leave package as 
 non-virtual. So, is
 that indeed the case and the spec needs to be fixed, or is 
 package going to be
 made virtual at some point?

 - Jonathan M Davis


 Is anyone even using "package"? I've basically never used it.


In a module based approach, it's not as useful. But for people 
who are more used to Java and C# and end up using mostly one 
file/module per class, it is indeed useful. I've never had nor 
saw a use for overriding a package member though. If there is, C# 
partially solves this by 'protected internal' where internal is 
essentially package; this allows it to be called as a package 
function but still be overridable and accessible from the 
inheriting class. I have found a few use cases for it, with a 
workaround of making a package function to call the protected 
function.

"Jonathan M Davis" <jmdavisProg gmx.com> writes:

On Thursday, March 01, 2012 21:19:04 Jacob Carlborg wrote:
 On 2012-03-01 14:43, Mike Parker wrote:
 On 3/1/2012 4:26 PM, Jacob Carlborg wrote:
 On 2012-03-01 01:53, Jonathan M Davis wrote:
 package functions are currenly non-virtual.
 
 The spec claims that "all non-sta­tic non-pri­vate non-tem­plate
 mem­ber func­
 tions are vir­tual," which would mean that package is supposed to be
 virtual.
 But from what I recall, the plan is to leave package as non-virtual.
 So, is
 that indeed the case and the spec needs to be fixed, or is package
 going to be
 made virtual at some point?
 
 - Jonathan M Davis


 Is anyone even using "package"? I've basically never used it.


 I use it. Primarily for utility declarations shared among modules, but
 not intended for the outside world. For example, DerelictGL's extension
 loader. Incidentally, before reading this I just finished refactoring
 another project to use some package-protected stuff. But I've never had
 a need (yet) to override anything with package protection outside of the
 same module.


 I see, I see. I guess it's more used in Java because it's the default.


Well, it's kind of forced on you in Java when you want classes to interact 
without having the functions or variables involved be public, since all public 
classes must be in their own file. A lot of those cases can be covered in D by 
putting the classes in the same module. So, the value of package is definitely 
reduced in D, but it's not gone.

- Jonathan M Davis

"Martin Nowak" <dawg dawgfoto.de> writes:

On Thu, 01 Mar 2012 17:11:14 +0100, Alex R=C3=B8nne Petersen  =

<xtzgzorex gmail.com> wrote:

 On 01-03-2012 08:26, Jacob Carlborg wrote:
 On 2012-03-01 01:53, Jonathan M Davis wrote:
 package functions are currenly non-virtual.

 The spec claims that "all non-static non-private non-template
 member func=C2=AD
 tions are virtual," which would mean that package is supposed to be
 virtual.
 But from what I recall, the plan is to leave package as non-virtual.=






 So, is
 that indeed the case and the spec needs to be fixed, or is package
 going to be
 made virtual at some point?

 - Jonathan M Davis


 Is anyone even using "package"? I've basically never used it.


 I use it. It's useful when you wish to create higher-level wrappers  =


 around stuff. (Interestingly, I only ever use package for constructors=