Smalltalk › Pharo › Pharo Smalltalk Users

Class versions

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

NorbertHartl

Class versions

How far are we to support multiple versions of the same class in an image? Are there existing approaches?

Norbert

Von meinem iPad gesendet

Dale Henrichs-3

Re: Class versions

Norbert.

Are you thinking of GemStone-style class versions for Pharo?

Dale

On 03/19/2017 06:16 AM, Norbert Hartl wrote:
> How far are we to support multiple versions of the same class in an image? Are there existing approaches?
>
> Norbert
>
>
>
>
> Von meinem iPad gesendet
>

Stephane Ducasse-3

Re: Class versions

In reply to this post by NorbertHartl

What are multiple versions of a classes?

We are working on a module system for Pharo. The prototype is making progress. You will be able to have different classes with the same name in different classes.

Stef

On Sun, Mar 19, 2017 at 2:16 PM, Norbert Hartl <[hidden email]> wrote:

How far are we to support multiple versions of the same class in an image? Are there existing approaches?

Norbert

Von meinem iPad gesendet

NorbertHartl

Re: Class versions

In reply to this post by Dale Henrichs-3

Hi Dale,

> Am 20.03.2017 um 19:30 schrieb Dale Henrichs <[hidden email]>:
>
> Norbert.
>
> Are you thinking of GemStone-style class versions for Pharo?
>
I was thinking of something less elaborate. The first thing that should be possible is that two classes with different shape of the same name can co-exist in the image.That might be provided by #environment. The next step would be to have something like #migrateTo: in GemStone. Meaning that in case of a class/shape change the old instance is called with the new shape as parameter so I can intercept the process of object migration.

The #history case of GemStone would be nice of it would be modular and could be loaded. I think it can be done. But the points above need to be done first.

Norbert

> Dale
>
> On 03/19/2017 06:16 AM, Norbert Hartl wrote:
>> How far are we to support multiple versions of the same class in an image? Are there existing approaches?
>>
>> Norbert
>>
>>
>>
>>
>> Von meinem iPad gesendet
>>
>
>

NorbertHartl

Re: Class versions

In reply to this post by Stephane Ducasse-3

Stef,

Am 21.03.2017 um 07:53 schrieb Stephane Ducasse <[hidden email]>:

What are multiple versions of a classes?

it is what I wrote to Dale. Multiple versions of a class are different classes with the same name in the same image. And in a way that one class can access the other of same name. This way the two classes can build a context like old/new version or something else. It would also need to VM support of having a image side interception method while migration is done.

We are working on a module system for Pharo. The prototype is making progress. You will be able to have different classes with the same name in different classes.

I don't understand that sentence. The last work is supposed to be "environments"?

How far is that prototype?

thanks,

Norbert

Stef

On Sun, Mar 19, 2017 at 2:16 PM, Norbert Hartl <[hidden email]> wrote:
How far are we to support multiple versions of the same class in an image? Are there existing approaches?

Norbert

Von meinem iPad gesendet

Dale Henrichs-3

Re: Class versions

In reply to this post by NorbertHartl

On 03/21/2017 02:06 AM, Norbert Hartl wrote:
> Hi Dale,
>
>> Am 20.03.2017 um 19:30 schrieb Dale Henrichs <[hidden email]>:
>>
>> Norbert.
>>
>> Are you thinking of GemStone-style class versions for Pharo?
>>
> I was thinking of something less elaborate.
The GemStone implementation is not very elaborate ... the `class
history` exists pretty much to provide #isKindof: sanity for "two
versions of the same class".

> The first thing that should be possible is that two classes with different shape of the same name can co-exist in the image.That might be provided by #environment. The next step would be to have something like #migrateTo: in GemStone. Meaning that in case of a class/shape change the old instance is called with the new shape as parameter so I can intercept the process of object migration.
>
> The #history case of GemStone would be nice of it would be modular and could be loaded. I think it can be done. But the points above need to be done first.
>
> Norbert
>
>> Dale
>>
>> On 03/19/2017 06:16 AM, Norbert Hartl wrote:
>>> How far are we to support multiple versions of the same class in an image? Are there existing approaches?
>>>
>>> Norbert
>>>
>>>
>>>
>>>
>>> Von meinem iPad gesendet
>>>
>>
>