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

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

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

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

On Thu, 01 Mar 2012 17:11:14 +0100, Alex Rønne 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­
>>> 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?