[Pharo-users] 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

Re: [Pharo-users] Transforming objects

[jtuc...@objektfabrik.de]

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

Re: [Pharo-users] #select was sent to nil

[Andrei Chis]

The bug seems to have been introduce in
Pharo7.0-SNAPSHOT.build.102.sha.3f660fc.arch.64bit by merging the pull
request https://github.com/pharo-project/pharo/pull/1847

On Wed, Jan 16, 2019 at 1:32 AM Hilaire via Pharo-users <
pharo-users@lists.pharo.org> wrote:

> Indeed, seems to only happen in a subclass of BlEement.
>
> Hilaire
>
> Le 15/01/2019 à 21:33, Andrei Chis a écrit :
> > It happens if you create methods in a class having a superclass with
> > traits. For example if you create a subclass of BlElement you will get
> > this error.
> >
> > What class are you editing when you get this errror?
> >
> --
> Dr. Geo
> http://drgeo.eu
>
>
>
>

Re: [Pharo-users] #select was sent to nil

[Tudor Girba]

Thanks for looking into this problem!

Doru


> On Jan 16, 2019, at 10:57 AM, Andrei Chis  wrote:
> 
> The bug seems to have been introduce in 
> Pharo7.0-SNAPSHOT.build.102.sha.3f660fc.arch.64bit by merging the pull 
> request https://github.com/pharo-project/pharo/pull/1847
> 
> On Wed, Jan 16, 2019 at 1:32 AM Hilaire via Pharo-users 
>  wrote:
> Indeed, seems to only happen in a subclass of BlEement.
> 
> Hilaire
> 
> Le 15/01/2019 à 21:33, Andrei Chis a écrit :
> > It happens if you create methods in a class having a superclass with
> > traits. For example if you create a subclass of BlElement you will get
> > this error.
> >
> > What class are you editing when you get this errror?
> >
> -- 
> Dr. Geo
> http://drgeo.eu
> 
> 
> 

--
www.feenk.com

"Some battles are better lost than fought."

Re: [Pharo-users] 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, jtuc...@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

Re: [Pharo-users] 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  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, jtuc...@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
> >>
> >>
> >>
> >>
> >
> >
>
>
>

Re: [Pharo-users] Transforming objects

[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 ()
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  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, jtuc...@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

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

[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@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 :
> >
> > >
> > >
> > > On 6 Sep 2018, at 23:35, Petr Fischer via Pharo-users <
> > > pharo-users@lists.pharo.org> wrote:
> > >
> > >
> > > *From: *Petr Fischer 
> > > *Subject: **adding instance variables (data) to the Object class*
> > > *Date: *6 September 2018 at 23:35:26 CEST
> > > *To: *pharo-users@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
> > >
>
>

[Pharo-users] LOOP book title mismatch

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

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

[Petr Fischer via Pharo-users]

--- Begin Message ---
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@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 :
> > >
> > > >
> > > >
> > > > On 6 Sep 2018, at 23:35, Petr Fischer via Pharo-users <
> > > > pharo-users@lists.pharo.org> wrote:
> > > >
> > > >
> > > > *From: *Petr Fischer 
> > > > *Subject: **adding instance variables (data) to the Object class*
> > > > *Date: *6 September 2018 at 23:35:26 CEST
> > > > *To: *pharo-users@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
> > > >
> >
> >

--- End Message ---

Re: [Pharo-users] Transforming objects

[Ben Coman via Pharo-users]

--- Begin Message ---
On Wed, 16 Jan 2019 at 17:16, 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 ?
>

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

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

[James Foster]

> On Jan 16, 2019, at 6:28 AM, Petr Fischer via Pharo-users 
>  wrote:
> 
> 
> From: Petr Fischer 
> 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@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@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 :
 
> 
> 
> On 6 Sep 2018, at 23:35, Petr Fischer via Pharo-users <
> pharo-users@lists.pharo.org> wrote:
> 
> 
> *From: *Petr Fischer 
> *Subject: **adding instance variables (data) to the Object class*
> *Date: *6 September 2018 at 23:35:26 CEST
> *To: *pharo-users@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
> 
>>> 
>>> 
> 
> 
> 
> 

Re: [Pharo-users] Transforming objects

[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 > 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, jtuc...@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. 

Re: [Pharo-users] Transforming objects

[Richard Sargent]

On Wed, Jan 16, 2019 at 9:05 AM Loïc Pagès  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  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, jtuc...@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 simul

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

[Benoit St-Jean via Pharo-users]

--- Begin Message ---

Petr,

Since you seem to want to add this (these) extra instance variable(s) in 
the context of some kind of persistence (objects being retrieved/created 
from/to some kind of database), perhaps subclassing all your objects 
from a PersistentObject class (that inherits from Object) would be the 
simplest solution.




--- End Message ---

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

[Stephan Eggermont]

Petr Fischer via Pharo-users
 wrote:
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)?

You might want to take a look at the documentation of Magma.
http://wiki.squeak.org/squeak/2665

Stephan

Re: [Pharo-users] Transforming objects

[Esteban Maringolo]

El mié., 16 ene. 2019 a las 14:49, Ben Coman via Pharo-users (<
pharo-users@lists.pharo.org>) escribió:

>
>
> On Wed, 16 Jan 2019 at 17:16, Loïc Pagès  wrote:
>
>>
>> Maybe a naive question ?
>>
>
> Maybe #become: ...
> https://gbracha.blogspot.com/2009/07/miracle-of-become.html
>
>
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

Re: [Pharo-users] Transforming objects

[Joachim Tuchel]

+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 :
> 
>> El mié., 16 ene. 2019 a las 14:49, Ben Coman via Pharo-users 
>> () escribió:
> 
>> 
>> 
>>> On Wed, 16 Jan 2019 at 17:16, Loïc Pagès  wrote:
>>> 
>>> Maybe a naive question ?
>> 
>> Maybe #become: ...
>> https://gbracha.blogspot.com/2009/07/miracle-of-become.html
>> 
> 
> 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  
> 
>  

Re: [Pharo-users] Transforming objects

[Jose San Leandro]

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 ()
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  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, jtuc...@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

[Pharo-users] [ANN] SETT (Store Export to Tonel Tools) for Pharo6.1

[Dale Henrichs]

GemTalkSystems is pleased to announce SETT (Store Export to Tonel 
Tools)[1]. SETT is open source project with an MIT license.


SETT (Store Export to Tonel Tools) is a set of tools to export Smalltalk 
code from Store and

write into the Tonel file format managed using Git.

SETT is:

 * a Pharo 6.1 application, that
 * connects to a Postgres Database
 * containing source code history in VisualWorks Store format; and
 * writes to a Git repository
 * in Tonel format
 * maintaining all version history, source code and SCM metadata.

SETT was developed last year to support one of our commercial customers 
in their conversion From Store to Rowan[2]. Rowan artifacts are produced 
as part of the output of SETT, but the Rowan artifacts can be ignored. 
The important bit is that SETT converts from Store to Tonel and 
maintains version history in git.


Please see the project ReadMe[3] and Wiki[4] for additional details.

Dale

[1] https://github.com/GemTalk/SETT
[2] https://github.com/GemTalk/Rowan
[3] https://github.com/GemTalk/SETT#overview
[4] https://github.com/GemTalk/SETT/wiki

Re: [Pharo-users] [ANN] SETT (Store Export to Tonel Tools) for Pharo6.1

[Esteban Maringolo]

This is great!

One less fence to move code from one dialect to another. :)

I will follow the examples and try to export code from Store and load id in
Pharo.

Is it mandatory to use Linux?

Esteban A. Maringolo


El mié., 16 ene. 2019 a las 16:38, Dale Henrichs (<
dale.henri...@gemtalksystems.com>) escribió:

> GemTalkSystems is pleased to announce SETT (Store Export to Tonel
> Tools)[1]. SETT is open source project with an MIT license.
>
> SETT (Store Export to Tonel Tools) is a set of tools to export Smalltalk
> code from Store and
> write into the Tonel file format managed using Git.
>
> SETT is:
>
>- a Pharo 6.1 application, that
>- connects to a Postgres Database
>- containing source code history in VisualWorks Store format; and
>- writes to a Git repository
>- in Tonel format
>- maintaining all version history, source code and SCM metadata.
>
> SETT was developed last year to support one of our commercial customers in
> their conversion From Store to Rowan[2]. Rowan artifacts are produced as
> part of the output of SETT, but the Rowan artifacts can be ignored. The
> important bit is that SETT converts from Store to Tonel and maintains
> version history in git.
>
> Please see the project ReadMe[3] and Wiki[4] for additional details.
>
> Dale
> [1] https://github.com/GemTalk/SETT
> [2] https://github.com/GemTalk/Rowan
> [3] https://github.com/GemTalk/SETT#overview
> [4] https://github.com/GemTalk/SETT/wiki
>
>
>

Re: [Pharo-users] [ANN] SETT (Store Export to Tonel Tools) for Pharo6.1

[Dale Henrichs via Pharo-users]

--- Begin Message ---


On 1/16/19 11:56 AM, Esteban Maringolo wrote:

This is great!

One less fence to move code from one dialect to another. :)

I will follow the examples and try to export code from Store and load 
id in Pharo.


Is it mandatory to use Linux?


We've only tested with Linux and it looks like the current code base is 
wired to use Unix[1] 


Dale

[1] 
https://github.com/GemTalk/SETT/blob/master/StoreImporter.package/SettGitRepository.class/instance/runGitWithArguments..st




Esteban A. Maringolo


El mié., 16 ene. 2019 a las 16:38, Dale Henrichs 
(>) escribió:


GemTalkSystems is pleased to announce SETT (Store Export to Tonel
Tools)[1]. SETT is open source project with an MIT license.

SETT (Store Export to Tonel Tools) is a set of tools to export
Smalltalk code from Store and
write into the Tonel file format managed using Git.

SETT is:

  * a Pharo 6.1 application, that
  * connects to a Postgres Database
  * containing source code history in VisualWorks Store format; and
  * writes to a Git repository
  * in Tonel format
  * maintaining all version history, source code and SCM metadata.

SETT was developed last year to support one of our commercial
customers in their conversion From Store to Rowan[2]. Rowan
artifacts are produced as part of the output of SETT, but the
Rowan artifacts can be ignored. The important bit is that SETT
converts from Store to Tonel and maintains version history in git.

Please see the project ReadMe[3] and Wiki[4] for additional details.

Dale

[1] https://github.com/GemTalk/SETT
[2] https://github.com/GemTalk/Rowan
[3] https://github.com/GemTalk/SETT#overview
[4] https://github.com/GemTalk/SETT/wiki


--- End Message ---

Re: [Pharo-users] Transforming objects

[Loïc Pagès]

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 (>) 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 mailto:loic.pa...@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, jtuc...@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.
 

Re: [Pharo-users] [ANN] SETT (Store Export to Tonel Tools) for Pharo6.1

[Sven Van Caekenberghe]

Great, thanks for sharing this.

> On 16 Jan 2019, at 20:35, Dale Henrichs  
> wrote:
> 
> GemTalkSystems is pleased to announce SETT (Store Export to Tonel Tools)[1]. 
> SETT is open source project with an MIT license.
> 
> SETT (Store Export to Tonel Tools) is a set of tools to export Smalltalk code 
> from Store and
> write into the Tonel file format managed using Git.
> 
> SETT is:
> 
>   • a Pharo 6.1 application, that
>   • connects to a Postgres Database
>   • containing source code history in VisualWorks Store format; and
>   • writes to a Git repository
>   • in Tonel format
>   • maintaining all version history, source code and SCM metadata.
> 
> SETT was developed last year to support one of our commercial customers in 
> their conversion From Store to Rowan[2]. Rowan artifacts are produced as part 
> of the output of SETT, but the Rowan artifacts can be ignored. The important 
> bit is that SETT converts from Store to Tonel and maintains version history 
> in git.
> 
> Please see the project ReadMe[3] and Wiki[4] for additional details.
> 
> Dale
> 
> [1] https://github.com/GemTalk/SETT
> [2] https://github.com/GemTalk/Rowan
> [3] https://github.com/GemTalk/SETT#overview
> [4] https://github.com/GemTalk/SETT/wiki
> 
> 

[Pharo-users] Smalltalks 2018 videos are live

[Gabriel Cotelli]

Hi,
We finished uploading all the videos of the conference. You can get the
links and related info here .

Regards,
Gabriel in name of FAST