Transforming objects

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Transforming objects

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



Reply | Threaded
Open this post in threaded view
|

Re: Transforming objects

jtuchel
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?

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.

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.

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?


Just a thought, maybe better ideas show up.

Joachim


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
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Transforming objects

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, [hidden email] 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
>>
>>
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Transforming objects

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 <[hidden email]> 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, [hidden email] 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
>>
>>
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Transforming objects

Esteban A. 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 (<[hidden email]>) 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 <[hidden email]> 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, [hidden email] 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
>>
>>
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Transforming objects

Pharo Smalltalk Users mailing list
In reply to this post by Loïc Pagès


On Wed, 16 Jan 2019 at 17:16, Loïc Pagès <[hidden email]> 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: ...

but it might be a misuse for your purpose.  The following book will provide some good insights...

cheers -ben


 
Reply | Threaded
Open this post in threaded view
|

Re: Transforming objects

Loïc Pagès
In reply to this post by Richard O'Keefe
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 <[hidden email]> 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, [hidden email] 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
>>
>>
>>
>>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Transforming objects

Richard Sargent
Administrator


On Wed, Jan 16, 2019 at 9:05 AM Loïc Pagès <[hidden email]> 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 <[hidden email]> 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, [hidden email] 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
>>
>>
>>
>>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Transforming objects

Esteban A. Maringolo
In reply to this post by Pharo Smalltalk Users mailing list
El mié., 16 ene. 2019 a las 14:49, Ben Coman via Pharo-users (<[hidden email]>) escribió:


On Wed, 16 Jan 2019 at 17:16, Loïc Pagès <[hidden email]> wrote:

Maybe a naive question ?

Maybe #become: ...


Although miraculous, using #become: to model a business domain is harmful, and has more undesired side effects than benefits.

So I would save it to a very limited use case scenarios, which are more related with low level stuff.

Esteban A. Maringolo  

 
Reply | Threaded
Open this post in threaded view
|

Re: Transforming objects

jtuchel
+1 about become:
Don’t use it for business stuff. Plus it can be very problematic when it comes to persistence mechanisms like O/R mappers...

Am 16.01.2019 um 19:01 schrieb Esteban Maringolo <[hidden email]>:

El mié., 16 ene. 2019 a las 14:49, Ben Coman via Pharo-users (<[hidden email]>) escribió:


On Wed, 16 Jan 2019 at 17:16, Loïc Pagès <[hidden email]> wrote:

Maybe a naive question ?

Maybe #become: ...


Although miraculous, using #become: to model a business domain is harmful, and has more undesired side effects than benefits.

So I would save it to a very limited use case scenarios, which are more related with low level stuff.

Esteban A. Maringolo  

 
Reply | Threaded
Open this post in threaded view
|

Re: Transforming objects

Jose San Leandro
In reply to this post by Loïc Pagès
Being a fan of DDD and Event Sourcing as I am, I'd implement your domain using Aggregates and Events.
Basically, your aggregate (Plant?) would respond to external information (or based on a schedule) and as a result, new events are generated ("Flower sprung", "Plant died", ...).
If only we had properly documented our Pharo-EDA "framework"... https://github.com/osoco/pharo-eda


El mié., 16 ene. 2019 a las 18:05, Loïc Pagès (<[hidden email]>) escribió:
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 <[hidden email]> 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, [hidden email] 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
>>
>>
>>
>>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Transforming objects

Loïc Pagès
In reply to this post by Esteban A. Maringolo
Hi Esteban,

In the present model, the plant has a tree-like structure. It is a well suited structure, even for a dandelion since the leaves are connected on a shoot. The plant root system has a tree structure as well !

Thank you,

Loïc


Le 16/01/2019 à 13:52, Esteban Maringolo a écrit :
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 (<[hidden email]>) 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 <[hidden email]> 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, [hidden email] 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
>>
>>
>>
>>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Transforming objects

Offray Vladimir Luna Cárdenas-2
In reply to this post by Loïc Pagès
Hi,

I would use an ad-hoc solution, modeling the Plant tree structure as a
document tree in Grafoscopio [1]. The root of the plant representation
would be the root of the document, the branches and sub-branches would
be nodes and sub-nodes in the documents, respectively. And each node
would contain a dictionary with the properties I want to reflect for
that particular node. The header of the node would be a shortcut to the
more detailed representation in the node body (the dictionary). Because
Grafoscopio notebooks are just plain STON text, you could store plants
history on a DVCS (Fossil, Git) and reify that ad-hoc model with methods
that capture what started just as dictionaries.

[1] http://mutabit.com/grafoscopio/index.en.html

Notice that Grafoscopio documents are programmable, so, while
Grafoscopio provides a GUI for editing them, you could access the API
and create them by scripting/coding.

Also the long, painful, joyful Karma of my PhD  is finishing with only
public dissertation pending, so I will have more time to care for
Grafoscopio source code and issues (hopefully I will send some updates,
once the deserved quiet time after intense thesis writing have finished).

Cheers,

Offray

On 16/1/19 4:15, Loïc Pagès 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 ?
>
> Thanks for your lights !
>
> Loïc
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Transforming objects

Richard O'Keefe
In reply to this post by Pharo Smalltalk Users mailing list
I note that #become: is not in the ANSI Smalltalk standard (am I the last
person in the world to care about that? Probably) and that several of the
Smalltalk systems I have on my machine don't support it.
In Squeak 5.2, there were 17 references to #become:.  Four of those were
just testing it.  One is just a mention in a collection of dangerous
things to not be tried.  Several are ways of changing an object's class.
Several are ways of forcibly deleting an object by turning it into
something trivial but safe.  And a couple, I don't understand.  Thing
is, #become: is *not* something to do lightly, and the code that calls
"x become: y" should "own" both x and y.  (In fact one of them is
often "self".)

About The Design Patterns Smalltalk Companion, draft chapters are
When I read the Gang of Four book, it seemed to me that most of it was
about fighting the fact that C++ and Java aren't Smalltalk.  Read a draft
chapter or two to make up your own mind.

One difference between the State pattern and #become: is that an object
can be an instance of the State pattern in more than one way at the same
time.

On Thu, 17 Jan 2019 at 05:58, Ben Coman via Pharo-users <[hidden email]> wrote:


On Wed, 16 Jan 2019 at 17:16, Loïc Pagès <[hidden email]> 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: ...

but it might be a misuse for your purpose.  The following book will provide some good insights...

cheers -ben