Poster child for the porting pain[1] of symbols and strings - from this
morning:)
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 ...
Dale
[1]
https://github.com/GsDevKit/tonel/commit/b00565685586630452a9de3d4f90f16571428019#diff-bf8f5ba630dc8c679c3c68668bc76a5e
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
<[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
