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

> On 6 Nov 2017, at 17:13, Dale Henrichs <[hidden email]> wrote:
>
>
>
> On 11/6/17 7:07 AM, Sven Van Caekenberghe wrote:
>>
>>> On 6 Nov 2017, at 15:43, Dale Henrichs <[hidden email]> 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

> On 6 Nov 2017, at 17:25, Nicolas Cellier <[hidden email]> wrote:
>
>
>
> 2017-11-06 17:23 GMT+01:00 Sven Van Caekenberghe <[hidden email]>:
>
>
> > On 6 Nov 2017, at 17:13, Dale Henrichs <[hidden email]> wrote:
> >
> >
> >
> > On 11/6/17 7:07 AM, Sven Van Caekenberghe wrote:
> >>
> >>> On 6 Nov 2017, at 15:43, Dale Henrichs <[hidden email]> 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.

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.

Stef

On Mon, Nov 6, 2017 at 8:15 PM, Dale Henrichs

<[hidden email]> wrote:
>
>
> On 11/06/2017 08:23 AM, Sven Van Caekenberghe wrote:
>>
>>
>>> On 6 Nov 2017, at 17:13, Dale Henrichs <[hidden email]>
>>> wrote:
>>>
>>>
>>>
>>> On 11/6/17 7:07 AM, Sven Van Caekenberghe wrote:
>>>>>
>>>>> On 6 Nov 2017, at 15:43, Dale Henrichs
>>>>> <[hidden email]> 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
>

On 11/08/2017 01:15 PM, Sven Van Caekenberghe wrote:

What is the opinion of the original Tonel designers ?

Well, Esteban did the largest part of the work, but I guess I am *one* of the original designers, in that various design proposals were floated back and forth, starting with one of mine and ending with Tonel.

My intent is that Tonel, as a declarative cross-platform format, should use strings exclusively, never Symbols. I *think* I discussed this with Esteban during ESUG, and I *think* he agreed, so it seems likely that the current behavior with class definitions is unintentional.

Regards,

-Martin