www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - package and virtual

reply "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
Feb 29 2012
next sibling parent reply 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
Feb 29 2012
next sibling parent reply 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.
Mar 01 2012
parent 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
Mar 01 2012
prev sibling next sibling parent =?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
Mar 01 2012
prev sibling parent =?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
Mar 01 2012
prev sibling next sibling parent 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
Feb 29 2012
prev sibling next sibling parent reply 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.
Mar 01 2012
next sibling parent reply =?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
Mar 01 2012
parent 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
Mar 01 2012
prev sibling parent 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
Mar 01 2012
prev sibling next sibling parent "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.
Mar 01 2012
prev sibling next sibling parent "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.
Mar 01 2012
prev sibling next sibling parent "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
Mar 01 2012
prev sibling parent "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=


Mar 01 2012