Library standardization

[Robert Fraser]

Sean Kelly wrote:
> == Quote from Robert Fraser (fraserofthenight at gmail.com)'s article
>> Sean Kelly wrote:
>>> Oh, I see what you mean.  I suppose one could argue that package methods are
>>> effectively static, but it still seems a bit weird to me.  Can they access instance
>>> variables?
>>>
>> Yes, of course. What's your argument for "effectively static"? "package"
>> is just a protection attribute, just like "public", "private", and
>> "protected"; I don't see the static-ness involved at all.
>> Maybe "package" means something different in another language? I'm just
>> coming from a Java background where package-protection is the default &
>> quite common.
> 
> Yeah, I was just being dumb.  I think the reasoning is that, because 'package' is
> simply a slightly looser 'private' then it should follow the same rules.  I think
> this could be argued either way, but it does make some sense.  I don't suppose
> it's possible to implement a protected interface?

It doesn't make sense even for "private" because "private" means 
"private to this module", not "private to this class". "final" means 
(unless it's overriding something else) "don't put this in the vtable". 
But it's less of an issue for private than it is for package.

>     package interface I {
>         void fn();
>     }
> 
>     class C : package I {
>         package void fn() {}
>     }
> 
> I'd like to believe that this would work, but it's hard to say.  The other options
> I can think of would be some variation of the above--ie. providing an interface
> for package-level operations.  I've done this sort of thing in C++ before to get
> around the "friends have access to everything" issue.

It works, but it's still a design issue ;P.