> 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] > <mailto:[email protected]>>: > On 10 Nov 2017, at 13:05, Denis Kudriashov <[email protected] > <mailto:[email protected]>> wrote: >> 2017-11-10 16:30 GMT+01:00 Martin McClure <[email protected] >> <mailto:[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 >
