- Pharo-users - lists.pharo.org

Re: [Pharo-users] Transforming objects

by Richard Sargent

On Wed, Jan 16, 2019 at 9:05 AM LoÃ¯c PagÃ¨s <loic.pages(a)inra.fr> wrote: > Hi Richard, > > You are in the south hemisphere, so ! Temperatures are low here in France. > > Thank you for your comments. > I agree that development is slow if you look at the plant every day, and > in this case we perceive continuous changes. But in models, it might be > convenient to define discrete stages. If you look at a flower bud at a > given date and come back several days (or weeks) after, you can see a > flower at the bud location. This type of approximation is usual in > biological modelling and data acquisition. > > Thank you for the suggestions on the "State" design pattern. I will have a > look ! > LoÃ¯c, the state pattern is one form of composition. You may want to formally model the stages as named attributes or a collection, rather than something that "loses history". (The 0, 1, infinity guideline suggests a collection of stages is more likely the way to go.) Whether all the stages are in the collection from the beginning or whether each as added as development reaches that point is an open question. e.g. (stages at: stage) versus (stages last) to access the "state" in a state pattern implementation. > > LoÃ¯c > > Le 16/01/2019 Ã 13:18, Richard O'Keefe a Ã©crit : > > It seems to me that in the real world, a bud does not get replaced by a > flower > nor a flower by a fruit, nor is there a definite point at which a thing > stops > being a bud and starts being a flower, and so on. It's summer now, but > spring > wasn't that long ago, and I enjoyed watching the imperceptible *continuous* > changes. So anything you do is going to be imposing discontinuity on a > more- > or-less continuous process and is definitely going to be an approximation. > > You may perhaps be looking for the "State" design pattern where there is an > object with a fixed identity (*this* bud/flower/fruit) which behaves > differently at different times, and this is modelled by the "outer" object > delegating some of its behaviour to a "state" which can be replaced. > So you would have > PlantOrgan > PlantReproductiveOrgan (state) > > PlantReproductiveOrganState > Bud > Flower > DeadFlower > ImmatureFruit > MatureFruit > > You will find abundant material about the "State" design pattern on the > web. > > > On Thu, 17 Jan 2019 at 00:29, LoÃ¯c PagÃ¨s <loic.pages(a)inra.fr> wrote: > >> Hi Joachim, >> >> Thank you for your reply and for your ideas. I will reply to your >> questions below. >> >> Le 16/01/2019 Ã 10:25, jtuchel(a)objektfabrik.de a Ã©crit : >> > LoÃ¯c, >> > >> > Am I correct in assuming you are thinking about a model in which a >> > plant can have a growing and shrinking list of organs over time and >> > some of them even have (a growing list of) stages? >> >> Yes, the plant can be seen as a growing and shrinking list of organs. >> Very short list at the beginning, and becoming larger. Some organs can >> fall (leaves, roots) or even be pruned (shoots in fruit trees), so that >> shrinking can also occur. >> >> However, the list of stages for each organ is usually known at the >> beginning, for each type of organ. It depends of knowledge and level of >> detail that we include in the model. >> >> > >> > I am not an expert on the matter, but to me the stages idea sounds >> > good. It even allows for historic information (it was a bud from Date1 >> > to Date2 and since then it is a flower). So transformation would be >> > adding a new Stage and "terminate" the previous one. >> >> This can be an approach. But the conditions for passing from one stage >> to another can be more complex and involve several aspects (age, >> previous growth, pollination, etc) with a lot of code. So, if you keep >> this code into the general "reproductive organ" class, you make a "fat >> class" with a lot of tests. This was not recommended in the Pharo course >> :-) >> >> > >> > With this you can ask a plant about its current stage on the >> > reproductive front and maybe other organs as well at any point time. >> > This may be helpful if you want to build an animation of the plant's >> > development over time. You can have separate life cycles for each organ. >> This is actually an objective of such models, to be able to get the >> status of the whole plant, regarding the stages of organs. >> > >> > Does the plant transform in the real world? I mean, is a cherry tree >> > still a cherry tree, even if it's not blooming any more and carries >> > fruit instead? So why transform the object in its abstract model? >> The plant usually changes because of its development, but a cherry tree >> remains a cherry tree ! And flowers are necessary steps to get fruits >> ! The idea was not to transform the whole plant, but each individual >> organ that it carries. >> > >> > >> > Just a thought, maybe better ideas show up. >> >> OK, thank you again >> >> LoÃ¯c >> >> > >> > >> > >> > Am 16.01.19 um 10:15 schrieb LoÃ¯c PagÃ¨s: >> >> Dear Pharo users, >> >> >> >> I develop software dedicated to the simulation of plant development >> >> and 3D architecture. >> >> >> >> In the past, I used Java, but I am very interested in translating >> >> code in Pharo. I appreciated very much the language and the course. >> >> >> >> I have a question for you all : >> >> >> >> During plant development (ontogeny), new organs appear, that are >> >> gradually tranformed. For example, a bud can make a flower, and then >> >> a fruit. >> >> >> >> Organs are conveniently modelled as classes. During the course, I >> >> learned that it was better to make several classes (bud, flower, >> >> fruit) instead of a "fat class" such as "reproductive organ" with >> >> many attributes and stages (bud stage, flower stage, fruit stage). I >> >> wonder how to transform an object into another one, to represent for >> >> example the fact that the flower may become a fruit. >> >> >> >> Maybe a naive question ? >> >> >> >> Thanks for your lights ! >> >> >> >> LoÃ¯c >> >> >> >> >> >> >> >> >> > >> > >> >> >> >

Jan. 16, 2019

Re: [Pharo-users] Transforming objects

by LoÃ¯c PagÃ¨s

Hi Richard, You are in the south hemisphere, so ! Temperatures are low here in France. Thank you for your comments. I agree that development is slow if you look at the plant every day, and in this case we perceive continuous changes. But in models, it might be convenient to define discrete stages. If you look at a flower bud at a given date and come back several days (or weeks) after, you can see a flower at the bud location. This type of approximation is usual in biological modelling and data acquisition. Thank you for the suggestions on the "State" design pattern. I will have a look ! LoÃ¯c Le 16/01/2019 Ã 13:18, Richard O'Keefe a Ã©critÂ : > It seems to me that in the real world, a bud does not get replaced by > a flower > nor a flower by a fruit, nor is there a definite point at which a > thing stops > being a bud and starts being a flower, and so on.Â It's summer now, > but spring > wasn't that long ago, and I enjoyed watching the imperceptible > *continuous* > changes.Â So anything you do is going to be imposing discontinuity on > a more- > or-less continuous process and is definitely going to be an approximation. > > You may perhaps be looking for the "State" design pattern where there > is an > object with a fixed identity (*this* bud/flower/fruit) which behaves > differently at different times, and this is modelled by the "outer" object > delegating some of its behaviour to a "state" which can be replaced. > So you would have > Â PlantOrgan > PlantReproductiveOrgan (state) > > PlantReproductiveOrganState > Â Â Bud > Â Â Flower > Â Â DeadFlower > Â Â ImmatureFruit > Â Â MatureFruit > > You will find abundant material about the "State" design pattern on > the web. > > > On Thu, 17 Jan 2019 at 00:29, LoÃ¯c PagÃ¨s <loic.pages(a)inra.fr > <mailto:loic.pages@inra.fr>> wrote: > > Hi Joachim, > > Thank you for your reply and for your ideas. I will reply to your > questions below. > > Le 16/01/2019 Ã 10:25, jtuchel(a)objektfabrik.de > <mailto:jtuchel@objektfabrik.de> a Ã©critÂ : > > LoÃ¯c, > > > > Am I correct in assuming you are thinking about a model in which a > > plant can have a growing and shrinking list of organs over time and > > some of them even have (a growing list of) stages? > > Yes, the plant can be seen as a growing and shrinking list of organs. > Very short list at the beginning, and becoming larger. Some organs > can > fall (leaves, roots) or even be pruned (shoots in fruit trees), so > that > shrinking can also occur. > > However, the list of stages for each organ is usually known at the > beginning, for each type of organ. It depends of knowledge and > level of > detail that we include in the model. > > > > > I am not an expert on the matter, but to me the stages idea sounds > > good. It even allows for historic information (it was a bud from > Date1 > > to Date2 and since then it is a flower). So transformation would be > > adding a new Stage and "terminate" the previous one. > > This can be an approach. But the conditions for passing from one > stage > to another can be more complex and involve several aspects (age, > previous growth, pollination, etc) with a lot of code. So, if you > keep > this code into the general "reproductive organ" class, you make a > "fat > class" with a lot of tests. This was not recommended in the Pharo > course > :-) > > > > > With this you can ask a plant about its current stage on the > > reproductive front and maybe other organs as well at any point > time. > > This may be helpful if you want to build an animation of the > plant's > > development over time. You can have separate life cycles for > each organ. > This is actually an objective of such models, to be able to get the > status of the whole plant, regarding the stages of organs. > > > > Does the plant transform in the real world? I mean, is a cherry > tree > > still a cherry tree, even if it's not blooming any more and carries > > fruit instead? So why transform the object in its abstract model? > The plant usually changes because of its development, but a cherry > tree > remains a cherry tree !Â And flowers are necessary steps to get > fruits > !Â The idea was not to transform the whole plant, but each individual > organ that it carries. > > > > > > Just a thought, maybe better ideas show up. > > OK, thank you again > > LoÃ¯c > > > > > > > > > Am 16.01.19 um 10:15 schrieb LoÃ¯c PagÃ¨s: > >> Dear Pharo users, > >> > >> I develop software dedicated to the simulation of plant > development > >> and 3D architecture. > >> > >> In the past, I used Java, but I am very interested in translating > >> code in Pharo. I appreciated very much the language and the course. > >> > >> I have a question for you all : > >> > >> During plant development (ontogeny), new organs appear, that are > >> gradually tranformed. For example, a bud can make a flower, and > then > >> a fruit. > >> > >> Organs are conveniently modelled as classes. During the course, I > >> learned that it was better to make several classes (bud, flower, > >> fruit) instead of a "fat class" such as "reproductive organ" with > >> many attributes and stages (bud stage, flower stage, fruit > stage). I > >> wonder how to transform an object into another one, to > represent for > >> example the fact that the flower may become a fruit. > >> > >> Maybe a naive question ? > >> > >> Thanks for your lights ! > >> > >> LoÃ¯c > >> > >> > >> > >> > > > > > >

Jan. 16, 2019

Re: [Pharo-users] adding instance variables (data) to the Object class

by James Foster

> On Jan 16, 2019, at 6:28 AM, Petr Fischer via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > > From: Petr Fischer <petr.fischer(a)me.com> > Subject: Re: [Pharo-users] adding instance variables (data) to the Object class > Date: January 16, 2019 at 6:28:44 AM PST > To: pharo-users(a)lists.pharo.org > > > Yes, due to the object layouts and strong connection of Object with VM, my idea can not be done that easily. > > I want to add some information (instance variables like OID [object id]) to some objects of any kind (some objects = persistent objects). > > I can do it with map (idenity as key, OID + other info as value), but I was afraid that the map would tend to be enormous. > Now (with all your feedback) I am inclined to think that this (map/dictionary) will be the only way. > > Also - on some systems (like Gemstone), there is "dynamic instance variables" (just key/value pairs) and you can add some information to any object instance you want. I like this, but not possible in Pharo, right? While GemStone allows dynamic instance variables on most objects (to support Ruby), it is not allowed on âspecialâ objects like SmallInteger instances that are encoded completely in the OOP. > > Thanks! pf > > >> I am having a little trouble understanding how adding instance >> variables to Object is supposed to work. Where would an immediate >> object like a SmallInteger *put* such variables? What does it even >> *mean* for 0 and 1 to have instance variables? Do you really want >> to give an extra word of storage to *every* object in your system, >> or to just some, but potentially of any kind? >> >> The usual technique is to use something like a WeakIdentityKeyDictionary. >> >> On Mon, 14 Jan 2019 at 13:54, Petr Fischer via Pharo-users < >> pharo-users(a)lists.pharo.org> wrote: >> >>> It looks like I can't simply add statefull trait to the Object like this: >>> >>> ProtoObject subclass: #Object >>> uses: TMyTrait >>> instanceVariableNames: '' >>> classVariableNames: 'DependentsFields' >>> package: 'Kernel-Objects' >>> >>> After this, Pharo 7 VM goes to 100% of CPU usage, several GB of RAM usage >>> and then crash. >>> >>> Or... what do you mean by "talents"? I found also this: >>> https://github.com/tesonep/pharo-talents >>> >>> Thanks, pf >>> >>> >>>> Talents with statefull traits will help you >>>> >>>> Ð¿Ñ, 7 ÑÐµÐ½Ñ. 2018 Ð³., 9:08 Marcus Denker <marcus.denker(a)inria.fr>: >>>> >>>>> >>>>> >>>>> On 6 Sep 2018, at 23:35, Petr Fischer via Pharo-users < >>>>> pharo-users(a)lists.pharo.org> wrote: >>>>> >>>>> >>>>> *From: *Petr Fischer <petr.fischer(a)me.com> >>>>> *Subject: **adding instance variables (data) to the Object class* >>>>> *Date: *6 September 2018 at 23:35:26 CEST >>>>> *To: *pharo-users(a)lists.pharo.org >>>>> >>>>> >>>>> Hello! Weird question: why I can't add instance variables to the Object >>>>> class (for example "oid" or something else)? Is it due to some internal >>>>> (and different) VM "class layouts"? >>>>> >>>>> Or - can I inject my own information to all existing objects (any >>> class)? >>>>> >>>>> >>>>> Behavior is a subclass of Object, too. So that means that you would >>> add a >>>>> ivar to all the classes, but for the VM an object can only be a class >>> that >>>>> has three ivars, and those >>>>> are accessed by offset. So if you add an ivar, you shift the offset â> >>>>> problem. >>>>> >>>>> As for âI want to add object specific stateâ: it would be nice to add >>> an >>>>> easy to use (and efficient) mechanism to do it. >>>>> >>>>> Marcus >>>>> >>> >>> > > > >

Jan. 16, 2019

Re: [Pharo-users] Transforming objects

by Ben Coman

On Wed, 16 Jan 2019 at 17:16, LoÃ¯c PagÃ¨s <loic.pages(a)inra.fr> wrote: > Dear Pharo users, > > I develop software dedicated to the simulation of plant development and > 3D architecture. > > In the past, I used Java, but I am very interested in translating code > in Pharo. I appreciated very much the language and the course. > > I have a question for you all : > > During plant development (ontogeny), new organs appear, that are > gradually tranformed. For example, a bud can make a flower, and then a > fruit. > > Organs are conveniently modelled as classes. During the course, I > learned that it was better to make several classes (bud, flower, fruit) > instead of a "fat class" such as "reproductive organ" with many > attributes and stages (bud stage, flower stage, fruit stage). I wonder > how to transform an object into another one, to represent for example > the fact that the flower may become a fruit. > > Maybe a naive question ? > Maybe #become: ... https://gbracha.blogspot.com/2009/07/miracle-of-become.html but it might be a misuse for your purpose. The following book will provide some good insights... https://www.amazon.com/Design-Patterns-Smalltalk-Companion/dp/0201184621 cheers -ben

Jan. 16, 2019

Re: [Pharo-users] adding instance variables (data) to the Object class

by Petr Fischer

Yes, due to the object layouts and strong connection of Object with VM, my idea can not be done that easily. I want to add some information (instance variables like OID [object id]) to some objects of any kind (some objects = persistent objects). I can do it with map (idenity as key, OID + other info as value), but I was afraid that the map would tend to be enormous. Now (with all your feedback) I am inclined to think that this (map/dictionary) will be the only way. Also - on some systems (like Gemstone), there is "dynamic instance variables" (just key/value pairs) and you can add some information to any object instance you want. I like this, but not possible in Pharo, right? Thanks! pf > I am having a little trouble understanding how adding instance > variables to Object is supposed to work. Where would an immediate > object like a SmallInteger *put* such variables? What does it even > *mean* for 0 and 1 to have instance variables? Do you really want > to give an extra word of storage to *every* object in your system, > or to just some, but potentially of any kind? > > The usual technique is to use something like a WeakIdentityKeyDictionary. > > On Mon, 14 Jan 2019 at 13:54, Petr Fischer via Pharo-users < > pharo-users(a)lists.pharo.org> wrote: > > > It looks like I can't simply add statefull trait to the Object like this: > > > > ProtoObject subclass: #Object > > uses: TMyTrait > > instanceVariableNames: '' > > classVariableNames: 'DependentsFields' > > package: 'Kernel-Objects' > > > > After this, Pharo 7 VM goes to 100% of CPU usage, several GB of RAM usage > > and then crash. > > > > Or... what do you mean by "talents"? I found also this: > > https://github.com/tesonep/pharo-talents > > > > Thanks, pf > > > > > > > Talents with statefull traits will help you > > > > > > Ð¿Ñ, 7 ÑÐµÐ½Ñ. 2018 Ð³., 9:08 Marcus Denker <marcus.denker(a)inria.fr>: > > > > > > > > > > > > > > > On 6 Sep 2018, at 23:35, Petr Fischer via Pharo-users < > > > > pharo-users(a)lists.pharo.org> wrote: > > > > > > > > > > > > *From: *Petr Fischer <petr.fischer(a)me.com> > > > > *Subject: **adding instance variables (data) to the Object class* > > > > *Date: *6 September 2018 at 23:35:26 CEST > > > > *To: *pharo-users(a)lists.pharo.org > > > > > > > > > > > > Hello! Weird question: why I can't add instance variables to the Object > > > > class (for example "oid" or something else)? Is it due to some internal > > > > (and different) VM "class layouts"? > > > > > > > > Or - can I inject my own information to all existing objects (any > > class)? > > > > > > > > > > > > Behavior is a subclass of Object, too. So that means that you would > > add a > > > > ivar to all the classes, but for the VM an object can only be a class > > that > > > > has three ivars, and those > > > > are accessed by offset. So if you add an ivar, you shift the offset â> > > > > problem. > > > > > > > > As for âI want to add object specific stateâ: it would be nice to add > > an > > > > easy to use (and efficient) mechanism to do it. > > > > > > > > Marcus > > > > > > > >

Jan. 16, 2019

LOOP book title mismatch

by Richard Kenneth Eng

At http://books.pharo.org/learning-oop/, the title is "Learning Object-Oriented Programming, Design *with* TDD *in* Pharo" but the actual PDF has the title "Learning Object-Oriented Programming, Design *and* TDD *with* Pharo". So which title is correct?

Jan. 16, 2019

Re: [Pharo-users] adding instance variables (data) to the Object class

by Richard O'Keefe

I am having a little trouble understanding how adding instance variables to Object is supposed to work. Where would an immediate object like a SmallInteger *put* such variables? What does it even *mean* for 0 and 1 to have instance variables? Do you really want to give an extra word of storage to *every* object in your system, or to just some, but potentially of any kind? The usual technique is to use something like a WeakIdentityKeyDictionary. On Mon, 14 Jan 2019 at 13:54, Petr Fischer via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > It looks like I can't simply add statefull trait to the Object like this: > > ProtoObject subclass: #Object > uses: TMyTrait > instanceVariableNames: '' > classVariableNames: 'DependentsFields' > package: 'Kernel-Objects' > > After this, Pharo 7 VM goes to 100% of CPU usage, several GB of RAM usage > and then crash. > > Or... what do you mean by "talents"? I found also this: > https://github.com/tesonep/pharo-talents > > Thanks, pf > > > > Talents with statefull traits will help you > > > > Ð¿Ñ, 7 ÑÐµÐ½Ñ. 2018 Ð³., 9:08 Marcus Denker <marcus.denker(a)inria.fr>: > > > > > > > > > > > On 6 Sep 2018, at 23:35, Petr Fischer via Pharo-users < > > > pharo-users(a)lists.pharo.org> wrote: > > > > > > > > > *From: *Petr Fischer <petr.fischer(a)me.com> > > > *Subject: **adding instance variables (data) to the Object class* > > > *Date: *6 September 2018 at 23:35:26 CEST > > > *To: *pharo-users(a)lists.pharo.org > > > > > > > > > Hello! Weird question: why I can't add instance variables to the Object > > > class (for example "oid" or something else)? Is it due to some internal > > > (and different) VM "class layouts"? > > > > > > Or - can I inject my own information to all existing objects (any > class)? > > > > > > > > > Behavior is a subclass of Object, too. So that means that you would > add a > > > ivar to all the classes, but for the VM an object can only be a class > that > > > has three ivars, and those > > > are accessed by offset. So if you add an ivar, you shift the offset â> > > > problem. > > > > > > As for âI want to add object specific stateâ: it would be nice to add > an > > > easy to use (and efficient) mechanism to do it. > > > > > > Marcus > > > > >

Jan. 16, 2019

Re: [Pharo-users] Transforming objects

by Esteban Maringolo

This is a challenging modelling issue, life progress or any other dissipative/emergent structure are "restricted" by the boundaries of your objects (e.g. if you model a flock, and it divides into two flocks, and then merges again, which flock remains? Note: I wouldn't model the Flock at all). So it is hard to advice without knowing exactly what the use case is or how the simulation is done, but in the past I had to model a non-organic tree structure that was changing on a daily basis, where each part had it's own attributes and we should be able to query (aka "reconstruct") the "tree structure" at any point in time and query specific parts history, my solution to that was to have an "invariant" identity (E.g. "Plant #1234") and a subtree of elements, where each child wasn't the "organ" directly, but a "node" that contains the "organ" with a starting and an end date (like Joachim suggested) and know the parent "organ" (or the plant itself). In your case, the organs are not going to be transplanted (as was in my case), so the organ/node could be merged into one, which simplifies everything. I don't know if your model has a tree like structure, whether it's a lemon tree or just a dandelion :), so I don't know if, e.g., the flower contains the fruit, or as I understand biology, the plant contains the flower until some point where it stops being a flower and then you replace it by a fruit. I hope it helps you. Esteban A. Maringolo El miÃ©., 16 ene. 2019 a las 9:19, Richard O'Keefe (<raoknz(a)gmail.com>) escribiÃ³: > It seems to me that in the real world, a bud does not get replaced by a > flower > nor a flower by a fruit, nor is there a definite point at which a thing > stops > being a bud and starts being a flower, and so on. It's summer now, but > spring > wasn't that long ago, and I enjoyed watching the imperceptible *continuous* > changes. So anything you do is going to be imposing discontinuity on a > more- > or-less continuous process and is definitely going to be an approximation. > > You may perhaps be looking for the "State" design pattern where there is an > object with a fixed identity (*this* bud/flower/fruit) which behaves > differently at different times, and this is modelled by the "outer" object > delegating some of its behaviour to a "state" which can be replaced. > So you would have > PlantOrgan > PlantReproductiveOrgan (state) > > PlantReproductiveOrganState > Bud > Flower > DeadFlower > ImmatureFruit > MatureFruit > > You will find abundant material about the "State" design pattern on the > web. > > > On Thu, 17 Jan 2019 at 00:29, LoÃ¯c PagÃ¨s <loic.pages(a)inra.fr> wrote: > >> Hi Joachim, >> >> Thank you for your reply and for your ideas. I will reply to your >> questions below. >> >> Le 16/01/2019 Ã 10:25, jtuchel(a)objektfabrik.de a Ã©crit : >> > LoÃ¯c, >> > >> > Am I correct in assuming you are thinking about a model in which a >> > plant can have a growing and shrinking list of organs over time and >> > some of them even have (a growing list of) stages? >> >> Yes, the plant can be seen as a growing and shrinking list of organs. >> Very short list at the beginning, and becoming larger. Some organs can >> fall (leaves, roots) or even be pruned (shoots in fruit trees), so that >> shrinking can also occur. >> >> However, the list of stages for each organ is usually known at the >> beginning, for each type of organ. It depends of knowledge and level of >> detail that we include in the model. >> >> > >> > I am not an expert on the matter, but to me the stages idea sounds >> > good. It even allows for historic information (it was a bud from Date1 >> > to Date2 and since then it is a flower). So transformation would be >> > adding a new Stage and "terminate" the previous one. >> >> This can be an approach. But the conditions for passing from one stage >> to another can be more complex and involve several aspects (age, >> previous growth, pollination, etc) with a lot of code. So, if you keep >> this code into the general "reproductive organ" class, you make a "fat >> class" with a lot of tests. This was not recommended in the Pharo course >> :-) >> >> > >> > With this you can ask a plant about its current stage on the >> > reproductive front and maybe other organs as well at any point time. >> > This may be helpful if you want to build an animation of the plant's >> > development over time. You can have separate life cycles for each organ. >> This is actually an objective of such models, to be able to get the >> status of the whole plant, regarding the stages of organs. >> > >> > Does the plant transform in the real world? I mean, is a cherry tree >> > still a cherry tree, even if it's not blooming any more and carries >> > fruit instead? So why transform the object in its abstract model? >> The plant usually changes because of its development, but a cherry tree >> remains a cherry tree ! And flowers are necessary steps to get fruits >> ! The idea was not to transform the whole plant, but each individual >> organ that it carries. >> > >> > >> > Just a thought, maybe better ideas show up. >> >> OK, thank you again >> >> LoÃ¯c >> >> > >> > >> > >> > Am 16.01.19 um 10:15 schrieb LoÃ¯c PagÃ¨s: >> >> Dear Pharo users, >> >> >> >> I develop software dedicated to the simulation of plant development >> >> and 3D architecture. >> >> >> >> In the past, I used Java, but I am very interested in translating >> >> code in Pharo. I appreciated very much the language and the course. >> >> >> >> I have a question for you all : >> >> >> >> During plant development (ontogeny), new organs appear, that are >> >> gradually tranformed. For example, a bud can make a flower, and then >> >> a fruit. >> >> >> >> Organs are conveniently modelled as classes. During the course, I >> >> learned that it was better to make several classes (bud, flower, >> >> fruit) instead of a "fat class" such as "reproductive organ" with >> >> many attributes and stages (bud stage, flower stage, fruit stage). I >> >> wonder how to transform an object into another one, to represent for >> >> example the fact that the flower may become a fruit. >> >> >> >> Maybe a naive question ? >> >> >> >> Thanks for your lights ! >> >> >> >> LoÃ¯c >> >> >> >> >> >> >> >> >> > >> > >> >> >>

Jan. 16, 2019

Re: [Pharo-users] Transforming objects

by Richard O'Keefe

It seems to me that in the real world, a bud does not get replaced by a flower nor a flower by a fruit, nor is there a definite point at which a thing stops being a bud and starts being a flower, and so on. It's summer now, but spring wasn't that long ago, and I enjoyed watching the imperceptible *continuous* changes. So anything you do is going to be imposing discontinuity on a more- or-less continuous process and is definitely going to be an approximation. You may perhaps be looking for the "State" design pattern where there is an object with a fixed identity (*this* bud/flower/fruit) which behaves differently at different times, and this is modelled by the "outer" object delegating some of its behaviour to a "state" which can be replaced. So you would have PlantOrgan PlantReproductiveOrgan (state) PlantReproductiveOrganState Bud Flower DeadFlower ImmatureFruit MatureFruit You will find abundant material about the "State" design pattern on the web. On Thu, 17 Jan 2019 at 00:29, LoÃ¯c PagÃ¨s <loic.pages(a)inra.fr> wrote: > Hi Joachim, > > Thank you for your reply and for your ideas. I will reply to your > questions below. > > Le 16/01/2019 Ã 10:25, jtuchel(a)objektfabrik.de a Ã©crit : > > LoÃ¯c, > > > > Am I correct in assuming you are thinking about a model in which a > > plant can have a growing and shrinking list of organs over time and > > some of them even have (a growing list of) stages? > > Yes, the plant can be seen as a growing and shrinking list of organs. > Very short list at the beginning, and becoming larger. Some organs can > fall (leaves, roots) or even be pruned (shoots in fruit trees), so that > shrinking can also occur. > > However, the list of stages for each organ is usually known at the > beginning, for each type of organ. It depends of knowledge and level of > detail that we include in the model. > > > > > I am not an expert on the matter, but to me the stages idea sounds > > good. It even allows for historic information (it was a bud from Date1 > > to Date2 and since then it is a flower). So transformation would be > > adding a new Stage and "terminate" the previous one. > > This can be an approach. But the conditions for passing from one stage > to another can be more complex and involve several aspects (age, > previous growth, pollination, etc) with a lot of code. So, if you keep > this code into the general "reproductive organ" class, you make a "fat > class" with a lot of tests. This was not recommended in the Pharo course > :-) > > > > > With this you can ask a plant about its current stage on the > > reproductive front and maybe other organs as well at any point time. > > This may be helpful if you want to build an animation of the plant's > > development over time. You can have separate life cycles for each organ. > This is actually an objective of such models, to be able to get the > status of the whole plant, regarding the stages of organs. > > > > Does the plant transform in the real world? I mean, is a cherry tree > > still a cherry tree, even if it's not blooming any more and carries > > fruit instead? So why transform the object in its abstract model? > The plant usually changes because of its development, but a cherry tree > remains a cherry tree ! And flowers are necessary steps to get fruits > ! The idea was not to transform the whole plant, but each individual > organ that it carries. > > > > > > Just a thought, maybe better ideas show up. > > OK, thank you again > > LoÃ¯c > > > > > > > > > Am 16.01.19 um 10:15 schrieb LoÃ¯c PagÃ¨s: > >> Dear Pharo users, > >> > >> I develop software dedicated to the simulation of plant development > >> and 3D architecture. > >> > >> In the past, I used Java, but I am very interested in translating > >> code in Pharo. I appreciated very much the language and the course. > >> > >> I have a question for you all : > >> > >> During plant development (ontogeny), new organs appear, that are > >> gradually tranformed. For example, a bud can make a flower, and then > >> a fruit. > >> > >> Organs are conveniently modelled as classes. During the course, I > >> learned that it was better to make several classes (bud, flower, > >> fruit) instead of a "fat class" such as "reproductive organ" with > >> many attributes and stages (bud stage, flower stage, fruit stage). I > >> wonder how to transform an object into another one, to represent for > >> example the fact that the flower may become a fruit. > >> > >> Maybe a naive question ? > >> > >> Thanks for your lights ! > >> > >> LoÃ¯c > >> > >> > >> > >> > > > > > > >

Jan. 16, 2019

Re: [Pharo-users] Transforming objects

by LoÃ¯c PagÃ¨s

Hi Joachim, Thank you for your reply and for your ideas. I will reply to your questions below. Le 16/01/2019 Ã 10:25, jtuchel(a)objektfabrik.de a Ã©critÂ : > LoÃ¯c, > > Am I correct in assuming you are thinking about a model in which a > plant can have a growing and shrinking list of organs over time and > some of them even have (a growing list of) stages? Yes, the plant can be seen as a growing and shrinking list of organs. Very short list at the beginning, and becoming larger. Some organs can fall (leaves, roots) or even be pruned (shoots in fruit trees), so that shrinking can also occur. However, the list of stages for each organ is usually known at the beginning, for each type of organ. It depends of knowledge and level of detail that we include in the model. > > I am not an expert on the matter, but to me the stages idea sounds > good. It even allows for historic information (it was a bud from Date1 > to Date2 and since then it is a flower). So transformation would be > adding a new Stage and "terminate" the previous one. This can be an approach. But the conditions for passing from one stage to another can be more complex and involve several aspects (age, previous growth, pollination, etc) with a lot of code. So, if you keep this code into the general "reproductive organ" class, you make a "fat class" with a lot of tests. This was not recommended in the Pharo course :-) > > With this you can ask a plant about its current stage on the > reproductive front and maybe other organs as well at any point time. > This may be helpful if you want to build an animation of the plant's > development over time. You can have separate life cycles for each organ. This is actually an objective of such models, to be able to get the status of the whole plant, regarding the stages of organs. > > Does the plant transform in the real world? I mean, is a cherry tree > still a cherry tree, even if it's not blooming any more and carries > fruit instead? So why transform the object in its abstract model? The plant usually changes because of its development, but a cherry tree remains a cherry tree !Â And flowers are necessary steps to get fruits !Â The idea was not to transform the whole plant, but each individual organ that it carries. > > > Just a thought, maybe better ideas show up. OK, thank you again LoÃ¯c > > > > Am 16.01.19 um 10:15 schrieb LoÃ¯c PagÃ¨s: >> Dear Pharo users, >> >> I develop software dedicated to the simulation of plant development >> and 3D architecture. >> >> In the past, I used Java, but I am very interested in translating >> code in Pharo. I appreciated very much the language and the course. >> >> I have a question for you all : >> >> During plant development (ontogeny), new organs appear, that are >> gradually tranformed. For example, a bud can make a flower, and then >> a fruit. >> >> Organs are conveniently modelled as classes. During the course, I >> learned that it was better to make several classes (bud, flower, >> fruit) instead of a "fat class" such as "reproductive organ" with >> many attributes and stages (bud stage, flower stage, fruit stage). I >> wonder how to transform an object into another one, to represent for >> example the fact that the flower may become a fruit. >> >> Maybe a naive question ? >> >> Thanks for your lights ! >> >> LoÃ¯c >> >> >> >> > >

Jan. 16, 2019