Usage of unicode method selectors?
tom95 opened this issue · comments
Hi!
This is not an issue report but rather a question. As a background: I recently tried loading your package in Squeak and stumbled over your usage of the unicode PI symbol as a method selector. Squeak currently does not support this, so I had to fork and replace occurrences accordingly to be able to load it in Squeak.
My question is whether this was just an experiment or whether you expect this to come up more frequently in Pharo packages. I would also be curious to learn if you have editor support to even be able to type the selector without copy-pasting it from somewhere. If you think unicode in selectors is here to stay, I'll investigate how difficult it would be to add support on Squeak's end.
Thank you for your time!
Hi Tom,
i think this usage was implemented by Peter (and i have to admit it's really cool to express stuff like 0.5π radians).
In Pharo there is the support to type it like in any other editor (alt-p on my mac).
In my opinion, we should make Geometry able to load in Squeak if the only cost is to remove this π selector.
What i propose is that you create a small pull request where you put the changes you have already done to make Geometry loadable in Squeak and also put in a new pharo specific package with the π method on Number (to avoid breaking projects using it).
Finally create two groups in the baseline (a pharo one being the default loading also the Pharo only compatible package and a squeak one not loading it).
I cannot answer about unicode usage in Pharo selectors but once something is supported, you will always find users of it.
Tell me if that's ok for you.
Thanks in advance for your Contribution
Ah interesting! On my Linux/QWERTZ layout I don't have a pi symbol, so that didn't even occur to me :D
Could you clear up what the current proper upstream repo is? I came here through Roassal's Baseline, so I first ended up at the https://github.com/pharo-contributions/Geometry fork instead of this repo, but the fork didn't even have issues enabled, so I figured this repo is probably the proper upstream?
My changes are found here: tom95@5e7e1fa
As you can see, it (naturally) affects quite a few classes. If I understand your suggestion correctly, you would replace all internal usage of π with pi (e.g. 2π to 2pi), but leave the Number>>#π selector available as part of the public API, just moved to a Pharo-only package?
This sounds like a very good first step to me.
More fundamentally, from my personal point of view, while I absolutely agree that it reads very cleanly, I would prefer to deprecate (not remove) it as part of the public API, too, as I think it makes it harder for people to contribute/write code on systems that do not support typing the symbol. Contrarily, if there's an obvious IM trick that I'm missing or Pharo implements tool support to type the selector similarly quickly, I would be on board again and investigate what can be done to add support on Squeak's end. Otherwise, I would argue that if we leave the selector non-deprecated the compatibility issue will continue popping up.
Hi,
It is not Peter but me who introduced the used of the pi symbol.
At first, when I worked on Geometry it was more for fun than anything else. Thus, I used the pi symbol because Pharo allowed it and it made the code more readable in my opinion.
Now, the current proper upstream of the project is the for of pharo-contribution since it is used in roassal. I see no problem at removing the use of pi symbol if it can improve compatibility inter-smalltalks. We can even keep this method packaged in a Pharo-specific package of the project and remove its use in the core project. Like this, we would not break existing projects while providing the compatibility.
Hi, thank you for the great insights!
I went and investigated the failure to load in Squeak further and it turned out to be a simple decoding problem: squeak-smalltalk/squeak-filesystem#2 As such, I would go ahead and close this issue as there is no immediate need for changes.
Still, on a more fundamental level, I think it would be worth it for the Pharo community to discuss whether source code with unicode symbols in important base libraries (especially in the public interface) is wanted or not. I looked at a number of German and English layouts and the only one that mapped the PI symbol was "English (US) Macintosh". As such, the selector, while looking great, is quite inconvenient to input for non-Mac-users, as it appears.
Cool, i am very happy that you can use Geometry without modifications.
I agree with you that unicode usage should be discussed at the community level but it's out of my scope, i don't want to lose time in this.
In our case, the keyboard layout doesn't matter because you can use the #pi selector.