On Wed, Nov 8, 2017 at 10:15 PM, Sven Van Caekenberghe <[email protected]> wrote: > > >> On 8 Nov 2017, at 21:29, Stephane Ducasse <[email protected]> wrote: >> >> 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. > > Tonel is a mix of different formats. Parts are custom to Tonel (the overall > structure), parts are Pharo syntax (the method's source code), parts are STON > (the contents of the meta data sections). > > Even if we make a change to how the Symbols are represented, it would still > not make the meta sections Pharo syntax. > > But I do agree it is a bit confusing. > > Either we make them all Strings, or I could add an option to STON that allows > STONWriter to control what constitutes a 'simple' or 'literal' Symbol.
Yes this would be great. Stef > > And we could err on the safe side (like only allow > 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789'), because I > dare you to look at String>>#isLiteralSymbol it is way more ugly than STON's > simple definition (which allows all characters from > 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_./'). > > What is the opinion of the original Tonel designers ? > >> 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 >>>>> >>>> >>> >>> >> > >
