Hi.
I extracted my question from previous thread about encoding issue in Tonel.
����
2017-11-10 18:08 GMT+01:00 Esteban Lorenzano��<estebanlm@gmail.com>:
On 10 Nov 2017, at 13:05, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2017-11-10 16:30 GMT+01:00 Martin McClure��<martin@hand2mouse.com>:
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.