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

Denis Kudriashov dionisiydk at gmail.com
Thu Nov 9 04:50:46 EST 2017


2017-11-08 21:29 GMT+01:00 Stephane Ducasse <stepharo.self at gmail.com>:

> Sven
>
> I understand but it is SUPER strange to save the code in a format that
> does not respect the syntax of the language.
> I think that we should write a parser for the class definition or save
> category as strings.
>
>
Then should not we replace STON based class definition with actual
smalltalk based definition? Tonel could parse class definition in similar
way like it parses methods.


> I do not want to have to explain to people. Yes and no this is not the
> pharo syntax.
>
> Sorry I'm fed up.
>
> Stef
>
> On Mon, Nov 6, 2017 at 10:25 PM, Sven Van Caekenberghe <sven at stfx.eu>
> wrote:
> >
> >
> >> On 6 Nov 2017, at 20:52, Stephane Ducasse <stepharo.self at gmail.com>
> wrote:
> >>
> >> Esteban told me that this is because he uses STON for the class
> definition.
> >> Now a simple question may be we could use a string instead of a symbol
> >> because this is strange
> >> to have a class definitino that does not respect Pharo syntax.
> >
> > It might be a bit confusing at first sight, but it is correct, IMHO.
> >
> > It is STON syntax, not Pharo.
> >
> > Yes, STON is a bit more liberal with Symbols than normal Smalltalk, but
> it is totally consistent with itself.
> >
> > STON fromString: (STON toString: #'My Strange Symbol').
> > STON fromString: (STON toString: #'foo-bar').
> >
> > If a Symbol consists only of characters in '
> abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_./' then
> the Symbol does not need to be quoted in STON.
> >
> > I see no problem there.
> >
> >> Stef
> >>
> >> On Mon, Nov 6, 2017 at 8:15 PM, Dale Henrichs
> >> <dale.henrichs at gemtalksystems.com> wrote:
> >>>
> >>>
> >>> On 11/06/2017 08:23 AM, Sven Van Caekenberghe wrote:
> >>>>
> >>>>
> >>>>> 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.
> >>>
> >>> 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
> >>>
> >>
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20171109/f6888841/attachment-0002.html>


More information about the Pharo-dev mailing list