As I threatened a while back, I've started up a "Pharo shim" - a package that adds to a Squeak image those messages necessary to get interesting Pharo projects working in Squeak:
http://www.squeaksource.com/PharoCompatibility
At the moment "interesting projects" means "PetitParser", and so the shim merely contains Symbol >> #isBinary.
Going forwards, as I find other bits necessary - my upcoming Helvetia/LanguageBoxes work will no doubt uncover bits and pieces - I'll add to Pharo-Compatibility.
I expect some bits to make their way into trunk, and we can regard Pharo-Compatibility as a proving ground of sorts.
frank
Every one knows that messages in Smalltalk syntax can be - unary - binary - keyword Unsurprisingly, there are corresponding methods implemented in Symbol... isUnary, isKeyword and... isInfix "Answer whether the receiver is an infix message selector." ^ self precedence = 2 Hmm, the name was surprising!
It would not hurt me to see isBinary integrated in trunk and replacing the isInfix sends... Maybe the purpose was to avoid polymorphism with Stream>>isBinary ?
Nicolas
2011/9/3 Frank Shearar frank.shearar@gmail.com:
As I threatened a while back, I've started up a "Pharo shim" - a package that adds to a Squeak image those messages necessary to get interesting Pharo projects working in Squeak:
http://www.squeaksource.com/PharoCompatibility
At the moment "interesting projects" means "PetitParser", and so the shim merely contains Symbol >> #isBinary.
Going forwards, as I find other bits necessary - my upcoming Helvetia/LanguageBoxes work will no doubt uncover bits and pieces - I'll add to Pharo-Compatibility.
I expect some bits to make their way into trunk, and we can regard Pharo-Compatibility as a proving ground of sorts.
frank
On Sat, 3 Sep 2011, Nicolas Cellier wrote:
Every one knows that messages in Smalltalk syntax can be
- unary
- binary
- keyword
Unsurprisingly, there are corresponding methods implemented in Symbol... isUnary, isKeyword and... isInfix "Answer whether the receiver is an infix message selector." ^ self precedence = 2 Hmm, the name was surprising!
It would not hurt me to see isBinary integrated in trunk and replacing the isInfix sends...
+1
Levente
Maybe the purpose was to avoid polymorphism with Stream>>isBinary ?
Nicolas
2011/9/3 Frank Shearar frank.shearar@gmail.com:
As I threatened a while back, I've started up a "Pharo shim" - a package that adds to a Squeak image those messages necessary to get interesting Pharo projects working in Squeak:
http://www.squeaksource.com/PharoCompatibility
At the moment "interesting projects" means "PetitParser", and so the shim merely contains Symbol >> #isBinary.
Going forwards, as I find other bits necessary - my upcoming Helvetia/LanguageBoxes work will no doubt uncover bits and pieces - I'll add to Pharo-Compatibility.
I expect some bits to make their way into trunk, and we can regard Pharo-Compatibility as a proving ground of sorts.
frank
On 9/3/2011 20:55, Nicolas Cellier wrote:
It would not hurt me to see isBinary integrated in trunk and replacing the isInfix sends... Maybe the purpose was to avoid polymorphism with Stream>>isBinary ?
Probably. I could easily see something like:
ByteArray>>isBinary ^true
String>>isBinary ^false
in which case Symbol>>isBinary would be a major surprise. My preference would be a more explicit name along the lines of #isBinarySelector or #isSelectorBinary or something. #isBinary has a number of potential conflicts and the proposed implementation is used way to rarely to occupy such a generic name.
Cheers, - Andreas
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Frank Shearar -
Levente Uzonyi -
Nicolas Cellier