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

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

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

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.

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.

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.

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.

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

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

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