Class versions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Class versions

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

Norbert




Von meinem iPad gesendet

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Class versions

Dale Henrichs-3
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
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Class versions

Stephane Ducasse-3
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Class versions

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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Class versions

NorbertHartl
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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Class versions

Dale Henrichs-3
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
>>>
>>
>


Loading...