T1>>f
self explicitRequirement
A is a subclass of Object, NOT using T1
A>>f
self doSomething
B is a subclass of A using T1
In B, f is still a requirement even if implemented in the superclass.
This is because methods in trait T1 take precedence over methods in
the superclass. This should not be the case with required methods.
Adrian why this is not simply that when you compute the composition
and the method that you should add in B that you do not add
f if it is an explicit requirement and defined in the superclass?
On Jan 21, 2009, at 10:03 PM, Adrian Lienhard wrote:
> Any suggestion for how to implement this? Without using some
> reflection tricks, this would imply that the marker methods have to be
> added and removed depending on the methods added and removed in
> superclasses. This would significantly complicate the implementation.
I do not understand why you would have to do that?
>
>
> BTW, this only is an issue if m is implemented as "self
> explicitRequirement". I never really understood why one would want to
> explicitly declare requirements.
I thought it was interesting because it made clear the intention and
what we had to provide.
> In the end, the difference is to get
> a different exception than a MNU. If one wants this to see what
> methods still need to be implemented in a class I would rather suggest
> to extend the tools to show this (even the ones not explicitly
> declared) and not use explicit declarations.
probably
> The algorithm by
> Nathanael to do exactly this is already in the image.
>
> Adrian
>
> On Jan 21, 2009, at 21:37 , Stéphane Ducasse wrote:
>
>>> T requires m
>>>
>>> A uses: T
>>> m ^#fromA
>>> B subclass: A uses: T
>>>
>>> M new m => error explicit requirement
>>
>> Begin forwarded message:
>>
>>> http://bugs.squeak.org/view.php?id=6534
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [email protected]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
