Re: [Pharo-project] Issue 3266 in pharo: Clean TextEditor
Indeed. I mean I can't help, but feel free to go ahead Stef
"I do not think that we can build something on simpleMorphic, what we can do is look at the kernel and see how the changes can be applied to Morphic",
it really means that it should better not be done. It means "I think it can't be done, don't waste your time".
If, instead of that, you say "I can't help, but feel free to go ahead", the reaction of the community will be completely different.
Cheers, Juan Vuletich
IMO SimpleMorphic, minus 'color' ivar in Morph class is a way to go. (i mean get rid that 'color' thing in base class) :) On 24 November 2010 16:49, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Indeed. I mean     I can't help, but feel free to go ahead
Stef
"I do not think that we can build something on simpleMorphic, what we can do is look at the kernel and see how the changes can be applied to Morphic",
it really means that it should better not be done. It means "I think it can't be done, don't waste your time".
If, instead of that, you say "I can't help, but feel free to go ahead", the reaction of the community will be completely different.
Cheers, Juan Vuletich
-- Best regards, Igor Stasenko AKA sig.
On 25 November 2010 03:45, Juan Vuletich <juan@jvuletich.org> wrote:
Igor Stasenko wrote:
IMO SimpleMorphic, minus 'color' ivar in Morph class is a way to go. (i mean get rid that 'color' thing in base class) Â :)
Yep. I fully agree.
I think, for things like Morphic, where there are dozens of various properties expected to be in basic morph class, we should use dictionaries, backed up by clever VM semantics. I cannot stop thinking about extending object format to allow a dynamic number of slots per object, like in self or javascript.
Cheers, Juan Vuletich
-- Best regards, Igor Stasenko AKA sig.
Igor Stasenko wrote:
I think, for things like Morphic, where there are dozens of various properties expected to be in basic morph class, we should use dictionaries, backed up by clever VM semantics. I cannot stop thinking about extending object format to allow a dynamic number of slots per object, like in self or javascript.
That sounds interesting, and I'm sure there are many applications that could benefit from it. Cheers, Juan Vuletich
On Wed, Nov 24, 2010 at 6:10 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 25 November 2010 03:45, Juan Vuletich <juan@jvuletich.org> wrote:
Igor Stasenko wrote:
IMO SimpleMorphic, minus 'color' ivar in Morph class is a way to go. (i mean get rid that 'color' thing in base class) :)
Yep. I fully agree.
I think, for things like Morphic, where there are dozens of various properties expected to be in basic morph class, we should use dictionaries, backed up by clever VM semantics. I cannot stop thinking about extending object format to allow a dynamic number of slots per object, like in self or javascript.
But you don't need to change the object model for this. The VM still supports the mixed format of named and indexed inst vars (e.g. MethodContext) and so you can make an object indexed and store properties in indexed inst vars (e.g. as flattened key, value pairs). The down side is the cost of become, but one can over-allocate, e.g. room for 8 properties so that one becomes only every 8th add. Alternatively have an uninitialized properties inst var which when needed holds a dictionary. Or a global weak dictionary. Or... And of course all these variants can be mixed, e.g. by providing a settable policy in the class so different classes ca do different things. The global properties dictionary can be used as a fallback when one wants to add a property to an instance of a class that doesn't implement one of the other policies. best Eliot
Cheers, Juan Vuletich
-- Best regards, Igor Stasenko AKA sig.
participants (4)
-
Eliot Miranda -
Igor Stasenko -
Juan Vuletich -
Stéphane Ducasse