Functions with package protection

Denis Koroskin 2korden at gmail.com
Thu Jun 4 04:01:41 PDT 2009


On Thu, 04 Jun 2009 07:36:35 +0400, Jarrett Billingsley <jarrett.billingsley at gmail.com> wrote:

> On Wed, Jun 3, 2009 at 10:02 PM, Christopher Wright <dhasenan at gmail.com>  
> wrote:
>> Robert Fraser wrote:
>>>
>>> grauzone wrote:
>>>>>
>>>>> Sorry to dig up this old post, but I still don't understand why
>>>>> 'package' functions cannot be virtual? Is there a good reason for  
>>>>> this? I
>>>>> can't see why we can't use polymorphism on 'package' functions!
>>>>>
>>>>> Is there way to make it virtual without making it public? (e.g. a
>>>>> 'virtual' keyword?)
>>>>
>>>> "package" needs to fixes:
>>>> - package methods must be allowed to be virtual
>>>> - package methods must be allowed to be accessed from sub packages
>>>> (module a.b.x should be able to access package identifiers declared in
>>>> module a.y)
>>>>
>>>> I don't understand why these fixes applied, especially because they  
>>>> are
>>>> completely backward compatible.
>>>
>>> "package methods must be allowed to be virtual" isn't
>>> backwards-compatible. This code will work differently if package  
>>> methods
>>> were made virtual:
>>
>> That's a larger problem, I think: you can override methods silently. The
>> override keyword should be required.
>
> It is in D2.

Since when?



More information about the Digitalmars-d mailing list