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