Use of #asMorph
Locked
 
|
Hello, lists
i'd like to ask an intricate question. Suppose that your morph acts as a container, which needs to hold an items, retrieved from a model object. A model's elements could be any object, and may choose to represent them in a way they like it. So, for instance, if we taking a list, the list elements is represented by a morphs not simple strings. Now, a question: is it fine to use #asMorph as a message to 'convert' a model's item to a morph, which then can be used to reflect given item in list? I.e. something like: model itemsDo: [:item | self addMorph: item asMorph ] In this way, a list is built from morphs, and each list item choosing by itself, what morph should be used to represent itself in a list. But by saying A, we usually need to say B: an object could choose different representation depending on container's properties: model itemsDo: [:item | self addMorph: (item asMorphIn: self) ] So, for example, a compiled method, could choose to represent itself in a list as a simple string with own selector, while in text editor it could choose to display own source code. What you would do in such case? -- Best regards, Igor Stasenko AKA sig. |
|
|
> model itemsDo: [:item |
> self addMorph: (item asMorphIn: self) ] this one seems the right one for me, although it wouldn't hurt if the morph purpose was stated even more explicitely: model itemsDo: [:item | self addMorph: (item asMorphItemIn: self) ] my 2 cents Stef |
|
|
2010/3/14 Stéphane Rollandin <[hidden email]>:
>> model itemsDo: [:item | >> self addMorph: (item asMorphIn: self) ] > > this one seems the right one for me, although it wouldn't hurt if the morph > purpose was stated even more explicitely: > > model itemsDo: [:item | > self addMorph: (item asMorphItemIn: self) ] > yes, i am also thought about specializing it like: self addMorph: (item asMorphInList: self) or self addMorph: (item asMorphInMenu: self) and so on.. keep in mind, that you need to make all objects to respond to such messages, which leads to explosion of such methods and their implementations in Object class and many of its subclasses. Too bad, smalltalk doesn't have multiple dispatch, so i cant define a single method for a number of method's arguments, not just for receiver. Then a method lookup would be based on two objects: list + compiled method menu + string etc. But its still possible when using a single dispatch, just specialize later: when container sending: item asMorphIn: container a receiver implements it as: ^ container morphForCompiledMethod: self so, then container chooses, which morph could be used to represent a compiled method in itself. The problem, that in this case, one should add such method in a container class. Which obviously creates a dilemma, since decision, what kind of morph should represent an item is equally shared between container and item, while using only a single side, to be responsible for it, creating a discrimination. > my 2 cents > > Stef > -- Best regards, Igor Stasenko AKA sig. |
|
|
In reply to this post by Igor Stasenko
Igor
I do not know (I'm dizzy after a couple of hours of bus) but asMorph for me conveys the idea that we get a transformation of the receiver, while if this is just to change the model of a morph why not model: Stef |
|
|
On 14 March 2010 14:40, stephane ducasse <[hidden email]> wrote:
> Igor > > I do not know (I'm dizzy after a couple of hours of bus) but > asMorph for me conveys the idea that we get a transformation of the receiver, while if this is just to > change the model of a morph why not model: > Changing a model gives nothing: morph := MyListMorph new. morph model: someModel. now, since my morph is a list, it assumes that someModel object implements a protocol, which allows to extract the items ( #size, #at: etc). The question is, what you would do, if you want to represent each item in a list as a morph, so instead of: strings := model items collect: [:each | each asString ]. you doing: subMorphs := model items collect: [:each | each asMorph ]. ... this gives you a freedom to pick any form how represent each item in a list, instead of bare strings. > > Stef > -- Best regards, Igor Stasenko AKA sig. |
|
|
I'm not convinced by your argumentation.
Stef On Mar 14, 2010, at 2:05 PM, Igor Stasenko wrote: > On 14 March 2010 14:40, stephane ducasse <[hidden email]> wrote: >> Igor >> >> I do not know (I'm dizzy after a couple of hours of bus) but >> asMorph for me conveys the idea that we get a transformation of the receiver, while if this is just to >> change the model of a morph why not model: >> > Changing a model gives nothing: > > morph := MyListMorph new. > morph model: someModel. > > now, since my morph is a list, it assumes that someModel object > implements a protocol, which allows to extract the > items ( #size, #at: etc). > The question is, what you would do, if you want to represent each item > in a list as a morph, so instead of: > > strings := model items collect: [:each | each asString ]. > > you doing: > > subMorphs := model items collect: [:each | each asMorph ]. > ... > this gives you a freedom to pick any form how represent each item in a > list, instead of bare strings. > > >> >> Stef >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > |
|
|
In reply to this post by Igor Stasenko
I'm not convinced by your argumentation. Because #('a' 'b') collect: [:each | each asMorph] would mean to me that you get StringMorph or some morph representation of the object. If this is what you want why not but I thought you talk about container containee relationship/ Stef On Mar 14, 2010, at 2:05 PM, Igor Stasenko wrote: > On 14 March 2010 14:40, stephane ducasse <[hidden email]> wrote: >> Igor >> >> I do not know (I'm dizzy after a couple of hours of bus) but >> asMorph for me conveys the idea that we get a transformation of the receiver, while if this is just to >> change the model of a morph why not model: >> > Changing a model gives nothing: > > morph := MyListMorph new. > morph model: someModel. > > now, since my morph is a list, it assumes that someModel object > implements a protocol, which allows to extract the > items ( #size, #at: etc). > The question is, what you would do, if you want to represent each item > in a list as a morph, so instead of: > > strings := model items collect: [:each | each asString ]. > > you doing: > > subMorphs := model items collect: [:each | each asMorph ]. > ... > this gives you a freedom to pick any form how represent each item in a > list, instead of bare strings. > > >> >> Stef >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > |
Re: [Pharo-project] [squeak-dev] Use of #asMorph
|
|
On 14 March 2010 15:38, Stéphane Ducasse <[hidden email]> wrote:
> > I'm not convinced by your argumentation. > Because > #('a' 'b') collect: [:each | each asMorph] > would mean to me that you get StringMorph or some morph representation of the object. Yes, exactly like that. And i want to find a convenient approach how to achieve that. Means , that from one side we having a container (list, inspector, panel, window etc) and from other side, we having a model which is a collection of items. And i want to find a way, how an object, which you want to represent in a container, could pick a most appropriate form of its representation, BUT depending on a nature of container. > If this is what you want why not but I thought you talk about container containee relationship/ > I am not convinced myself that such way is feasible either. You tell :) Usually, in most cases, a container dictating how its items should be displayed and behave. And usually, a model knows more than a little about items it contains (for instance a class methods pane contains only methods, not arbitrary objects). > > > Stef > > > On Mar 14, 2010, at 2:05 PM, Igor Stasenko wrote: > >> On 14 March 2010 14:40, stephane ducasse <[hidden email]> wrote: >>> Igor >>> >>> I do not know (I'm dizzy after a couple of hours of bus) but >>> asMorph for me conveys the idea that we get a transformation of the receiver, while if this is just to >>> change the model of a morph why not model: >>> >> Changing a model gives nothing: >> >> morph := MyListMorph new. >> morph model: someModel. >> >> now, since my morph is a list, it assumes that someModel object >> implements a protocol, which allows to extract the >> items ( #size, #at: etc). >> The question is, what you would do, if you want to represent each item >> in a list as a morph, so instead of: >> >> strings := model items collect: [:each | each asString ]. >> >> you doing: >> >> subMorphs := model items collect: [:each | each asMorph ]. >> ... >> this gives you a freedom to pick any form how represent each item in a >> list, instead of bare strings. >> >> >>> >>> Stef >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. |
Re: [Pharo-project] [squeak-dev] Use of #asMorph
|
|
On Mar 14, 2010, at 3:04 PM, Igor Stasenko wrote: > On 14 March 2010 15:38, Stéphane Ducasse <[hidden email]> wrote: >> >> I'm not convinced by your argumentation. >> Because >> #('a' 'b') collect: [:each | each asMorph] >> would mean to me that you get StringMorph or some morph representation of the object. > > Yes, exactly like that. > And i want to find a convenient approach how to achieve that. Means , > that from one side we having > a container (list, inspector, panel, window etc) and from other side, > we having a model which is a collection of items. > And i want to find a way, how an object, which you want to represent > in a container, could pick a most appropriate form > of its representation, BUT depending on a nature of container. it smells like a lot of magic or double dispatch? > >> If this is what you want why not but I thought you talk about container containee relationship/ >> > > I am not convinced myself that such way is feasible either. You tell :) > Usually, in most cases, a container dictating how its items should be > displayed and behave. > And usually, a model knows more than a little about items it contains > (for instance a class methods pane contains only methods, not > arbitrary objects). > >> >> >> Stef >> >> >> On Mar 14, 2010, at 2:05 PM, Igor Stasenko wrote: >> >>> On 14 March 2010 14:40, stephane ducasse <[hidden email]> wrote: >>>> Igor >>>> >>>> I do not know (I'm dizzy after a couple of hours of bus) but >>>> asMorph for me conveys the idea that we get a transformation of the receiver, while if this is just to >>>> change the model of a morph why not model: >>>> >>> Changing a model gives nothing: >>> >>> morph := MyListMorph new. >>> morph model: someModel. >>> >>> now, since my morph is a list, it assumes that someModel object >>> implements a protocol, which allows to extract the >>> items ( #size, #at: etc). >>> The question is, what you would do, if you want to represent each item >>> in a list as a morph, so instead of: >>> >>> strings := model items collect: [:each | each asString ]. >>> >>> you doing: >>> >>> subMorphs := model items collect: [:each | each asMorph ]. >>> ... >>> this gives you a freedom to pick any form how represent each item in a >>> list, instead of bare strings. >>> >>> >>>> >>>> Stef >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [Pharo-project] [squeak-dev] Use of #asMorph
|
|
On 14 March 2010 19:42, Stéphane Ducasse <[hidden email]> wrote:
> > On Mar 14, 2010, at 3:04 PM, Igor Stasenko wrote: > >> On 14 March 2010 15:38, Stéphane Ducasse <[hidden email]> wrote: >>> >>> I'm not convinced by your argumentation. >>> Because >>> #('a' 'b') collect: [:each | each asMorph] >>> would mean to me that you get StringMorph or some morph representation of the object. >> >> Yes, exactly like that. >> And i want to find a convenient approach how to achieve that. Means , >> that from one side we having >> a container (list, inspector, panel, window etc) and from other side, >> we having a model which is a collection of items. >> And i want to find a way, how an object, which you want to represent >> in a container, could pick a most appropriate form >> of its representation, BUT depending on a nature of container. > > it smells like a lot of magic or double dispatch? Yes, it is a double dispatch. But the problem who will take a first half and who is second, i.e. will message should come in object(item) -> container direction or container -> object(item). >> >>> If this is what you want why not but I thought you talk about container containee relationship/ >>> >> >> I am not convinced myself that such way is feasible either. You tell :) >> Usually, in most cases, a container dictating how its items should be >> displayed and behave. >> And usually, a model knows more than a little about items it contains >> (for instance a class methods pane contains only methods, not >> arbitrary objects). >> >>> >>> >>> Stef >>> >>> >>> On Mar 14, 2010, at 2:05 PM, Igor Stasenko wrote: >>> >>>> On 14 March 2010 14:40, stephane ducasse <[hidden email]> wrote: >>>>> Igor >>>>> >>>>> I do not know (I'm dizzy after a couple of hours of bus) but >>>>> asMorph for me conveys the idea that we get a transformation of the receiver, while if this is just to >>>>> change the model of a morph why not model: >>>>> >>>> Changing a model gives nothing: >>>> >>>> morph := MyListMorph new. >>>> morph model: someModel. >>>> >>>> now, since my morph is a list, it assumes that someModel object >>>> implements a protocol, which allows to extract the >>>> items ( #size, #at: etc). >>>> The question is, what you would do, if you want to represent each item >>>> in a list as a morph, so instead of: >>>> >>>> strings := model items collect: [:each | each asString ]. >>>> >>>> you doing: >>>> >>>> subMorphs := model items collect: [:each | each asMorph ]. >>>> ... >>>> this gives you a freedom to pick any form how represent each item in a >>>> list, instead of bare strings. >>>> >>>> >>>>> >>>>> Stef >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |