[Prev][Next][Index][Thread]
Re: Need help with Class-Allocated Slots
> > > During the design of Dylan, I proposed that class slots be accessible
> > > by calling the accessor on the class object itself, but Moon didn't like
> > > it because it confuses class vs. instance. I agree with Moon on the
> > > exact point, but I still think that the semantics of my dumb-ass proposal
> > > are well enough understood, that it is probably reasonable.
> >
> > Maybe it's time to resurrect the Dylan Language discussion at
> >
> > http://www.isr.com/dylan/dylan-language/
> >
> > I agree that it should be possible to access class slots without
> > having an instance.
>
> The big problems with this that is it's hard to know what to do if
> there is a specialized method shadowing the basic getter. For example:
>
> define class <super> (<object>)
> class slot foo :: <integer>,
> init-value: 6;
> end class;
>
> define class <perverse-subclass> (<super>)
> slot bar :: <integer>,
> init-value: 24;
> end class;
>
> define method foo (obj :: <perverse-subclass>, #next next-method)
> obj.bar * next-method()
> end method;
>
> Then it's totally unclear what you should return with a method like
>
> class-slot(class, getter-generic)
>
> when you call class-slot(<perverse-subclass>, foo). IMO, in this case,
> half a loaf is definitely worse than either no loaf.
There could (ought to) be a way to qualify the ambiguous reference to
make it clear which reference is being requested, "method foo" of "slot
foo".
In the absence of an unambiguous reference the system could simply flag
it as an error.
In practice, conflicts like this are less of a problem than the lack of
having the feature in the first place. Multiple Inheritance can cause
conflicts as well, but that doesn't mean it should not be implemented
(which is the approach Java took with MI).
Dick
Follow-Ups:
References: