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

Dale Henrichs dale.henrichs at gemtalksystems.com
Wed Nov 8 10:07:44 EST 2017

Poster child for the porting pain[1] of symbols and strings - from this 

The dictionary was created using symbols as the keys, but the code that 
I had to change used mixed symbols and strings as keys ... and of course 
I was left wondering why the class vars weren't being defined properly ...



On 11/6/17 11:15 AM, Dale Henrichs 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