Dale I missed your remark about traits. I think that traits are nice because they act as a kind of static macro expansion and really help to get multiple inheritance into single one. Now ideally I would like to have
Dale
I missed your remark about traits.I think that traits are nice because they act as a kind of static macro expansion and really help to get multiple inheritance into single one. Now ideally I would like to have (I hate so much this google nonUI)
- state with traits with a nice initialization process. - Now Pablo did a nice and simple implementation of Talents (dynamic traits). I should have a look because if we could unify it and have either a trait statically applied to a class (what we have now) and a trait being applicable to an instance then it would be really good. Now making the tools traits-aware is much more than just having traits in the language. - change - loading - editing - overloading when we compile a method that comes from a trait we should be able to say that it overrides..... What we did with the "unification" of traits and classes and the use of traits inside the kernel is a mistake (in Squeak andreas if I recall made Trait a subclass of classDescription and this is not good either - even if he marketed it as a good idea) and we will iterated to remove the use of traits from Class and friends. Then ideally I would like to iterate over the - reflective API (because we should be able to simply access the "class" of a compiledMethod from where the traits is coming from or where it is installed - revisite the implementation because the clause composition. I think that the tools should not manipulate traits as classes because traits are not classes. Then doing this we will clarify that the traits and classes must not be polymorphic because they are not. Stef
Am 10.12.2016 um 20:48 schrieb stepharong <stepharong@free.fr>:
Dale
I missed your remark about traits. I think that traits are nice because they act as a kind of static macro expansion and really help to get multiple inheritance into single one.
Now ideally I would like to have (I hate so much this google nonUI)
- state with traits with a nice initialization process. - Now Pablo did a nice and simple implementation of Talents (dynamic traits). I should have a look because if we could unify it and have either a trait statically applied to a class (what we have now) and a trait being applicable to an instance then it would be really good.
Where is this Talents implementation? thanks, Norbert
Now making the tools traits-aware is much more than just having traits in the language. - change - loading - editing - overloading when we compile a method that comes from a trait we should be able to say that it overrides.....
What we did with the "unification" of traits and classes and the use of traits inside the kernel is a mistake (in Squeak andreas if I recall made Trait a subclass of classDescription and this is not good either - even if he marketed it as a good idea) and we will iterated to remove the use of traits from Class and friends. Then ideally I would like to iterate over the - reflective API (because we should be able to simply access the "class" of a compiledMethod from where the traits is coming from or where it is installed - revisite the implementation because the clause composition.
I think that the tools should not manipulate traits as classes because traits are not classes. Then doing this we will clarify that the traits and classes must not be polymorphic because they are not.
Stef
Dale
I missed your remark about traits.I think that traits are nice because they act as a kind of static macro expansion and really help to get multiple inheritance into single one. Now ideally I would like to have (I hate so much this google nonUI)
- state with traits with a nice initialization process. - Now Pablo did a nice and simple implementation of Talents (dynamic traits). I should have a look because if we could unify it and have either a trait statically applied to a class (what we have now) and a trait being applicable to an instance then it would be really good.
Where is this Talents implementation? I should ask pablo. It is better than the one of jorge because it is not based on reflectivity but anonymous class. We will document it.
Stef
thanks,
Norbert
Now making the tools traits-aware is much more than just having traits in the language. - change - loading - editing - overloading when we compile a method that comes from a trait we should be able to say that it overrides.....
What we did with the "unification" of traits and classes and the use of traits inside the kernel is a mistake (in Squeak andreas if I recall made Trait a subclass of classDescriptionand this is not good either - even if he marketed it as a good idea) and we will iterated to remove the use of traits from Class and friends.Then ideally I would like to iterate over the - reflective API (because we should be able to simply access the "class" of a compiledMethod from where the traits is coming from or where it is installed - revisite the implementation because the clause composition. I think that the tools should not manipulate traits as classes because traits are not classes.Then doing this we will clarify that the traits and classes must not be polymorphic because they are not.
Stef
-- Using Opera's mail client: http://www.opera.com/mail/
Am 11.12.2016 um 09:05 schrieb stepharong <stepharong@free.fr>:
Dale
I missed your remark about traits. I think that traits are nice because they act as a kind of static macro expansion and really help to get multiple inheritance into single one.
Now ideally I would like to have (I hate so much this google nonUI)
- state with traits with a nice initialization process. - Now Pablo did a nice and simple implementation of Talents (dynamic traits). I should have a look because if we could unify it and have either a trait statically applied to a class (what we have now) and a trait being applicable to an instance then it would be really good.
Where is this Talents implementation? I should ask pablo. It is better than the one of jorge because it is not based on reflectivity but anonymous class. We will document it.
Sounds good. I agree the old implementation was too heavy. The anonymous class case is surely the next obvious things. I played a bit with that approach. So I'm interested to have a real inplementation for that. Norbert
Stef
thanks,
Norbert
Now making the tools traits-aware is much more than just having traits in the language. - change - loading - editing - overloading when we compile a method that comes from a trait we should be able to say that it overrides.....
What we did with the "unification" of traits and classes and the use of traits inside the kernel is a mistake (in Squeak andreas if I recall made Trait a subclass of classDescription and this is not good either - even if he marketed it as a good idea) and we will iterated to remove the use of traits from Class and friends. Then ideally I would like to iterate over the - reflective API (because we should be able to simply access the "class" of a compiledMethod from where the traits is coming from or where it is installed - revisite the implementation because the clause composition.
I think that the tools should not manipulate traits as classes because traits are not classes. Then doing this we will clarify that the traits and classes must not be polymorphic because they are not.
Stef
-- Using Opera's mail client: http://www.opera.com/mail/
Hi, my implementation is in https://github.com/tesonep/pharo-talents . It does not have enough documentation, although the tests have working examples. I have as an objective of this week write more documentation. Any comment will be gratefully received. thanks, Pablo On Sun, Dec 11, 2016 at 9:05 AM, stepharong <stepharong@free.fr> wrote:
Dale
I missed your remark about traits. I think that traits are nice because they act as a kind of static macro expansion and really help to get multiple inheritance into single one.
Now ideally I would like to have
(I hate so much this google nonUI)
- state with traits with a nice initialization process. - Now Pablo did a nice and simple implementation of Talents (dynamic traits). I should have a look because if we could unify it and have either a trait statically applied to a class (what we have now) and a trait being applicable to an instance then it would be really good.
Where is this Talents implementation?
I should ask pablo. It is better than the one of jorge because it is not based on reflectivity but anonymous class. We will document it.
Stef
thanks,
Norbert
Now making the tools traits-aware is much more than just having traits in the language. - change - loading - editing - overloading when we compile a method that comes from a trait we should be able to say that it overrides.....
What we did with the "unification" of traits and classes and the use of traits inside the kernel is a mistake (in Squeak andreas if I recall made Trait a subclass of classDescription and this is not good either - even if he marketed it as a good idea) and we will iterated to remove the use of traits from Class and friends. Then ideally I would like to iterate over the - reflective API (because we should be able to simply access the "class" of a compiledMethod from where the traits is coming from or where it is installed - revisite the implementation because the clause composition.
I think that the tools should not manipulate traits as classes because traits are not classes. Then doing this we will clarify that the traits and classes must not be polymorphic because they are not.
Stef
-- Using Opera's mail client: http://www.opera.com/mail/
-- Pablo Tesone. tesonep@gmail.com
On 12/10/16 11:48 AM, stepharong wrote:
Dale
I missed your remark about traits. I think that traits are nice because they act as a kind of static macro expansion and really help to get multiple inheritance into single one.
Now ideally I would like to have
(I hate so much this google nonUI)
- state with traits with a nice initialization process. - Now Pablo did a nice and simple implementation of Talents (dynamic traits). I should have a look because if we could unify it and have either a trait statically applied to a class (what we have now) and a trait being applicable to an instance then it would be really good.
Now making the tools traits-aware is much more than just having traits in the language. - change - loading - editing - overloading when we compile a method that comes from a trait we should be able to say that it overrides.....
What we did with the "unification" of traits and classes and the use of traits inside the kernel is a mistake (in Squeak andreas if I recall made Trait a subclass of classDescription and this is not good either - even if he marketed it as a good idea) and we will iterated to remove the use of traits from Class and friends. Then ideally I would like to iterate over the - reflective API (because we should be able to simply access the "class" of a compiledMethod from where the traits is coming from or where it is installed - revisite the implementation because the clause composition.
I think that the tools should not manipulate traits as classes because traits are not classes. Then doing this we will clarify that the traits and classes must not be polymorphic because they are not.
Stef, Thanks for the clarification ... we are open to adding traits to GemStone and perhaps we should talk a little bit more about your ideas on a "better implementation" ... at this point GemStone 3.5 would be the target version and that would give us time for syncing up the implementation. Dale
Dale I missed your remark about traits.I think that traits are nice because they act as a kind of static macro expansion and really help to get multiple inheritance into single one. Now ideally I would like to have (I hate so much this google nonUI)
- state with traits with a nice initialization process. - Now Pablo did a nice and simple implementation of Talents (dynamic traits). I should have a look because if we could unify it and have either a trait statically applied to a class (what we have now) and a trait being applicable to an instance then it would be really good. Now making the tools traits-aware is much more than just having traits in the language. - change - loading - editing - overloading when we compile a method that comes from a trait we should be able to say that it overrides..... What we did with the "unification" of traits and classes and the use of traits inside the kernel is a mistake (in Squeak andreas if I recall made Trait a subclass of classDescription and this is not good either - even if he marketed it as a good idea) and we will iterated to remove the use of traits from Class and friends. Then ideally I would like to iterate over the - reflective API (because we should be able to simply access the "class" of a compiledMethod from where the traits is coming from or where it is installed - revisite the implementation because the clause composition.
I think that the tools should not manipulate traits as classes because traits are not classes.Then doing this we will clarify that the traits and classes must not be polymorphic because they are not.
Stef,
Thanks for the clarification ... we are open to adding traits to GemStone and perhaps we should talk a little bit more about your ideas on a "better implementation" ... at this point GemStone 3.5 >would be the target version and that would give us time for syncing up the implementation.
Sure. This can be a good incentive for us to revisit it. Stef
On 12/11/16 12:06 AM, stepharong wrote:
Dale
I missed your remark about traits. I think that traits are nice because they act as a kind of static macro expansion and really help to get multiple inheritance into single one.
Now ideally I would like to have
(I hate so much this google nonUI)
- state with traits with a nice initialization process. - Now Pablo did a nice and simple implementation of Talents (dynamic traits). I should have a look because if we could unify it and have either a trait statically applied to a class (what we have now) and a trait being applicable to an instance then it would be really good.
Now making the tools traits-aware is much more than just having traits in the language. - change - loading - editing - overloading when we compile a method that comes from a trait we should be able to say that it overrides.....
What we did with the "unification" of traits and classes and the use of traits inside the kernel is a mistake (in Squeak andreas if I recall made Trait a subclass of classDescription and this is not good either - even if he marketed it as a good idea) and we will iterated to remove the use of traits from Class and friends. Then ideally I would like to iterate over the - reflective API (because we should be able to simply access the "class" of a compiledMethod from where the traits is coming from or where it is installed - revisite the implementation because the clause composition.
I think that the tools should not manipulate traits as classes because traits are not classes. Then doing this we will clarify that the traits and classes must not be polymorphic because they are not.
Stef,
Thanks for the clarification ... we are open to adding traits to GemStone and perhaps we should talk a little bit more about your ideas on a "better implementation" ... at this point GemStone 3.5 would be the target version and that would give us time for syncing up the implementation.
Sure. This can be a good incentive for us to revisit it.
Sounds like a plan...
participants (5)
-
Dale Henrichs -
Norbert Hartl -
Stephane Ducasse -
stepharong -
tesonep＠gmail.com