- Pharo-users - lists.pharo.org

Re: [Pharo-users] Symbol equality method #= - weird condition in the Pharo sourcecode

by Richard Sargent

On Fri, Mar 1, 2019 at 12:02 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Ah, it is an optimisation: if the first #== fails, but the argument is > also a Symbol, then that means the are different for sure, so false is > returned early, instead of failing in super's #= after that. > > And with ByteSymbol and WideSymbol, although they are exclusive (can never > be equal), they can be different and if they are both Symbols, then you can > return early (not just when their classes differ). > Thanks for explaining that! As an aside, this is the kind of information that should be in a method's comment. Rationale and explanation, rather than what it does. > > On 1 Mar 2019, at 18:40, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > Why ? Please explain ... > > > >> On 1 Mar 2019, at 18:02, David T. Lewis <lewis(a)mail.msen.com> wrote: > >> > >> On Fri, Mar 01, 2019 at 05:18:27PM +0100, Sven Van Caekenberghe wrote: > >>> > >>> > >>>> On 1 Mar 2019, at 17:08, Petr Fischer via Pharo-users < > pharo-users(a)lists.pharo.org> wrote: > >>>> > >>>> > >>>> From: Petr Fischer <petr.fischer(a)me.com> > >>>> Subject: Symbol equality method #= - weird condition in the Pharo > sourcecode > >>>> Date: 1 March 2019 at 17:08:03 GMT+1 > >>>> To: pharo-users(a)lists.pharo.org > >>>> > >>>> > >>>> Hello, this is Symbol equality method in Pharo: > >>>> > >>>> 1: = aSymbol > >>>> 2: "Compare the receiver and aSymbol." > >>>> 3: self == aSymbol ifTrue: [^ true]. > >>>> 4: self class == aSymbol class ifTrue: [^ false]. > >>>> 5: "Use String comparison otherwise" > >>>> 6: ^ super = aSymbol > >>>> > >>>> Look at line 4 - what does it mean? That's wrong, isn't it? > >>>> > >>>> Typically, every symbol comparisons end up in line 3, but if you do > some work with forward proxies for example, condition on line 3 is "false" > and then weird things on line 4 happens. > >>>> > >>>> If line 4 and further are correct, can someone explain a little? > >>>> > >>>> Thanks! pf > >>> > >>> Yes, that looks weird. Line 4 should probably be removed, unless I am > missing something. > >> > >> It is wrong in a Spur image, because we now have subclasses of Symbol. > >> But removing line 4 is not the right solution. See Nicolas' > implementation > >> in Squeak: > >> > >> Symbol>>= aSymbol > >> "Compare the receiver and aSymbol." > >> self == aSymbol ifTrue: [^ true]. > >> aSymbol isSymbol ifTrue: [^ false]. > >> "Use String comparison otherwise" > >> ^ super = aSymbol > >> > >> Dave > >> > >>> > >>> Symbols are by definition always #== so in that sense, #= should not > even be implemented (as #= on Object is defined as #==), but since its > direct super class String already overwrote #=, it has to follow. > >>> > >>> The super call in line 6 is what allows Symbols and String to be > compared. > >>> > >>> I would say line 4 is a kind of sanity check, but probably not needed. > > > > >

March 1, 2019

Re: [Pharo-users] Symbol equality method #= - weird condition in the Pharo sourcecode

by Sven Van Caekenberghe

Ah, it is an optimisation: if the first #== fails, but the argument is also a Symbol, then that means the are different for sure, so false is returned early, instead of failing in super's #= after that. And with ByteSymbol and WideSymbol, although they are exclusive (can never be equal), they can be different and if they are both Symbols, then you can return early (not just when their classes differ). > On 1 Mar 2019, at 18:40, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Why ? Please explain ... > >> On 1 Mar 2019, at 18:02, David T. Lewis <lewis(a)mail.msen.com> wrote: >> >> On Fri, Mar 01, 2019 at 05:18:27PM +0100, Sven Van Caekenberghe wrote: >>> >>> >>>> On 1 Mar 2019, at 17:08, Petr Fischer via Pharo-users <pharo-users(a)lists.pharo.org> wrote: >>>> >>>> >>>> From: Petr Fischer <petr.fischer(a)me.com> >>>> Subject: Symbol equality method #= - weird condition in the Pharo sourcecode >>>> Date: 1 March 2019 at 17:08:03 GMT+1 >>>> To: pharo-users(a)lists.pharo.org >>>> >>>> >>>> Hello, this is Symbol equality method in Pharo: >>>> >>>> 1: = aSymbol >>>> 2: "Compare the receiver and aSymbol." >>>> 3: self == aSymbol ifTrue: [^ true]. >>>> 4: self class == aSymbol class ifTrue: [^ false]. >>>> 5: "Use String comparison otherwise" >>>> 6: ^ super = aSymbol >>>> >>>> Look at line 4 - what does it mean? That's wrong, isn't it? >>>> >>>> Typically, every symbol comparisons end up in line 3, but if you do some work with forward proxies for example, condition on line 3 is "false" and then weird things on line 4 happens. >>>> >>>> If line 4 and further are correct, can someone explain a little? >>>> >>>> Thanks! pf >>> >>> Yes, that looks weird. Line 4 should probably be removed, unless I am missing something. >> >> It is wrong in a Spur image, because we now have subclasses of Symbol. >> But removing line 4 is not the right solution. See Nicolas' implementation >> in Squeak: >> >> Symbol>>= aSymbol >> "Compare the receiver and aSymbol." >> self == aSymbol ifTrue: [^ true]. >> aSymbol isSymbol ifTrue: [^ false]. >> "Use String comparison otherwise" >> ^ super = aSymbol >> >> Dave >> >>> >>> Symbols are by definition always #== so in that sense, #= should not even be implemented (as #= on Object is defined as #==), but since its direct super class String already overwrote #=, it has to follow. >>> >>> The super call in line 6 is what allows Symbols and String to be compared. >>> >>> I would say line 4 is a kind of sanity check, but probably not needed. >

March 1, 2019

Re: [Pharo-users] Symbol equality method #= - weird condition in the Pharo sourcecode

by Steffen MÃ¤rcker

Is it consistent with the definition of #= in String such that 'aSymbol = aString' iff 'aString = aSymbol'? Sorry, I don't have an image at hand. Am 1. MÃ¤rz 2019 18:40:11 MEZ schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >Why ? Please explain ... > >> On 1 Mar 2019, at 18:02, David T. Lewis <lewis(a)mail.msen.com> wrote: >> >> On Fri, Mar 01, 2019 at 05:18:27PM +0100, Sven Van Caekenberghe >wrote: >>> >>> >>>> On 1 Mar 2019, at 17:08, Petr Fischer via Pharo-users ><pharo-users(a)lists.pharo.org> wrote: >>>> >>>> >>>> From: Petr Fischer <petr.fischer(a)me.com> >>>> Subject: Symbol equality method #= - weird condition in the Pharo >sourcecode >>>> Date: 1 March 2019 at 17:08:03 GMT+1 >>>> To: pharo-users(a)lists.pharo.org >>>> >>>> >>>> Hello, this is Symbol equality method in Pharo: >>>> >>>> 1: = aSymbol >>>> 2: "Compare the receiver and aSymbol." >>>> 3: self == aSymbol ifTrue: [^ true]. >>>> 4: self class == aSymbol class ifTrue: [^ false]. >>>> 5: "Use String comparison otherwise" >>>> 6: ^ super = aSymbol >>>> >>>> Look at line 4 - what does it mean? That's wrong, isn't it? >>>> >>>> Typically, every symbol comparisons end up in line 3, but if you do >some work with forward proxies for example, condition on line 3 is >"false" and then weird things on line 4 happens. >>>> >>>> If line 4 and further are correct, can someone explain a little? >>>> >>>> Thanks! pf >>> >>> Yes, that looks weird. Line 4 should probably be removed, unless I >am missing something. >> >> It is wrong in a Spur image, because we now have subclasses of >Symbol. >> But removing line 4 is not the right solution. See Nicolas' >implementation >> in Squeak: >> >> Symbol>>= aSymbol >> "Compare the receiver and aSymbol." >> self == aSymbol ifTrue: [^ true]. >> aSymbol isSymbol ifTrue: [^ false]. >> "Use String comparison otherwise" >> ^ super = aSymbol >> >> Dave >> >>> >>> Symbols are by definition always #== so in that sense, #= should not >even be implemented (as #= on Object is defined as #==), but since its >direct super class String already overwrote #=, it has to follow. >>> >>> The super call in line 6 is what allows Symbols and String to be >compared. >>> >>> I would say line 4 is a kind of sanity check, but probably not >needed.

March 1, 2019

Re: [Pharo-users] Interval form: x to: y when x > y - or how to count down...

by K K Subbu

On 01/03/19 5:35 PM, Sven Van Caekenberghe wrote: > I like this too. > > Why would this not happen ? It is just one selector more. > > I think the only possible issue is that #to:do: is known by the > compiler, which makes it faster than any other iteration, even do: - > there is always a tradeoff between readability and raw speed. Thank you for the kind words. I am not sure if speed would be affected much by: downTo: stop ^self to: stop by: -1 downTo: stop do: aBlock ^self to: stop by: -1 do: aBlock In performance critical paths, one can always use to:do: with explicit steps. Regards .. Subbu

March 1, 2019

Re: [Pharo-users] Symbol equality method #= - weird condition in the Pharo sourcecode

by Sven Van Caekenberghe

Why ? Please explain ... > On 1 Mar 2019, at 18:02, David T. Lewis <lewis(a)mail.msen.com> wrote: > > On Fri, Mar 01, 2019 at 05:18:27PM +0100, Sven Van Caekenberghe wrote: >> >> >>> On 1 Mar 2019, at 17:08, Petr Fischer via Pharo-users <pharo-users(a)lists.pharo.org> wrote: >>> >>> >>> From: Petr Fischer <petr.fischer(a)me.com> >>> Subject: Symbol equality method #= - weird condition in the Pharo sourcecode >>> Date: 1 March 2019 at 17:08:03 GMT+1 >>> To: pharo-users(a)lists.pharo.org >>> >>> >>> Hello, this is Symbol equality method in Pharo: >>> >>> 1: = aSymbol >>> 2: "Compare the receiver and aSymbol." >>> 3: self == aSymbol ifTrue: [^ true]. >>> 4: self class == aSymbol class ifTrue: [^ false]. >>> 5: "Use String comparison otherwise" >>> 6: ^ super = aSymbol >>> >>> Look at line 4 - what does it mean? That's wrong, isn't it? >>> >>> Typically, every symbol comparisons end up in line 3, but if you do some work with forward proxies for example, condition on line 3 is "false" and then weird things on line 4 happens. >>> >>> If line 4 and further are correct, can someone explain a little? >>> >>> Thanks! pf >> >> Yes, that looks weird. Line 4 should probably be removed, unless I am missing something. > > It is wrong in a Spur image, because we now have subclasses of Symbol. > But removing line 4 is not the right solution. See Nicolas' implementation > in Squeak: > > Symbol>>= aSymbol > "Compare the receiver and aSymbol." > self == aSymbol ifTrue: [^ true]. > aSymbol isSymbol ifTrue: [^ false]. > "Use String comparison otherwise" > ^ super = aSymbol > > Dave > >> >> Symbols are by definition always #== so in that sense, #= should not even be implemented (as #= on Object is defined as #==), but since its direct super class String already overwrote #=, it has to follow. >> >> The super call in line 6 is what allows Symbols and String to be compared. >> >> I would say line 4 is a kind of sanity check, but probably not needed.

March 1, 2019

Re: [Pharo-users] [Pharo-dev] looking for an author of a Beginning Pharo or related

by Ben Coman

Obviously its good to be circumspect at such an earlier stage, but I can imagine a few "good" editors who publishing a book would really lend some legitimacy and exposure to Pharo. That would be overall beneficial even if the book is not free. Stef, I am interested to know more. cheers -ben On Fri, 1 Mar 2019 at 17:01, Thomas Dupriez <tdupriez(a)ens-paris-saclay.fr> wrote: > Hello, > > The timing of this mail is interesting, because just yesterday I stumbled > on the "Free Software Needs Free Documentation" preface of the GDB > documentation. > > It's a dozen paragraph so not exactly a short read, but the gist of it is > that the author urges other authors to use free documentation licenses for > the documentations/manuals they are writing, so that they can be modified > and grown by the community along with the free software they talk about. > > I've attached the full version if some people are interested in reading it. > > Sorry for this tangent, StÃ©phane. The timing was just too perfect. :) > > Thomas > On 01/03/2019 08:09, StÃ©phane Ducasse wrote: > > Hi guys > > We have been contacted by a (good) editor that would like to publish on > Beginning Pharo or related. > I have a lot of material that I can give but no energy to write such book > :) > > If one of you in interested, let me know. I could even be a co-author. > > Stef > > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr > http://www.synectique.eu / http://www.pharo.org > 03 59 35 87 52 > Assistant: Julie Jonas > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > >

March 1, 2019

Re: [Pharo-users] Richard Kenneth Eng is NOT Mr. Smalltalk

by Ben Coman

Hi Michael, Thanks for your thoughtful followup. On Fri, 1 Mar 2019 at 19:59, Michael Zeder <post(a)michael-j-zeder.de> wrote: > > I have carefully thought about, if I should really go publicly against one > person within the community, and to start this "tirade", including the > possibility that this causes an escalation, of course you cannot/must not > silence a person ("Streisand" effect, did not know the term, but very > fitting). But I decided that this kind of public conflicts is what is > needed (and will make the community look better, not worse), _if_ a certain > point is reached. > I certainly subscribe to the tenet "Community standards do not maintain themselves: They're maintained by people actively applying them, visibly, in public." [1] And I understand the tension in deciding to do so, with the accompanying risk of making things worse (been there myself) For me what weakened your first post was the name calling and sense you were coming from a position of hurt with a story you needed to justify by "making him wrong". :) Much better second time round. [1] http://www.catb.org/esr/faqs/smart-questions.html#not_losing > I stand by it, but have reconsidered some points: > * I do (did) not call for _immediate_ exclusion, but an "admonishment" > that if certain behaviour is not about to change fundamentally, the > community will have to act (by publicly separating this individual out). > * Take older articles down, which start flamewars against other languages, > or more precise: separate them from Smalltalk advocacy! If he wants to > flame JS (for its various birth defects), fine, but don't connect that with > pro-Smalltalk articles, for example. > That seems a reasonable position and a good way to frame it. > * Community efforts shall follow follow some community consensus. Core > developers are no dictators, of course, but they are the ones knowing, what > the state of the project is, and where _their_ work will lead to. > Constantly ignoring this common guidance is detrimental to the community. > So either, learn Smalltalk core coding and challenge the leadership, or do > accept that there is some common agenda (and there are lots of open tasks: > writing tutorials, documentation, make old scientific research available, > linking and connecting showcases). > His earlier articles got hammered and its natural that created a defensive position for him to disconnect from the community leadership. The trick as for everyone is to not carry those forever and try starting anew. * Public opinion does matter. The fact I mentioned Google SEO was indeed > the starting point for me, to get into or start this flame war. *Here is > my story*: > Two of my clients (medium-sized enterprises) are classical C++/C# Windows > development companies. I advertised Pharo to them for an _internal_ tool > (their commerical products won't change to Smalltalk of course, but for > their own internal dev tasks, Pharo whould have been a nice fit). When the > managers got back to me, *they had googled it, and told me, this thing > sounds very dubious ("unseriÃ¶s"). I enquired, what they had read, and they > told me, this "spokesperson" (sic!!!) sounds like a trolling script kid, > and they can't employ something which is developed (sic!!!) by such people*. > After some explanation, I managed to convince them, that this person is > just a lonely person, who showed up out of nowhere, is not involved in the > actual work, and just produces himself on the internet. But too late, their > impression on Smalltalk was already formed by R.K.Engs "blogs" (in the > meantime, they rank on top in Google search result). > You should have led with that !!!! An experience has a lot more power than an opinion. > When I did some research of my own yesterday, and saw again, that R.K. > Engs dubious blog entries were listed on top, I decided to take action. > > > I like to answer to your balanced and thoughtful responses: > > You may disagree about *how* he does such work, the actual content, for > sure, but that's a feedback better directed to mr. Eng himself. > > > R.K. Eng has made it clear in the past many many times in uncertain > wording, that he is not willing to follow community advice in these > matters, if his gut is telling him something different... > > Some of that community advice has been delivered fairly confrontation-ally and not really conducive to having someone listen. > Hopefully I've expressed a balanced enough position that this doesn't draw > too many responses. > > yes, you did. thank you. > > > I agree "Mr Smalltalk" is quite a presumptive title, but really anyone >> following the mail lists soon gets an idea of who are the community merit >> leaders. >> > > Well, I disagree, based on the experience, I have written down above. The > internet is very much about who is in the center of the focus (SEO/social > media). Anybody new to Smalltalk will at first glance identify our > community with this "spokesperson" (as I have experienced with two people, > last year already btw) > Point taken. Maybe it is a language thing, but "Mr. Smalltalk" is _extremely_ > presumptive (in German, it means the embodiment of the denoted thing). If a > person is not doing very very thorough reading of ages old mail list > discussions or is researching, that this person in fact never committed any > code to the repos, then any newcomer will think, this "Mr. Smalltalk" is at > least a versed and informed Smalltalk developer (which, given his newbie > questions he is absolutely not). > Got it. So apart from fighting directly against his presumption to the title (which seems difficult) would cleaning some other-language-denigration from old articles go some way towards mitigating your concern? > You are right he hasn't committed any code, but I've not actually seen him >> claim credit for any code in Pharo, so this point seems off. >> > true. but as I just wrote, that is what people presume, given his way and > manner of producing himself. If he wrote honestly wrote "I am a fanboy, > supporter and advocate of Smalltalk...", great! But he claims he worked > many many hours without a dime, but worth many dollars, and had "tremendous > success" in creating a new Smalltalk wave. > I'm pretty by many-hours-without-a dime he meant his evangelism. If it didn't come across like that, that is probably specific copy-edit feedback that would be useful to him. > * ...is doing SEO to make Google show his own results before FOSS >>> community or sciences pages. >>> >> I think its equally likely that most in our community are too busy coding >> to try getting articles ranked, >> so its more lack of effort by most of us. Most of his articles mention >> Pharo so people end up finding us anyway. >> > might be true (some criticism to the community agenda..? different topic) > The thing is, the wrong information are getting more and more in the focus > of the internet, pushing aside the community-driven Pharo sites (or real > scientific papers or well-done tutorials). > I've read most of his articles. I don't think he gets much factually wrong about Pharo (and has corrected those when pointed out). It seems your main concern about wrong information is attacks on other languages, which is fair. > Any money he gets for his writing is not anything that concerns me >> personally. Those articles are his own effort. >> > > Sorry, misunderstanding! Of course, he may earn with his writing, whatever > he gets for it. > I was referring to the "up-coming" Smalltalk Coding Competition. > btw, a few weeks ago when Richard asked for help to program the competition, I volunteered. I've criticized some of his articles, and maybe there are other "better" the money could be spent, but I admire he has stuck to his vision and think its a big thing he has taken on. If its going to happen anyway, for me its better to help make it a success than a flop. [Sidebar: I haven't managed to do much on it yet since I'm run ragged on a personal development course until mid-April that includes running a community project of my own... https://www.nanpopcode.fun/] > Now, yes, that money doesn't go into his own pockets (would be criminal > fraud), but the thing is, he controls this money. > Who will be the judges? Who will set parameters for the competition? > Transparency? > What is the benefit that goes back into the community? Now, it is fine, > that he is pushing for things like that, but again, he is doing it without > synchronising this effort with what is needed by the community. > He got a reasonable number of supporters on GoFundMe (I wasn't one at the time), and I believe the majority of the money comes from a few companies so I expect its really their opinion that counts about how their money is spent. > * ...denies community leadership by merit (Pharo core developers do know, >>> what they have created and where they want to go in the future, >>> >> I don't see him claiming leadership of our community or trying to set our >> agenda. >> He just didn't let community criticism of his writing slow him down. >> All I observed is that several people bit him and he bit back - fairly >> usual sort of poor communication on both sides (including me). >> > > Well, as written above, the manner of his web appearance is implicitly a > claim of community leadership. Not an exclusive one of course, but he wants > to be perceived of one of the most important persons in the community (he > told so many times, explicitly). And given my experience, read above, this > had already a (negative) success with it. > And I think he is setting agenda: "Make Smalltalk great/mainstream again" > is the baseline, and that is something, only the core dev team and the > community as a whole can decide/make happen (I love Smalltalk, but he > promises wrong things, so if, just for example, C++/Qt devs or _modern_ JS > devs have a first look at Smalltalk with the expectation they could already > do the same thing as in their usual platforms, they will be disappointed > --> synchronize a marketing agenda with what this great project currently > is about, but he is not willing to cooperate with the core dev team) > Fair enough. Since in a couple of months I'll be helping him out, I'll have an opportunity to raise these concerns with him. > Him swearing about a group of Pharo people is good ammunition to bring to >> the mail list to support your point, >> but I also see he was rather provoked. Overall I feel this extract was >> better left in that small corner of the internet >> rather than fan flames here. >> > > :) Yeah... no! I think this is really a central point (so I put him in the > pillory here with intent). There is something called community/FOSS ethics > and structures. > He does not show _respect_ towards those people, who did the work, but > produces himself, and pushes for things, which the people who devoted their > work to this project, told him that it is counter-productive. That is, in > the long-run, a very dangerous situation. > I agree, its not great. But he didn't get a warm welcome and some of his early interactions were abrasive. Considering two extremes, you can either be inclusive and hopefully nurture/mold, or exclude and lose any chance at that. Like a lot of things, the path is somewhere in the middle and needs a bit of give and take on both sides. > PS: a side note on Javascript (with lower S). wether you love or hate this >>> quirky lovechild of Lisp and Self/Smalltalk, telling JS developers they are >>> stupid and that they should abandon powerful Vue.js, for example, in favor >>> of Amber Smalltalk [cudos to Amber devs! great thing!]) is utterly stupid! >>> >> Agree. But banning everyone in the world for similar stupidity would >> leave the internet awfully quiet. >> > Sure! Again: I am against silencing or banning anybody (and how could > you). But if this becomes unbearable, there needs to be a public > separation, so he does not drag the project down. People need to speak up > against such usurpation. > I appreciate the stand your are taking for the community. I've gained from your share of your workplace experience. (which in the end are only a self-serving, ego-centric, attention-greedy >>> campaign to promote "Mr. Smalltalk" himself, a total newbie, who claims >>> credit for the work of others). >>> >> Your repeated "claims credit for the work of others" is quite provocative >> and I haven't noticed this in his writings. Could you provide a link? >> > > See above, maybe it is a cultural thing, but as I told in my experience, > all of his appearance screams for being recognized as one of the most > important persons in the community (he is condescendingly mocking marketing > efforts of the last 40 years, claims that he is the one who will "make > smalltalk great again"...) > > Yes I am provocative this time, not my normal style (and I admit, I was > tripped-out by his provocative blog title "Even people who understand > prototypal programming do not like it â an inconvienent truth"; that is > dripping off arrogance and ignorance... And sheds a bad light on Smalltalk, > with which he wants to be identified in the web) > Got it. Let me ask to park this thread for the moment, because it can be quite distracting if everyone chips in an opinion. I think you've made some fair points and I'll put myself on the line to discuss them with Richard when I start helping him with his competition project. cheers -ben

March 1, 2019

Re: [Pharo-users] Symbol equality method #= - weird condition in the Pharo sourcecode

by David T. Lewis

On Fri, Mar 01, 2019 at 05:18:27PM +0100, Sven Van Caekenberghe wrote: > > > > On 1 Mar 2019, at 17:08, Petr Fischer via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > > > > > From: Petr Fischer <petr.fischer(a)me.com> > > Subject: Symbol equality method #= - weird condition in the Pharo sourcecode > > Date: 1 March 2019 at 17:08:03 GMT+1 > > To: pharo-users(a)lists.pharo.org > > > > > > Hello, this is Symbol equality method in Pharo: > > > > 1: = aSymbol > > 2: "Compare the receiver and aSymbol." > > 3: self == aSymbol ifTrue: [^ true]. > > 4: self class == aSymbol class ifTrue: [^ false]. > > 5: "Use String comparison otherwise" > > 6: ^ super = aSymbol > > > > Look at line 4 - what does it mean? That's wrong, isn't it? > > > > Typically, every symbol comparisons end up in line 3, but if you do some work with forward proxies for example, condition on line 3 is "false" and then weird things on line 4 happens. > > > > If line 4 and further are correct, can someone explain a little? > > > > Thanks! pf > > Yes, that looks weird. Line 4 should probably be removed, unless I am missing something. It is wrong in a Spur image, because we now have subclasses of Symbol. But removing line 4 is not the right solution. See Nicolas' implementation in Squeak: Symbol>>= aSymbol "Compare the receiver and aSymbol." self == aSymbol ifTrue: [^ true]. aSymbol isSymbol ifTrue: [^ false]. "Use String comparison otherwise" ^ super = aSymbol Dave > > Symbols are by definition always #== so in that sense, #= should not even be implemented (as #= on Object is defined as #==), but since its direct super class String already overwrote #=, it has to follow. > > The super call in line 6 is what allows Symbols and String to be compared. > > I would say line 4 is a kind of sanity check, but probably not needed. > >

March 1, 2019

Re: [Pharo-users] Symbol equality method #= - issue submitted

by Petr Fischer

Issue submitted: https://github.com/pharo-project/pharo/issues/2744 pf > > On 1 Mar 2019, at 17:08, Petr Fischer via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > > > > > From: Petr Fischer <petr.fischer(a)me.com> > > Subject: Symbol equality method #= - weird condition in the Pharo sourcecode > > Date: 1 March 2019 at 17:08:03 GMT+1 > > To: pharo-users(a)lists.pharo.org > > > > > > Hello, this is Symbol equality method in Pharo: > > > > 1: = aSymbol > > 2: "Compare the receiver and aSymbol." > > 3: self == aSymbol ifTrue: [^ true]. > > 4: self class == aSymbol class ifTrue: [^ false]. > > 5: "Use String comparison otherwise" > > 6: ^ super = aSymbol > > > > Look at line 4 - what does it mean? That's wrong, isn't it? > > > > Typically, every symbol comparisons end up in line 3, but if you do some work with forward proxies for example, condition on line 3 is "false" and then weird things on line 4 happens. > > > > If line 4 and further are correct, can someone explain a little? > > > > Thanks! pf > > Yes, that looks weird. Line 4 should probably be removed, unless I am missing something. > > Symbols are by definition always #== so in that sense, #= should not even be implemented (as #= on Object is defined as #==), but since its direct super class String already overwrote #=, it has to follow. > > The super call in line 6 is what allows Symbols and String to be compared. > > I would say line 4 is a kind of sanity check, but probably not needed. > >

March 1, 2019

Re: [Pharo-users] Symbol equality method #= - weird condition in the Pharo sourcecode

by Sven Van Caekenberghe

> On 1 Mar 2019, at 17:08, Petr Fischer via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > > From: Petr Fischer <petr.fischer(a)me.com> > Subject: Symbol equality method #= - weird condition in the Pharo sourcecode > Date: 1 March 2019 at 17:08:03 GMT+1 > To: pharo-users(a)lists.pharo.org > > > Hello, this is Symbol equality method in Pharo: > > 1: = aSymbol > 2: "Compare the receiver and aSymbol." > 3: self == aSymbol ifTrue: [^ true]. > 4: self class == aSymbol class ifTrue: [^ false]. > 5: "Use String comparison otherwise" > 6: ^ super = aSymbol > > Look at line 4 - what does it mean? That's wrong, isn't it? > > Typically, every symbol comparisons end up in line 3, but if you do some work with forward proxies for example, condition on line 3 is "false" and then weird things on line 4 happens. > > If line 4 and further are correct, can someone explain a little? > > Thanks! pf Yes, that looks weird. Line 4 should probably be removed, unless I am missing something. Symbols are by definition always #== so in that sense, #= should not even be implemented (as #= on Object is defined as #==), but since its direct super class String already overwrote #=, it has to follow. The super call in line 6 is what allows Symbols and String to be compared. I would say line 4 is a kind of sanity check, but probably not needed.

March 1, 2019