if you use an object model a la Self, there is no difference between an instance variable and a method from the "sender" point of view. So, in this code "self name", name could be implemented as a "data slot" (a slot that references an object) or a "method slot", it is up to the receiver. So, the sender always sends the message #name, no matter if name is implemented as method or "variable". At the end it is not first class slots what solves the problem but the uniformity of using only message send to represent computation (no variable assingments, etc). So, going to the trait example, if the trait says "self name", the class that uses that trait could implement "name" as a data slot or method slot, it does not matter to the trait and therefore the trait is state agnostic... at least that is what I understood from Stef comment :-), but may be he meant other thing! :-) On Thu, Feb 16, 2012 at 2:11 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Thu, Feb 16, 2012 at 3:04 PM, Hernan Wilkinson < hernan.wilkinson@10pines.com> wrote:
I have an idea about the state issue in traits, maybe you thought about it too... I was thinking that the definition of representing something as state or not should be responsibility of the implementation, that is the class (nothing new here), so we delay that decision until the trait is used. So, maybe what we need is a way to indicate that a message send in a trait is not really that in a class... For example:
TraitA>>m1
^self name first
Object subclass: #ClassA uses: #TraitA mapping: (MessageSendToInstanceVariable from: #name to: 'firstName') ... bla bla.
So, #m1 in ClassA would look like:
ClassA>>m1
^firstName first
Of course this implies some complexity when copying the behavior from the trait to the class (we can not use the same compiled method), also maintaining the relationship with changes on the trait (what happens if #m1 is changed in TraitA and does not send #name anymore), etc. First class slot (a la Self) would be a nicer solution,
For the slower ones ... why would first class slots solves this? I didn't get it.
Thanks!
but I feel that that implies a more radical change on the object model, vm, etc. and also has the disadvantages of making all state public (unless something is done to avoid that).
At the same time, I would like to point out that having subclassing and traits at the same time as sharing mechanism is kind of confusing, programmers do not know which one is better to use, should I subclass or use a trait? how I'm sure which one is better? etc. We talk about this when you came to Argentina, do you remember? A student did his tesis about removing subclassing and using only traits as sharing tool, but the results were not as good as I expected (sadly, the thesis is written in Spanish...)
Anyway, my two cents Hernan.
On Thu, Feb 16, 2012 at 4:56 AM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
On Feb 15, 2012, at 11:30 PM, Hernan Wilkinson wrote:
what is the difference with the current trait implementation in pharo? I could not see the differenceâ¦
Stefan replied but what I wanted to say is that I would like to have the time to see how we can introduce more nicely traits. Right now there are edges where this is ugly and also rethink the system. I think that if we would have first class slots we could have traits with state in a much better fashion.
Stef
On Wed, Feb 15, 2012 at 7:45 AM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote: Indeed. Now I would love that we rethink our trait implementation and tool support but no time.
On Feb 15, 2012, at 6:40 AM, blake wrote:
This is kinda cool:
-- Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina
-- *Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina
-- Mariano http://marianopeck.wordpress.com
-- *Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina