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