Tonel and class definition changes
Locked
Tonel and class definition changes
 
|
Hi. I extracted my question from previous thread about encoding issue in Tonel. 2017-11-10 18:08 GMT+01:00 Esteban Lorenzano <[hidden email]>:
My question was related to the sentence that Tonel is intended to be for any Smalltalk dialect. If Pharo will use #slots, #package and #tags names in class definition format it will be not compatible to other smalltalks.
And what will happen then? We will again regenerate all sources/history? When we will switch to new names every class will be modified in following commit. |
|
|
we will use #slots and other implementations will use #instVars platforms will need to translate them… for example, we will be able to interpret instVars as simple slots and categories as packages, they can do the same (it can be more complicated for slots, but at the end, is also doable) tonel is a portable cross dialect format, but that does not means that what is saved for pharo is immediately loadable in other platforms and viceversa. When working for compatibility, framework designers takes the differences into account: they do not use traits and sometimes they need a compatibility layer (Seaside, I’m watching you). With slots they will need to do the same, and most probably they will not use them, sadly.
or incremental (while working). I still do not decide how to proceed since is a problem we still do not have. I have plenty of things I need to decide right now, I can wait a bit for this one :) Esteban |
Re: Tonel and class definition changes
|
|
Thank's Esteban. Originally I thought that Tonel will be only Pharo format. And in that case I was wondering why it uses old names which will need support in future. But for other Smalltalks it is clear: we will need support it anyway. 2017-11-11 12:39 GMT+01:00 Esteban Lorenzano <[hidden email]>:
|
|
|
heh… you know this thing about changing paradigms from Kuhn? As architect, I always apply the rule for everything: - for one thing to replace another, the new one has to provide an advantage over the old one (we cannot replace it just because). - but people forgets the second rule it needs to follow, which is IMO the most relevant: for one thing to replace another, it needs not just to have an advantage, but it has to ALSO solve all the problems the previous one solved. So. We want to change filetree with tonel. Then we need have an advantage (we have it). But then Tonel also has to solve all the problems filetree did. And portability is one of them :) Esteban
|
Re: Tonel and class definition changes
|
|
Yes I love this changing paradigm rules.
Stef On Sun, Nov 12, 2017 at 4:20 PM, Esteban Lorenzano <[hidden email]> wrote: > > > On 12 Nov 2017, at 12:07, Denis Kudriashov <[hidden email]> wrote: > > Thank's Esteban. > > Originally I thought that Tonel will be only Pharo format. And in that case > I was wondering why it uses old names which will need support in future. > > > heh… you know this thing about changing paradigms from Kuhn? As architect, I > always apply the rule for everything: > - for one thing to replace another, the new one has to provide an advantage > over the old one (we cannot replace it just because). > - but people forgets the second rule it needs to follow, which is IMO the > most relevant: for one thing to replace another, it needs not just to have > an advantage, but it has to ALSO solve all the problems the previous one > solved. > > So. We want to change filetree with tonel. Then we need have an advantage > (we have it). But then Tonel also has to solve all the problems filetree > did. And portability is one of them :) > > Esteban > > But for other Smalltalks it is clear: we will need support it anyway. > > 2017-11-11 12:39 GMT+01:00 Esteban Lorenzano <[hidden email]>: >> >> >> >> On 11 Nov 2017, at 07:48, Denis Kudriashov <[hidden email]> wrote: >> >> Hi. >> I extracted my question from previous thread about encoding issue in >> Tonel. >> >> 2017-11-10 18:08 GMT+01:00 Esteban Lorenzano <[hidden email]>: >>> >>> On 10 Nov 2017, at 13:05, Denis Kudriashov <[hidden email]> wrote: >>>> >>>> 2017-11-10 16:30 GMT+01:00 Martin McClure <[hidden email]>: >>>>> >>>>> Tonel is intended to be, I believe: >>>>> * For Smalltalk primarily (although there are other languages) >>>>> * Be for any Smalltalk dialect (although the first implementation is >>>>> for Pharo, it is being ported to GemStone, and we intend to port it to VW >>>>> and VA) >>>> >>>> >>>> Interesting how it will be handled when Pharo will use slots abstraction >>>> exclusively. And more simple, when there will be only package and tags >>>> instead of class categories. >>> >>> >>> To be more clear. Imaging that instead of #instanceVariables field Pharo >>> will use #slots. And instead of #category it will be #package and #tags >>> >>> >>> what does it has to do with this thread? >> >> >> My question was related to the sentence that Tonel is intended to be for >> any Smalltalk dialect. If Pharo will use #slots, #package and #tags names in >> class definition format it will be not compatible to other smalltalks. >> >> >> we will use #slots and other implementations will use #instVars >> >> platforms will need to translate them… for example, we will be able to >> interpret instVars as simple slots and categories as packages, they can do >> the same (it can be more complicated for slots, but at the end, is also >> doable) >> >> tonel is a portable cross dialect format, but that does not means that >> what is saved for pharo is immediately loadable in other platforms and >> viceversa. When working for compatibility, framework designers takes the >> differences into account: they do not use traits and sometimes they need a >> compatibility layer (Seaside, I’m watching you). With slots they will need >> to do the same, and most probably they will not use them, sadly. >> >> >> >>> >>> handling that is trivial: once we actually have slots (bah, we have them, >>> but once we *use* them) and once we move to package+tags, we just adapt the >>> descriptions. That’s the advantage of using STON to keep them. >> >> >> And what will happen then? We will again regenerate all sources/history? >> When we will switch to new names every class will be modified in following >> commit. >> >> >> or incremental (while working). >> I still do not decide how to proceed since is a problem we still do not >> have. >> I have plenty of things I need to decide right now, I can wait a bit for >> this one :) >> >> Esteban >> >> >> > > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |