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