Question about alias in traits
Hi, I may have understood incorrectly the idea behind and alias when using traits, but I was expecting that when using an alias, the aliased method would be removed and all the sender of that message would be change to the new one (the alias), but I don't see that happening. Here is some code: Trait named: #SomeTrait uses: {} SomeTrait>>m1 ^ 1 SomeTrait>>m2 self m1 Object subclass: #SomeClass uses: SomeTrait @ { #m3 -> #m1} It generates: SomeClass>>m1 ^ 1 SomeClass>>m2 self m1 SomeClass>>m3 ^1 But I was specting: SomeClass>>m2 self m3 SomeClass>>m3 ^1 and the method SomeClass>>m1 removed. Was my interpretation of Alias incorrect? or is the current implementation of alias incorrect? (maybe due to some implementation problems?) Thanks! Hernan. -- *Hernán Wilkinson Agile Software Development, Teaching & Coaching* *Phone: +54 - 011 - *6091 - 3125* Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Alem 693, Floor 5 B, Buenos Aires, Argentina
On Thu, Jan 10, 2013 at 1:21 PM, Hernan Wilkinson <hernan.wilkinson@10pines.com> wrote:
Was my interpretation of Alias incorrect? or is the current implementation of alias incorrect? (maybe due to some implementation problems?)
@ is an Alias operator, not a Rename operator. That means when you alias { #m3 -> #m1 } you get a new name for the same method. So what you see is the expected behavior, as defined in the paper. And the direction of the arrow makes sense: #m3 -> #m1 is read as "m3 is a new name for m1", whereas for a Rename operator, we would probably have something like "#m1 -> #m3", i.e., m1 is renamed to m3. In a fully dynamic language, a Rename operator would be quite hard to implement I guess, IIRC Eiffel has a rename operator. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
On Jan 10, 2013, at 2:17 PM, Damien Cassou wrote:
On Thu, Jan 10, 2013 at 1:21 PM, Hernan Wilkinson <hernan.wilkinson@10pines.com> wrote:
Was my interpretation of Alias incorrect? or is the current implementation of alias incorrect? (maybe due to some implementation problems?)
@ is an Alias operator, not a Rename operator. That means when you alias { #m3 -> #m1 } you get a new name for the same method. So what you see is the expected behavior, as defined in the paper. And the direction of the arrow makes sense: #m3 -> #m1 is read as "m3 is a new name for m1", whereas for a Rename operator, we would probably have something like "#m1 -> #m3", i.e., m1 is renamed to m3. In a fully dynamic language, a Rename operator would be quite hard to implement I guess, IIRC Eiffel has a rename operator.
Not quite hard. doing it fully and correctly is no possible because you should distinguish the methods that should be renamed.
thanks, I don't know why I thought that the alias was a rename too (maybe the name suggested me that...) I think that having a "rename operator" that acts on the trait being composed in messages send to self would help in most of the cases, but as you say, it is not possible to take care of all the cases. Thanks! Hernan. On Thu, Jan 10, 2013 at 4:17 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
On Jan 10, 2013, at 2:17 PM, Damien Cassou wrote:
On Thu, Jan 10, 2013 at 1:21 PM, Hernan Wilkinson <hernan.wilkinson@10pines.com> wrote:
Was my interpretation of Alias incorrect? or is the current implementation of alias incorrect? (maybe due to some implementation problems?)
@ is an Alias operator, not a Rename operator. That means when you alias { #m3 -> #m1 } you get a new name for the same method. So what you see is the expected behavior, as defined in the paper. And the direction of the arrow makes sense: #m3 -> #m1 is read as "m3 is a new name for m1", whereas for a Rename operator, we would probably have something like "#m1 -> #m3", i.e., m1 is renamed to m3. In a fully dynamic language, a Rename operator would be quite hard to implement I guess, IIRC Eiffel has a rename operator.
Not quite hard. doing it fully and correctly is no possible because you should distinguish the methods that should be renamed.
-- *Hernán Wilkinson Agile Software Development, Teaching & Coaching* *Phone: +54 - 011 - *6091 - 3125* Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Alem 693, Floor 5 B, Buenos Aires, Argentina
On Mon, Jan 14, 2013 at 9:11 PM, Hernan Wilkinson <hernan.wilkinson@10pines.com> wrote:
I think that having a "rename operator" that acts on the trait being composed in messages send to self would help in most of the cases, but as you say, it is not possible to take care of all the cases.
I guess it would be possible to rename all the self-sends and only them. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
I may have understood incorrectly the idea behind and alias when using traits, but I was expecting that when using an alias, the aliased method would be removed and all the sender of that message would be change to the new one (the alias), but I don't see that happening.
You cannot do that in a dynamically typed language. Why because you do not know how to scope the method renaming. Aliasing is not renaming. Stef
Here is some code:
Trait named: #SomeTrait uses: {}
SomeTrait>>m1 ^ 1 SomeTrait>>m2 self m1
Object subclass: #SomeClass uses: SomeTrait @ { #m3 -> #m1}
It generates: SomeClass>>m1 ^ 1 SomeClass>>m2 self m1 SomeClass>>m3 ^1
But I was specting: SomeClass>>m2 self m3 SomeClass>>m3 ^1 and the method SomeClass>>m1 removed.
Was my interpretation of Alias incorrect? or is the current implementation of alias incorrect? (maybe due to some implementation problems?)
Thanks! Hernan.
-- Hernán Wilkinson Agile Software Development, Teaching & Coaching Phone: +54 - 011 - 6091 - 3125 Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com Address: Alem 693, Floor 5 B, Buenos Aires, Argentina
participants (3)
-
Damien Cassou -
Hernan Wilkinson -
Stéphane Ducasse