> On 6 Nov 2017, at 17:25, Nicolas Cellier <[email protected]> > wrote: > > > > 2017-11-06 17:23 GMT+01:00 Sven Van Caekenberghe <[email protected]>: > > > > 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 > > > > Note that it's not entirely Pharo's fault. > #foo = 'foo' in Squeak too.
It is neither Squeak's 'fault'. It is a choice, just like you prefer #<=> over our #threeWayCompareTo: There are valid reasons for such choices, if a community choses or prefers one way or the other it is not a fault, it is a feature.
