Traits for class methods?
Hi everyone, A quick question: is it possible to use traits to define class methods? For example, could the popular singleton pattern consisting of the three class methods #uniqueInstance, #new, and #reset plus the instance variable uniqueInstance be packaged as a trait? Konrad.
On Mon, Feb 11, 2019 at 4:50 PM Konrad Hinsen <konrad.hinsen@fastmail.net> wrote:
Hi everyone,
A quick question: is it possible to use traits to define class methods?
For example, could the popular singleton pattern consisting of the three class methods #uniqueInstance, #new, and #reset plus the instance variable uniqueInstance be packaged as a trait?
Hi, Yes it is possible.
Konrad.
-- Cyril Ferlicot https://ferlicot.fr
It seems, however, that self points to the trait class, instead of the target object class. Is that correct? Instance side methods behave as expected and self points to the target object. On Mon, Feb 11, 2019 at 2:19 PM Cyril Ferlicot <cyril.ferlicot@gmail.com> wrote:
On Mon, Feb 11, 2019 at 4:50 PM Konrad Hinsen <konrad.hinsen@fastmail.net> wrote:
Hi everyone,
A quick question: is it possible to use traits to define class methods?
For example, could the popular singleton pattern consisting of the three class methods #uniqueInstance, #new, and #reset plus the instance variable uniqueInstance be packaged as a trait?
Hi,
Yes it is possible.
Konrad.
-- Cyril Ferlicot https://ferlicot.fr
Rectifying, It does as expected and self points to the target class. This odd behavior happened to me when I implemented the initialize method on the class side of a Trait and then clicked the 'Run Script' Button on the target class. On Mon, Feb 11, 2019 at 4:52 PM Vitor Medina Cruz <vitormcruz@gmail.com> wrote:
It seems, however, that self points to the trait class, instead of the target object class. Is that correct? Instance side methods behave as expected and self points to the target object.
On Mon, Feb 11, 2019 at 2:19 PM Cyril Ferlicot <cyril.ferlicot@gmail.com> wrote:
On Mon, Feb 11, 2019 at 4:50 PM Konrad Hinsen <konrad.hinsen@fastmail.net> wrote:
Hi everyone,
A quick question: is it possible to use traits to define class methods?
For example, could the popular singleton pattern consisting of the three class methods #uniqueInstance, #new, and #reset plus the instance variable uniqueInstance be packaged as a trait?
Hi,
Yes it is possible.
Konrad.
-- Cyril Ferlicot https://ferlicot.fr
On 11/02/2019 17:18, Cyril Ferlicot wrote:
A quick question: is it possible to use traits to define class methods?
For example, could the popular singleton pattern consisting of the three class methods #uniqueInstance, #new, and #reset plus the instance variable uniqueInstance be packaged as a trait? Hi,
Yes it is possible.
Thanks for your encouragement! I ended up trying exactly that example, and it works just fine: Â Â Â https://github.com/khinsen/SingletonTrait Konrad.
On 13 Feb 2019, at 12:22, Konrad Hinsen <konrad.hinsen@fastmail.net> wrote:
On 11/02/2019 17:18, Cyril Ferlicot wrote:
A quick question: is it possible to use traits to define class methods?
For example, could the popular singleton pattern consisting of the three class methods #uniqueInstance, #new, and #reset plus the instance variable uniqueInstance be packaged as a trait? Hi,
Yes it is possible.
Thanks for your encouragement!
I ended up trying exactly that example, and it works just fine:
It is amazing how much better this feels now that Traits can define state, too⦠(compared to before where it was just methods). https://github.com/khinsen/SingletonTrait/blob/master/SingletonTrait/Singlet... I would even want to have (and use) a Trait like that in the system by default. Marcus
I am wondering. Does it not make responsabilities less clear, shareed in class hierarchy and traits hierarchy, now both in term of behavior but also state? Hilaire Le 13/02/2019 à 13:02, Marcus Denker a écrit :
It is amazing how much better this feels now that Traits can define state, too⦠(compared to before where it was just methods).
https://github.com/khinsen/SingletonTrait/blob/master/SingletonTrait/Singlet...
I would even want to have (and use) a Trait like that in the system by default.
Marcus
-- Dr. Geo http://drgeo.eu
On Wed, Feb 13, 2019 at 2:40 PM Hilaire <hilaire@drgeo.eu> wrote:
I am wondering. Does it not make responsabilities less clear, shareed in class hierarchy and traits hierarchy, now both in term of behavior but also state?
Hi, In general I do not choose between inheritance and composition based on what the language allows. When we had stateless traits, I created subclasses even if I was not using any state, because it made sense. I'm not a big fan of limiting the language on composition because the choice between composition and inheritance should be conceptual and not technical. I read in an article this way to choose between inheritance and composition: «Inheritance should only be used when: - Both classes are in the same logical domain - The subclass is a proper subtype of the superclass - The superclassâs implementation is necessary or appropriate for the subclass - The enhancements made by the subclass are primarily additive.»
Hilaire
-- Dr. Geo http://drgeo.eu
-- Cyril Ferlicot https://ferlicot.fr
On 13. 2. 2019 14:54, Cyril Ferlicot wrote:
On Wed, Feb 13, 2019 at 2:40 PM Hilaire <hilaire@drgeo.eu> wrote:
I am wondering. Does it not make responsabilities less clear, shareed in class hierarchy and traits hierarchy, now both in term of behavior but also state?
Hi,
In general I do not choose between inheritance and composition based on what the language allows. When we had stateless traits, I created subclasses even if I was not using any state, because it made sense.
I'm not a big fan of limiting the language on composition because the choice between composition and inheritance should be conceptual and not technical.
Sorry for the unconstructive and spammy "I like it" post, but: +1!
I read in an article this way to choose between inheritance and composition:
«Inheritance should only be used when: - Both classes are in the same logical domain - The subclass is a proper subtype of the superclass - The superclassâs implementation is necessary or appropriate for the subclass - The enhancements made by the subclass are primarily additive.»
Hilaire
-- Dr. Geo http://drgeo.eu
Cyril Ferlicot <cyril.ferlicot@gmail.com> wrote:
I'm not a big fan of limiting the language on composition because the choice between composition and inheritance should be conceptual and not technical.
I read in an article this way to choose between inheritance and composition:
An alternative (Smalltalk) view is that inheritance is primarily a code reuse instrument. Use it when it allows you to do so. Java and c++ deformed a lot of OO thinking Stephan
Marcus Denker <marcus.denker@inria.fr> writes:
It is amazing how much better this feels now that Traits can define state, too⦠(compared to before where it was just methods).
https://github.com/khinsen/SingletonTrait/blob/master/SingletonTrait/Singlet...
I would even want to have (and use) a Trait like that in the system by default.
That's what I thought as well when I saw the 43 implementors of uniqueInstance in Pharo. I'll package this as a pull request for Pharo! Konrad.
With singleton you will access class variable, which you can't with a trait, so you will need a setter, but should work I guess Hilaire -- Dr. Geo http://drgeo.eu
On Mon 11 Feb 2019 at 20:36, Hilaire <hilaire@drgeo.eu> wrote:
With singleton you will access class variable, which you can't with a trait, so you will need a setter, but should work I guess
Hi, Since Pharo 7, Traits are statefuls. See documentation at: https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/T...
Hilaire
-- Dr. Geo http://drgeo.eu
--
Cyril Ferlicot https://ferlicot.fr
Thanks for the update. Took a look at the doc bellow. To my taste, this traits design really add complexity in the code, particularly in responsibility and now the state. While it could be useful in some situation. Le 11/02/2019 à 20:37, Cyril Ferlicot a écrit :
Hi,
Since Pharo 7, Traits are statefuls.Â
See documentation at:Â https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/T...
-- Dr. Geo http://drgeo.eu
participants (7)
-
Cyril Ferlicot -
Herby VojÄÃk -
Hilaire -
Konrad Hinsen -
Marcus Denker -
Stephan Eggermont -
Vitor Medina Cruz