[Pharo-dev] [IMPORTANT] Is there a bug in Tonel with category:
dale.henrichs at gemtalksystems.com
Wed Nov 8 10:07:44 EST 2017
Poster child for the porting pain 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:)
>> 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 ...
More information about the Pharo-dev