> 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. 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. 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. And I happen to like the ability to mix and match Strings and Symbols (we discussed about this before). Sven
