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