2017-11-06 20:52 GMT+01:00 Stephane Ducasse <[email protected]>:
> 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. > But anyway we are not able to use definition from Tonel in playground. So what the difference? > > 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 <dale.henrichs@gemtalksystems. > com> > >>> 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 > > > >
