Working on the new class builder I have a hard time figuring out the full trait semantics. If I use a trait on instance side, does that imply that its classTrait on the metaclass?
On 29 June 2013 20:12, Camillo Bruni <camillobruni@gmail.com> wrote:
Working on the new class builder I have a hard time figuring out the full trait semantics.
If I use a trait on instance side, does that imply that its classTrait on the metaclass?
yes. Trait resembles same dual property as class (it has instance side and class side methods). But i also not really like it. IMO single trait should be applied separately only to selected behavior not two at once (class and its metaclass), and you should be able to choose which one. -- Best regards, Igor Stasenko.
On Jun 29, 2013, at 8:19 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 29 June 2013 20:12, Camillo Bruni <camillobruni@gmail.com> wrote:
Working on the new class builder I have a hard time figuring out the full trait semantics.
If I use a trait on instance side, does that imply that its classTrait on the metaclass?
No. I do not think so (I will have to think). Normally Trait and ClassTrait are two different classes. NOw I do not remember if a trait is composed of a classTrait too. Sytef
On 29 June 2013 21:21, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Jun 29, 2013, at 8:19 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 29 June 2013 20:12, Camillo Bruni <camillobruni@gmail.com> wrote:
Working on the new class builder I have a hard time figuring out the full trait semantics.
If I use a trait on instance side, does that imply that its classTrait on the metaclass?
No. I do not think so (I will have to think). Normally Trait and ClassTrait are two different classes. NOw I do not remember if a trait is composed of a classTrait too.
Trait has 'classTrait'
Sytef
-- Best regards, Igor Stasenko.
On 2013-06-29, at 22:32, Igor Stasenko <siguctua@gmail.com> wrote:
On 29 June 2013 21:21, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Jun 29, 2013, at 8:19 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 29 June 2013 20:12, Camillo Bruni <camillobruni@gmail.com> wrote:
Working on the new class builder I have a hard time figuring out the full trait semantics.
If I use a trait on instance side, does that imply that its classTrait on the metaclass?
No. I do not think so (I will have to think). Normally Trait and ClassTrait are two different classes. NOw I do not remember if a trait is composed of a classTrait too.
Trait has 'classTrait'
yes, but the strange part is, that if you use a Trait on the instance-side it will automatically install the class trait as well. ClassDescription subclass: #Class uses: TClass ... and the users TClass users => an IdentitySet(Class) TClass classTrait users => an IdentitySet(Class class) so in this case it implies that when you use a Trait on the instance side it will apply also it's classTrait to the class side. So is it ok then to enforce that in the new class builder? Currently you can do the following in the new class builder: PharoClassInstaller make: [:builder| builder superclass: Object; name: 'Foo'; traitComposition: TClass ] which will explicitely NOT install `TClass classTrait` in `Foo class`. Does this behavior make sense?
yes, i don't know if it good or bad, but i'd rather prefer that traits applied to Behavior, but not to Class (which has two entangled behaviors). But maybe for human comprehension it is better.. but not for implementing, because it certainly makes model more complex. On 29 June 2013 22:52, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-06-29, at 22:32, Igor Stasenko <siguctua@gmail.com> wrote:
On 29 June 2013 21:21, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Jun 29, 2013, at 8:19 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 29 June 2013 20:12, Camillo Bruni <camillobruni@gmail.com> wrote:
Working on the new class builder I have a hard time figuring out the full trait semantics.
If I use a trait on instance side, does that imply that its classTrait on the metaclass?
No. I do not think so (I will have to think). Normally Trait and ClassTrait are two different classes. NOw I do not remember if a trait is composed of a classTrait too.
Trait has 'classTrait'
yes, but the strange part is, that if you use a Trait on the instance-side it will automatically install the class trait as well.
ClassDescription subclass: #Class uses: TClass ...
and the users
TClass users => an IdentitySet(Class) TClass classTrait users => an IdentitySet(Class class)
so in this case it implies that when you use a Trait on the instance side it will apply also it's classTrait to the class side. So is it ok then to enforce that in the new class builder?
Currently you can do the following in the new class builder:
PharoClassInstaller make: [:builder| builder superclass: Object; name: 'Foo'; traitComposition: TClass ]
which will explicitely NOT install `TClass classTrait` in `Foo class`. Does this behavior make sense?
-- Best regards, Igor Stasenko.
so let's discuss that on monday with the trait specialists Damien et Sebastian :) On 2013-06-29, at 23:34, Igor Stasenko <siguctua@gmail.com> wrote:
yes, i don't know if it good or bad, but i'd rather prefer that traits applied to Behavior, but not to Class (which has two entangled behaviors). But maybe for human comprehension it is better.. but not for implementing, because it certainly makes model more complex.
On 29 June 2013 22:52, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-06-29, at 22:32, Igor Stasenko <siguctua@gmail.com> wrote:
On 29 June 2013 21:21, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Jun 29, 2013, at 8:19 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 29 June 2013 20:12, Camillo Bruni <camillobruni@gmail.com> wrote:
Working on the new class builder I have a hard time figuring out the full trait semantics.
If I use a trait on instance side, does that imply that its classTrait on the metaclass?
No. I do not think so (I will have to think). Normally Trait and ClassTrait are two different classes. NOw I do not remember if a trait is composed of a classTrait too.
Trait has 'classTrait'
yes, but the strange part is, that if you use a Trait on the instance-side it will automatically install the class trait as well.
ClassDescription subclass: #Class uses: TClass ...
and the users
TClass users => an IdentitySet(Class) TClass classTrait users => an IdentitySet(Class class)
so in this case it implies that when you use a Trait on the instance side it will apply also it's classTrait to the class side. So is it ok then to enforce that in the new class builder?
Currently you can do the following in the new class builder:
PharoClassInstaller make: [:builder| builder superclass: Object; name: 'Foo'; traitComposition: TClass ]
which will explicitely NOT install `TClass classTrait` in `Foo class`. Does this behavior make sense?
-- Best regards, Igor Stasenko.
Ok I slept and now my brain is working. I think that having classTrait and trait together is important because else it would be the mess when you have a class method that uses an instance methods (both define in a trait). So conceptually this is one trait like in smalltalk you have one class and its metaclass. The model is similar and to represent class trait we have a ClassTrait class. Stef On Jun 30, 2013, at 1:04 AM, Camillo Bruni <camillobruni@gmail.com> wrote:
so let's discuss that on monday with the trait specialists Damien et Sebastian :)
On 2013-06-29, at 23:34, Igor Stasenko <siguctua@gmail.com> wrote:
yes, i don't know if it good or bad, but i'd rather prefer that traits applied to Behavior, but not to Class (which has two entangled behaviors). But maybe for human comprehension it is better.. but not for implementing, because it certainly makes model more complex.
On 29 June 2013 22:52, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-06-29, at 22:32, Igor Stasenko <siguctua@gmail.com> wrote:
On 29 June 2013 21:21, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Jun 29, 2013, at 8:19 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 29 June 2013 20:12, Camillo Bruni <camillobruni@gmail.com> wrote:
Working on the new class builder I have a hard time figuring out the full trait semantics.
If I use a trait on instance side, does that imply that its classTrait on the metaclass?
No. I do not think so (I will have to think). Normally Trait and ClassTrait are two different classes. NOw I do not remember if a trait is composed of a classTrait too.
Trait has 'classTrait'
yes, but the strange part is, that if you use a Trait on the instance-side it will automatically install the class trait as well.
ClassDescription subclass: #Class uses: TClass ...
and the users
TClass users => an IdentitySet(Class) TClass classTrait users => an IdentitySet(Class class)
so in this case it implies that when you use a Trait on the instance side it will apply also it's classTrait to the class side. So is it ok then to enforce that in the new class builder?
Currently you can do the following in the new class builder:
PharoClassInstaller make: [:builder| builder superclass: Object; name: 'Foo'; traitComposition: TClass ]
which will explicitely NOT install `TClass classTrait` in `Foo class`. Does this behavior make sense?
-- Best regards, Igor Stasenko.
+1 Keeping things uniform is a plus in this case, even though we might lose some flexibility. Doru On Sun, Jun 30, 2013 at 9:01 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
Ok I slept and now my brain is working. I think that having classTrait and trait together is important because else it would be the mess when you have a class method that uses an instance methods (both define in a trait). So conceptually this is one trait like in smalltalk you have one class and its metaclass.
The model is similar and to represent class trait we have a ClassTrait class.
Stef
On Jun 30, 2013, at 1:04 AM, Camillo Bruni <camillobruni@gmail.com> wrote:
so let's discuss that on monday with the trait specialists Damien et Sebastian :)
On 2013-06-29, at 23:34, Igor Stasenko <siguctua@gmail.com> wrote:
yes, i don't know if it good or bad, but i'd rather prefer that traits applied to Behavior, but not to Class (which has two entangled behaviors). But maybe for human comprehension it is better.. but not for implementing, because it certainly makes model more complex.
On 29 June 2013 22:52, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-06-29, at 22:32, Igor Stasenko <siguctua@gmail.com> wrote:
On 29 June 2013 21:21, Stéphane Ducasse <stephane.ducasse@inria.fr>
wrote:
On Jun 29, 2013, at 8:19 PM, Igor Stasenko <siguctua@gmail.com>
wrote:
On 29 June 2013 20:12, Camillo Bruni <camillobruni@gmail.com>
wrote:
Working on the new class builder I have a hard time figuring out the full trait semantics.
If I use a trait on instance side, does that imply that its classTrait on the metaclass?
No. I do not think so (I will have to think). Normally Trait and ClassTrait are two different classes. NOw I do not remember if a trait is composed of a classTrait too.
Trait has 'classTrait'
yes, but the strange part is, that if you use a Trait on the instance-side it will automatically install the class trait as well.
ClassDescription subclass: #Class uses: TClass ...
and the users
TClass users => an IdentitySet(Class) TClass classTrait users => an IdentitySet(Class class)
so in this case it implies that when you use a Trait on the instance side it will apply also it's classTrait to the class side. So is it ok then to enforce that in the new class builder?
Currently you can do the following in the new class builder:
PharoClassInstaller make: [:builder| builder superclass: Object; name: 'Foo'; traitComposition: TClass ]
which will explicitely NOT install `TClass classTrait` in `Foo class`. Does this behavior make sense?
-- Best regards, Igor Stasenko.
-- www.tudorgirba.com "Every thing has its own flow"
I also like this uniform because it's easier to program, Up to now i haven't had the need to separate them. 2013/6/30 Tudor Girba <tudor@tudorgirba.com>
+1
Keeping things uniform is a plus in this case, even though we might lose some flexibility.
Doru
On Sun, Jun 30, 2013 at 9:01 AM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
Ok I slept and now my brain is working. I think that having classTrait and trait together is important because else it would be the mess when you have a class method that uses an instance methods (both define in a trait). So conceptually this is one trait like in smalltalk you have one class and its metaclass.
The model is similar and to represent class trait we have a ClassTrait class.
Stef
On Jun 30, 2013, at 1:04 AM, Camillo Bruni <camillobruni@gmail.com> wrote:
so let's discuss that on monday with the trait specialists Damien et Sebastian :)
On 2013-06-29, at 23:34, Igor Stasenko <siguctua@gmail.com> wrote:
yes, i don't know if it good or bad, but i'd rather prefer that traits applied to Behavior, but not to Class (which has two entangled behaviors). But maybe for human comprehension it is better.. but not for implementing, because it certainly makes model more complex.
On 29 June 2013 22:52, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-06-29, at 22:32, Igor Stasenko <siguctua@gmail.com> wrote:
On 29 June 2013 21:21, Stéphane Ducasse <stephane.ducasse@inria.fr>
wrote:
On Jun 29, 2013, at 8:19 PM, Igor Stasenko <siguctua@gmail.com>
wrote:
On 29 June 2013 20:12, Camillo Bruni <camillobruni@gmail.com>
wrote:
Working on the new class builder I have a hard time figuring out the full trait semantics.
If I use a trait on instance side, does that imply that its classTrait on the metaclass?
No. I do not think so (I will have to think). Normally Trait and ClassTrait are two different classes. NOw I do not remember if a trait is composed of a classTrait too.
Trait has 'classTrait'
yes, but the strange part is, that if you use a Trait on the instance-side it will automatically install the class trait as well.
ClassDescription subclass: #Class uses: TClass ...
and the users
TClass users => an IdentitySet(Class) TClass classTrait users => an IdentitySet(Class class)
so in this case it implies that when you use a Trait on the instance side it will apply also it's classTrait to the class side. So is it ok then to enforce that in the new class builder?
Currently you can do the following in the new class builder:
PharoClassInstaller make: [:builder| builder superclass: Object; name: 'Foo'; traitComposition: TClass ]
which will explicitely NOT install `TClass classTrait` in `Foo class`. Does this behavior make sense?
-- Best regards, Igor Stasenko.
-- www.tudorgirba.com
"Every thing has its own flow"
On 2013-06-30, at 11:16, Sebastian Tleye <stleye@gmail.com> wrote:
I also like this uniform because it's easier to program, Up to now i haven't had the need to separate them.
2013/6/30 Tudor Girba <tudor@tudorgirba.com>
+1
Keeping things uniform is a plus in this case, even though we might lose some flexibility.
Doru
But you know that you can do this right now? Object subclass: #Foo uses: TMyTrait classTrait and the same on the class-side :/ Foo class uses: TMyOtherTrait instanceVariableNames: 'a b c' so from that point of view the current system allows for a messy/flexible combination of instance-side and class-side traits.
On Sun, Jun 30, 2013 at 2:54 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
But you know that you can do this right now?
I think these examples only show that some verifications are missing. I don't know any source code using that. To me it's more a bug than a feature. I would keep things simple: applying a trait to a class applies the classTrait to the metaclass. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
On 30 June 2013 15:48, Damien Cassou <damien.cassou@gmail.com> wrote:
On Sun, Jun 30, 2013 at 2:54 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
But you know that you can do this right now?
I think these examples only show that some verifications are missing. I don't know any source code using that. To me it's more a bug than a feature. I would keep things simple: applying a trait to a class applies the classTrait to the metaclass.
but that's far less simpler than: - applying trait to behavior (object), applies it only to that object and nothing else (no meta-mess).
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
-- Best regards, Igor Stasenko.
On 1 juil. 2013, at 12:19, Igor Stasenko wrote:
On 30 June 2013 15:48, Damien Cassou <damien.cassou@gmail.com> wrote:
On Sun, Jun 30, 2013 at 2:54 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
But you know that you can do this right now?
I think these examples only show that some verifications are missing. I don't know any source code using that. To me it's more a bug than a feature. I would keep things simple: applying a trait to a class applies the classTrait to the metaclass.
but that's far less simpler than: - applying trait to behavior (object), applies it only to that object and nothing else (no meta-mess).
Yet the current trait model is based on trait and class trait, and that's consistent with the class model. If you want trait to be applied only on one side: - we have to refactor a lot of stuff, because a lot of our current code rely on this model. - you have to provide a new way for managing instance/class-side dependancies: For example, if one the class side you have: "self class blah" how can you ensure that the class side has the implementation you expect? On the other hand if you want a trait to be applied only on the instance side: provide only instance-side methods. And if you want a trait to be applied only on the class-side: provides only class-side methods. So everything's fine with this regard IMO. Don't change it, just ensure the missing verification in the class builder.
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
-- Best regards, Igor Stasenko.
On 1 July 2013 14:01, Camille Teruel <camille.teruel@gmail.com> wrote:
On 1 juil. 2013, at 12:19, Igor Stasenko wrote:
On 30 June 2013 15:48, Damien Cassou <damien.cassou@gmail.com> wrote:
On Sun, Jun 30, 2013 at 2:54 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
But you know that you can do this right now?
I think these examples only show that some verifications are missing. I don't know any source code using that. To me it's more a bug than a feature. I would keep things simple: applying a trait to a class applies the classTrait to the metaclass.
but that's far less simpler than: - applying trait to behavior (object), applies it only to that object and nothing else (no meta-mess).
Yet the current trait model is based on trait and class trait, and that's consistent with the class model. If you want trait to be applied only on one side: - we have to refactor a lot of stuff, because a lot of our current code rely on this model. - you have to provide a new way for managing instance/class-side dependancies: For example, if one the class side you have: "self class blah" how can you ensure that the class side has the implementation you expect?
it is not responsibility of trait to reason whether "self class" gives right/wrong object to work with. #class is just a message sent to receiver.. you may think it is special, but there's nothing special in it comparing to any other message you sending to object(s). in any case, when developer applies trait on class side, he knows what he doing, isn't?
On the other hand if you want a trait to be applied only on the instance side: provide only instance-side methods. And if you want a trait to be applied only on the class-side: provides only class-side methods.
So everything's fine with this regard IMO. Don't change it, just ensure the missing verification in the class builder.
Fine? Ok, how to apply trait which has single method, to make this method appear on both class and instance sides? (Copy/pasting same method twice is not an answer). I am not asking for changing things. But i think that implementation would be simpler, if Trait do not have to support class/metaclass duality. -- Best regards, Igor Stasenko.
But you know that you can do this right now?
Object subclass: #Foo uses: TMyTrait classTrait
and the same on the class-side :/
Foo class uses: TMyOtherTrait instanceVariableNames: 'a b c'
so from that point of view the current system allows for a messy/flexible combination of instance-side and class-side traits.
yes because you can have class side trait. and this is too complex. I agree. In fact I really have a love/hate feeling about traits. Stef
Hi, Theoretically, I could do the same for inheritance as well. But, that would be too complex for most cases, so it is the implicit behavior. To me, the decision for trait handling is similar. Cheers, Doru On Sun, Jun 30, 2013 at 2:54 PM, Camillo Bruni <camillobruni@gmail.com>wrote:
On 2013-06-30, at 11:16, Sebastian Tleye <stleye@gmail.com> wrote:
I also like this uniform because it's easier to program, Up to now i haven't had the need to separate them.
2013/6/30 Tudor Girba <tudor@tudorgirba.com>
+1
Keeping things uniform is a plus in this case, even though we might lose some flexibility.
Doru
But you know that you can do this right now?
Object subclass: #Foo uses: TMyTrait classTrait
and the same on the class-side :/
Foo class uses: TMyOtherTrait instanceVariableNames: 'a b c'
so from that point of view the current system allows for a messy/flexible combination of instance-side and class-side traits.
-- www.tudorgirba.com "Every thing has its own flow"
participants (7)
-
Camille Teruel -
Camillo Bruni -
Damien Cassou -
Igor Stasenko -
Sebastian Tleye -
Stéphane Ducasse -
Tudor Girba