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
