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 <[email protected]>: > > > On 11 Nov 2017, at 07:48, Denis Kudriashov <[email protected]> wrote: > > Hi. > I extracted my question from previous thread about encoding issue in Tonel. > > 2017-11-10 18:08 GMT+01:00 Esteban Lorenzano <[email protected]>: > >> On 10 Nov 2017, at 13:05, Denis Kudriashov <[email protected]> wrote: >> >> 2017-11-10 16:30 GMT+01:00 Martin McClure <[email protected]>: >>>> >>>> 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 > > > >
