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 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=




m=C2=ADplate mem=C2=ADber

 func=C2=AD tions are vir=C2=ADtual," 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 f=




ixed,

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


=20
 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
parent reply "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
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 >




 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.


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 "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 

file/module per class, it is indeed useful. I've never had nor 

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 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 reply 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
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 reply =?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
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=


.)


Because 'package' doesn't work for anything but functions?



 Mar 01 2012



prev 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