[Pharo-dev] [IMPORTANT] Is there a bug in Tonel with category:

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Mon Nov 6 12:58:13 EST 2017


2017-11-06 18:20 GMT+01:00 Sven Van Caekenberghe <sven at stfx.eu>:

>
>
> > On 6 Nov 2017, at 17:25, Nicolas Cellier <nicolas.cellier.aka.nice at gmai
> l.com> wrote:
> >
> >
> >
> > 2017-11-06 17:23 GMT+01:00 Sven Van Caekenberghe <sven at stfx.eu>:
> >
> >
> > > On 6 Nov 2017, at 17:13, Dale Henrichs <dale.henrichs at gemtalksystems.
> com> wrote:
> > >
> > >
> > >
> > > On 11/6/17 7:07 AM, Sven Van Caekenberghe wrote:
> > >>
> > >>> On 6 Nov 2017, at 15:43, Dale Henrichs <
> dale.henrichs at gemtalksystems.com> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20171106/56580309/attachment-0002.html>


More information about the Pharo-dev mailing list