2017-11-08 21:29 GMT+01:00 Stephane Ducasse <[email protected]>:
> Sven > > I understand but it is SUPER strange to save the code in a format that > does not respect the syntax of the language. > I think that we should write a parser for the class definition or save > category as strings. > > Then should not we replace STON based class definition with actual smalltalk based definition? Tonel could parse class definition in similar way like it parses methods. > I do not want to have to explain to people. Yes and no this is not the > pharo syntax. > > Sorry I'm fed up. > > Stef > > On Mon, Nov 6, 2017 at 10:25 PM, Sven Van Caekenberghe <[email protected]> > wrote: > > > > > >> On 6 Nov 2017, at 20:52, Stephane Ducasse <[email protected]> > wrote: > >> > >> Esteban told me that this is because he uses STON for the class > definition. > >> Now a simple question may be we could use a string instead of a symbol > >> because this is strange > >> to have a class definitino that does not respect Pharo syntax. > > > > It might be a bit confusing at first sight, but it is correct, IMHO. > > > > It is STON syntax, not Pharo. > > > > Yes, STON is a bit more liberal with Symbols than normal Smalltalk, but > it is totally consistent with itself. > > > > STON fromString: (STON toString: #'My Strange Symbol'). > > STON fromString: (STON toString: #'foo-bar'). > > > > If a Symbol consists only of characters in ' > abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_./' then > the Symbol does not need to be quoted in STON. > > > > I see no problem there. > > > >> Stef > >> > >> On Mon, Nov 6, 2017 at 8:15 PM, Dale Henrichs > >> <[email protected]> wrote: > >>> > >>> > >>> On 11/06/2017 08:23 AM, Sven Van Caekenberghe wrote: > >>>> > >>>> > >>>>> On 6 Nov 2017, at 17:13, Dale Henrichs < > [email protected]> > >>>>> wrote: > >>>>> > >>>>> > >>>>> > >>>>> On 11/6/17 7:07 AM, Sven Van Caekenberghe wrote: > >>>>>>> > >>>>>>> On 6 Nov 2017, at 15:43, Dale Henrichs > >>>>>>> <[email protected]> wrote: > >>>>>>> > >>>>>>> of course with Pharo's implementation of Symbol it is not > practical to > >>>>>>> use asString nor type checks - things that are not necessary in > other > >>>>>>> Smalltalk implementations > >>>>>> > >>>>>> How so ? > >>>>>> > >>>>>> What is the problem with Symbol>>#asString ? > >>>>> > >>>>> I am not going to go to every field in the api that is supposed to > be a > >>>>> String and add asString. There are too many places to worry about > ... I > >>>>> would prefer that Pharo be ANSI compliant:) > >>>>> > >>>>> It's not just Metacello. > >>>>> > >>>>> It's an annoying issue that has to be dealt with every time a Pharo > >>>>> application is ported to another dialect of Smalltalk and an annoying > >>>>> barrier for folks running on other dialects to move their > application to > >>>>> Pharo - in this case the bugs that are introduced by Pharo's > behavior with > >>>>> respect to Symbols can be very hard to diagnose -- > >>>>> > >>>>> Making things harder to share code between dialects is a bad thing > for > >>>>> Smalltalk overall -- just another reason for non-Smalltalk > programmers to > >>>>> question the whether they should use Smalltalk or not... > >>>>> > >>>>> And I don't need to hear about how Pharo is not Smalltalk:) > >>>>> > >>>>> Dale > >>>> > >>>> So there is nothing 'wrong', you just want Pharo to remain the same as > >>>> every other non-changing Smalltalk out there. > >>> > >>> Did I say that? > >>> > >>> I support the direction that Pharo is going, but I reserve the right to > >>> disagree with some of the details. > >>> > >>> This is just one detail ... nothing more nothing less ... For those of > us > >>> that work in multiple dialects, it IS annoying and I take an > opportunity > >>> every year or so to remind you guys of the things that I find > annoying, just > >>> to keep you guys honest:) > >>> > >>>> > >>>> From one perspective you are right, it makes some cross platform > porting > >>>> in either direction harder. Seaside has many rules to help > portability. Not > >>>> mixing Strings and Symbol is probably one of them. > >>> > >>> ... and as I mentioned, this problem can be one of the more annoying > issues > >>> to track down, when a developer is not careful ... Honestly there are > two > >>> sides to the issue ... when developers use Symbols in tests to drive > an API > >>> that is supposed to use Strings (this happens the most often) things > break > >>> pretty quickly and the tests can be fixed pretty easily ... but when > the > >>> code itself is written with mixed Symbols and Strings, the tests might > >>> actually pass after the port, and the bugs will only show up in subtle > cases > >>> ... I've hit a handful of these over the years and they are hard to > track > >>> down... > >>>> > >>>> > >>>> But you know very well that Pharo was started so that we would be > able to > >>>> make changes, in any area or aspect of the system, without the burden > of > >>>> backwards or cross platform compatibility, even if some of these > changes are > >>>> taste based. > >>> > >>> Agree with your statement -- most of the changes that Pharo has made > have > >>> not been difficult to accommodate, but Symbol/String is at a > fundamental > >>> level and I'm not sure that it would be "illegal" to make this > accommodation > >>> --- I AM pretty certain that it would cause some short term pain, but > >>> probably no more pain (and likely less pain) than is caused by trying > to > >>> move an application to a new version of Pharo:) > >>>> > >>>> And I happen to like the ability to mix and match Strings and Symbols > (we > >>>> discussed about this before). > >>>> > >>> I won't argue with taste, it's is simply the portability for this > particular > >>> problem that I am highlighting ... > >>> > >>> Dale > >>> > >> > > > > > >
