[Pharo-project] Trait bug to fix....
T requires m
A uses: T m ^#fromA B subclass: A uses: T
M new m => error explicit requirement
Begin forwarded message:
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. 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. 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. 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:
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I'm confused I do not undersatnd why if B is a subclass of A it uses T too. I have to check the bugs tracker 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.
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. 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. 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:
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Maybe the solution is to not have this methods. Required methods are easily inferred. There is no need to ask the user to define methods... Alexandre On 21 Jan 2009, at 22:03, 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.
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. 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. 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:
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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:
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Jan 21, 2009, at 22:55 , Alexandre Bergel wrote:
Maybe the solution is to not have this methods. Required methods are easily inferred. There is no need to ask the user to define methods...
exactly Adrian
Alexandre
On 21 Jan 2009, at 22:03, 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.
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. 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. 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:
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
In the example you posted the class A should not use T. The description of the Mantis report is correct. Adrian On Jan 21, 2009, at 22:53 , Stéphane Ducasse wrote:
I'm confused I do not undersatnd why if B is a subclass of A it uses T too. I have to check the bugs tracker
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.
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. 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. 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:
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Jan 21, 2009, at 22:57 , Stéphane Ducasse wrote:
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?
Its not that simple because the situation can change at any time. Lets say, class A does not implement #doSomething when you define B. When you add the trait T1, #doSomething sending #explicitRequirement is added to B. Later you implement #doSomething in A. At this moment the #doSomething has to be removed from B. Adrian
Yes I thought about that after my post if the superclass get the method removed... So I think that we should remove the explicit requirement since it is too static in a world like Smalltalk. Stef On Jan 21, 2009, at 11:08 PM, Adrian Lienhard wrote:
On Jan 21, 2009, at 22:57 , Stéphane Ducasse wrote:
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?
Its not that simple because the situation can change at any time. Lets say, class A does not implement #doSomething when you define B. When you add the trait T1, #doSomething sending #explicitRequirement is added to B. Later you implement #doSomething in A. At this moment the #doSomething has to be removed from B.
Adrian
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (4)
-
Adrian Lienhard -
Alexandre Bergel -
Stéphane Ducasse -
Stéphane Ducasse