[IMPORTANT] Is there a bug in Tonel with category:

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 <[hidden email]> wrote:
>
>
>> On 6 Nov 2017, at 20:52, Stephane Ducasse <[hidden email]> 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
>> <[hidden email]> wrote:
>>>
>>>
>>> On 11/06/2017 08:23 AM, Sven Van Caekenberghe wrote:
>>>>
>>>>
>>>>> On 6 Nov 2017, at 17:13, Dale Henrichs <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 11/6/17 7:07 AM, Sven Van Caekenberghe wrote:
>>>>>>>
>>>>>>> On 6 Nov 2017, at 15:43, Dale Henrichs
>>>>>>> <[hidden email]> 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
>>>
>>
>
>

>>
>
> Then should not we replace STON based class definition with actual smalltalk
> based definition? Tonel could parse class definition in similar way like it
> parses methods.

Probably not :) but one of this day we will change the class
definition in Pharo adn we do not really want to impact tonel.
For me tonel is a storage format and it is ok like that.
Using Strings will solve the glitches.

Stef