Yes I love this changing paradigm rules. Stef
On Sun, Nov 12, 2017 at 4:20 PM, Esteban Lorenzano <[email protected]> wrote: > > > On 12 Nov 2017, at 12:07, Denis Kudriashov <[email protected]> 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 <[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 >> >> >> > >
