On Wed, Feb 29, 2012 at 07:53:54PM -0500, 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?
[...]

Virtual package functions would be interesting in theory... but I doubt there's much practical use for such things. Will packages have an inheritance hierarchy now?


T

-- 
Любишь кататься - люби и саночки возить.

On Wednesday, February 29, 2012 17:05:19 H. S. Teoh wrote:
> On Wed, Feb 29, 2012 at 07:53:54PM -0500, 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?
> 
> [...]
> 
> Virtual package functions would be interesting in theory... but I doubt there's much practical use for such things. Will packages have an inheritance hierarchy now?

The point of allowing virtual package functions would be to allow derived classes within a package to override the function but disallow it for derived classes outside of the package. It has nothing to do with adding an "inheritance hierarchy" to packages (I'm not even sure what you mean be that). There are similar arguments for making private virtual.

Personally, I'm absolutely fine with package being non-virtual. I'm just trying to verify that I'm correct in my understanding that the plan is to leave it non-virtual rather than to make dmd match what the spec currently says and make package virtual.

- Jonathan M Davis

On 01-03-2012 02:27, Jonathan M Davis wrote:
> On Wednesday, February 29, 2012 17:05:19 H. S. Teoh wrote:
>> On Wed, Feb 29, 2012 at 07:53:54PM -0500, 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?
>>
>> [...]
>>
>> Virtual package functions would be interesting in theory... but I doubt
>> there's much practical use for such things. Will packages have an
>> inheritance hierarchy now?
>
> The point of allowing virtual package functions would be to allow derived
> classes within a package to override the function but disallow it for derived
> classes outside of the package. It has nothing to do with adding an
> "inheritance hierarchy" to packages (I'm not even sure what you mean be that).
> There are similar arguments for making private virtual.
>
> Personally, I'm absolutely fine with package being non-virtual. I'm just trying
> to verify that I'm correct in my understanding that the plan is to leave it
> non-virtual rather than to make dmd match what the spec currently says and
> make package virtual.
>
> - Jonathan M Davis

I think making package functions non-virtual is a bad idea. Why is the language trying to make some arbitrary decision for the programmer without any real reason?

(And please don't say "performance"; then I'll have to whip out the good old "virtual by default is stupid"...)

-- 
- Alex

Le 01/03/2012 02:27, Jonathan M Davis a écrit :
>
> Personally, I'm absolutely fine with package being non-virtual. I'm just trying
> to verify that I'm correct in my understanding that the plan is to leave it
> non-virtual rather than to make dmd match what the spec currently says and
> make package virtual.
>

Both should be virtual unless specified final.


For private as it is in the module, it is easy for the compiler to finalize the function if it isn't overriden within the module.