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. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Use of #asMorph
|
|
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 |
Re: [squeak-dev] Use of #asMorph
|
|
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. > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [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. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [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. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |