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

Sven Van Caekenberghe sven at stfx.eu
Mon Nov 6 16:25:36 EST 2017

> On 6 Nov 2017, at 20:52, Stephane Ducasse <stepharo.self at gmail.com> 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
> <dale.henrichs at gemtalksystems.com> wrote:
>> On 11/06/2017 08:23 AM, Sven Van Caekenberghe wrote:
>>>> On 6 Nov 2017, at 17:13, Dale Henrichs <dale.henrichs at gemtalksystems.com>
>>>> wrote:
>>>> On 11/6/17 7:07 AM, Sven Van Caekenberghe wrote:
>>>>>> On 6 Nov 2017, at 15:43, Dale Henrichs
>>>>>> <dale.henrichs at gemtalksystems.com> 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

More information about the Pharo-dev mailing list