2017-11-06 18:20 GMT+01:00 Sven Van Caekenberghe <[email protected]>: > > > > On 6 Nov 2017, at 17:25, Nicolas Cellier <nicolas.cellier.aka.nice@gmai > l.com> wrote: > > > > > > > > 2017-11-06 17:23 GMT+01:00 Sven Van Caekenberghe <[email protected]>: > > > > > > > On 6 Nov 2017, at 17:13, Dale Henrichs <dale.henrichs@gemtalksystems. > com> 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. >
Agree, the POV is: Symbol are just special String optimized for space. But then one must assume the cost of hischoices and provide appropriate transforms for communicating with external world. If a file exchange format or cross platform package specification requires a String, it's his responsability to provide a String... I shouldn't change the ston format just because it would ease some implementation in Squeak, should I?
