Issue 14160: Introduce isXXX dialect testing methods to SmalltalkImage to ease cross-dialect development
Hi guys, I've just opened: https://pharo.fogbugz.com/f/cases/14160/Introduce-isXXX-dialect-testing-meth... Introduce isXXX (isPharo, isVisualWorks, ...) dialect testing methods to SmalltalkImage to ease multi-dialect development. RATIONALE: Commonly used approach to solve differences among dialect is to use a sort of platform object and dispatch there for troublesome operations that has to be specialized. This platform object is usually in platform specific package. Other option is to load some library like Grease or Sport. The problem of the first approach is that brings to much (unnecessary) burden when used for two, three things. The amount of of the code and management is way to bigger then the amount of the code that has to be specialized. Loading Grease/Sport on the other hand introduces a dependency on an external package - not worth of for two or three things. The proposed dialect testing messages would allow for simple, #ifdef-like idiom like: | stream | ... ((Smalltalk respondsTo: #isSomeCoolDialect) and:[Smalltalk isSomeCoolDialect]) ifTrue:[ stream := CharacterWriteStream on: (String new: 10) ] ifFalse:[ stream := WriteStream on: (String new: 10) ] The #respondsTo: check, while not nice, is required as at the moment not all dialects could be trusted to have these testing messages. Putting these methods may not stick with Pharo standard (whatever it is), but Smalltalk global is probably one of the very few that are present in pretty much every Smalltalk implementation. Other option would be to place them to the class side of an Object (which is amost certainly present everywhere), however Smalltalk isPharo reads better than Object isPharo. Best, Jan
Hi jan Thanks for the proposal. I thought about it and I'm against because it goes again the idea of dispatch. I prefer to have a class and some dispatch. Seaside with Grease is the way to go from my perspective. Finally I do not want such methods in the systems because I spent my time removing isXXXX because of bad design. Let us see what other people think. Stef On 4/10/14 22:14, Jan Vrany wrote:
Hi guys,
I've just opened:
https://pharo.fogbugz.com/f/cases/14160/Introduce-isXXX-dialect-testing-meth...
Introduce isXXX (isPharo, isVisualWorks, ...) dialect testing methods to SmalltalkImage to ease multi-dialect development.
RATIONALE:
Commonly used approach to solve differences among dialect is to use a sort of platform object and dispatch there for troublesome operations that has to be specialized. This platform object is usually in platform specific package. Other option is to load some library like Grease or Sport.
The problem of the first approach is that brings to much (unnecessary) burden when used for two, three things. The amount of of the code and management is way to bigger then the amount of the code that has to be specialized. Loading Grease/Sport on the other hand introduces a dependency on an external package - not worth of for two or three things.
The proposed dialect testing messages would allow for simple, #ifdef-like idiom like:
| stream | ... ((Smalltalk respondsTo: #isSomeCoolDialect) and:[Smalltalk isSomeCoolDialect]) ifTrue:[ stream := CharacterWriteStream on: (String new: 10) ] ifFalse:[ stream := WriteStream on: (String new: 10) ]
The #respondsTo: check, while not nice, is required as at the moment not all dialects could be trusted to have these testing messages.
Putting these methods may not stick with Pharo standard (whatever it is), but Smalltalk global is probably one of the very few that are present in pretty much every Smalltalk implementation. Other option would be to place them to the class side of an Object (which is amost certainly present everywhere), however
Smalltalk isPharo
reads better than
Object isPharo.
Best, Jan
Itâs true that when you do a lot of cross-dialect development, such a method is often what you desire. However, I think itâs better to do feature detection instead of dialect detection. So, something like: ((Smalltalk includesKey: #CharacterWriteStream) ifTrue:[ stream := CharacterWriteStream on: (String new: 10) ] ifFalse:[ stream := WriteStream on: (String new: 10) ] And yes: use Grease where applicable. We try to maintain Grease across Pharo, Squeak and Gemstone. I also think itâs actively ported to VA. cheers Johan On 05 Oct 2014, at 09:00, stepharo <stepharo@free.fr> wrote:
Hi jan
Thanks for the proposal. I thought about it and I'm against because it goes again the idea of dispatch. I prefer to have a class and some dispatch. Seaside with Grease is the way to go from my perspective. Finally I do not want such methods in the systems because I spent my time removing isXXXX because of bad design. Let us see what other people think.
Stef
On 4/10/14 22:14, Jan Vrany wrote:
Hi guys,
I've just opened:
https://pharo.fogbugz.com/f/cases/14160/Introduce-isXXX-dialect-testing-meth...
Introduce isXXX (isPharo, isVisualWorks, ...) dialect testing methods to SmalltalkImage to ease multi-dialect development.
RATIONALE:
Commonly used approach to solve differences among dialect is to use a sort of platform object and dispatch there for troublesome operations that has to be specialized. This platform object is usually in platform specific package. Other option is to load some library like Grease or Sport.
The problem of the first approach is that brings to much (unnecessary) burden when used for two, three things. The amount of of the code and management is way to bigger then the amount of the code that has to be specialized. Loading Grease/Sport on the other hand introduces a dependency on an external package - not worth of for two or three things.
The proposed dialect testing messages would allow for simple, #ifdef-like idiom like:
| stream | ... ((Smalltalk respondsTo: #isSomeCoolDialect) and:[Smalltalk isSomeCoolDialect]) ifTrue:[ stream := CharacterWriteStream on: (String new: 10) ] ifFalse:[ stream := WriteStream on: (String new: 10) ]
The #respondsTo: check, while not nice, is required as at the moment not all dialects could be trusted to have these testing messages.
Putting these methods may not stick with Pharo standard (whatever it is), but Smalltalk global is probably one of the very few that are present in pretty much every Smalltalk implementation. Other option would be to place them to the class side of an Object (which is amost certainly present everywhere), however
Smalltalk isPharo
reads better than
Object isPharo.
Best, Jan
Johan Brichau wrote:
Itâs true that when you do a lot of cross-dialect development, such a method is often what you desire. However, I think itâs better to do feature detection instead of dialect detection.
+1 and others agree... (though on the net its possible to find material to support any view) "test for features, not for platforms" http://programmers.stackexchange.com/questions/50876/are-there-any-best-prac... "The best bet is always to test for features, not versions, because it's difficult to screw that up and it allows for the possibility that things might be back-ported in future. " http://mac-os-x.10953.n7.nabble.com/CocoaApp-isThisTiger-td29619i20.html "The Autoconf approach to portability is to test for features, not for versions." http://en.wikipedia.org/wiki/Autoconf btw Johan, how would you handle a method-existence-based requirement rather than class-existence-based? ...
So, something like:
((Smalltalk includesKey: #CharacterWriteStream) ifTrue:[ stream := CharacterWriteStream on: (String new: 10) ] ifFalse:[ stream := WriteStream on: (String new: 10) ]
And yes: use Grease where applicable. We try to maintain Grease across Pharo, Squeak and Gemstone. I also think itâs actively ported to VA.
cheers Johan
On 05 Oct 2014, at 09:00, stepharo <stepharo@free.fr> wrote:
Hi jan
Thanks for the proposal. I thought about it and I'm against because it goes again the idea of dispatch. I prefer to have a class and some dispatch. Seaside with Grease is the way to go from my perspective. Finally I do not want such methods in the systems because I spent my time removing isXXXX because of bad design. Let us see what other people think.
Stef
With the disclaimer that I haven't done cross platform Smalltalk yet, in general philosophy I agree with Stef. "A Mentoring Course On Smalltalk" regarding elimination of conditional logic says, "drawing design time distinctions at run time is intention obscuring by nature". ...
On 4/10/14 22:14, Jan Vrany wrote:
Hi guys,
I've just opened:
https://pharo.fogbugz.com/f/cases/14160/Introduce-isXXX-dialect-testing-meth...
Introduce isXXX (isPharo, isVisualWorks, ...) dialect testing methods to SmalltalkImage to ease multi-dialect development.
You would need to get ALL dialects to implement the convention?
RATIONALE:
Commonly used approach to solve differences among dialect is to use a sort of platform object and dispatch there for troublesome operations that has to be specialized. This platform object is usually in platform specific package.
Other option is to load some library like Grease or Sport.
The problem of the first approach is that brings to much (unnecessary) burden when used for two, three things. The amount of of the code and management is way to bigger then the amount of the code that has to be specialized.
However if you do want to go the testing-for-versions, and your concern is management of separate packages, then perhaps it can all be done on one package. The following does not seem too onerous from a code perspective... ------------------ CrossPlatform>>platform ^ CurrentPlatform ifNil: [ "<--class variable" CurrentPlatform := self class subClasses detect: [ :candidatePlatformClass | candidatePlatformClass isCurrentPlatform CrossPlatform subclass: SomeCoolDialect. SomeCoolDialect>>isCurrentPlatform ^ (Smalltalk version includesSubstring: 'SomeCoolDialect') ------------------ CrossPlatform>>writeStreamOn: aString self platform writeSteamOn: aString SomeCoolDialect>>writeStreamOn: aString ^ CharacterWriteStream on: aString ------------------ Loading Grease/Sport on the other hand introduces a
dependency on an external package - not worth of for two or three things.
The proposed dialect testing messages would allow for simple, #ifdef-like idiom like:
"New #ifdef's which test for specific compilers or manufacturers or operating systems are unacceptable. All #ifdef's should test for features." https://www.cs.utah.edu/dept/old/texinfo/gdb/gdbint.html cheers -ben
| stream | ... ((Smalltalk respondsTo: #isSomeCoolDialect) and:[Smalltalk isSomeCoolDialect]) ifTrue:[ stream := CharacterWriteStream on: (String new: 10) ] ifFalse:[ stream := WriteStream on: (String new: 10) ]
The #respondsTo: check, while not nice, is required as at the moment not all dialects could be trusted to have these testing messages.
Putting these methods may not stick with Pharo standard (whatever it is), but Smalltalk global is probably one of the very few that are present in pretty much every Smalltalk implementation. Other option would be to place them to the class side of an Object (which is amost certainly present everywhere), however
Smalltalk isPharo
reads better than
Object isPharo.
Best, Jan
On Sun, 2014-10-05 at 10:29 +0200, Johan Brichau wrote:
Itâs true that when you do a lot of cross-dialect development, such a method is often what you desire. However, I think itâs better to do feature detection instead of dialect detection. So, something like:
((Smalltalk includesKey: #CharacterWriteStream) ifTrue:[ stream := CharacterWriteStream on: (String new: 10) ] ifFalse:[ stream := WriteStream on: (String new: 10) ]
Right, in this example it could eventually work. Another concrete example I bumped just yesterday. The "feature testing" code would look like ((Character respondsTo: #to:) and:[($a to: $z) isKindOf: Interval]) ifTrue:[ ... ] ifFalse:[ ... ]. (true, in this very case you may be able to get around using different method, but you get the point, no?) Some time ago Hilaire posted a very nice, 15 lines long code that does reliable "feature detection" whether the system is Pharo 2.0 or 3.0 (or similar, I don't remember exactly). Is the interval testing code above more robust? Perhaps. Is it more readable, more intention revelaling? I doubt it. While I can agree that feature testing is is better, however, in my experience it is very tricky if the code does not provide support for such tests.
And yes: use Grease where applicable. We try to maintain Grease across Pharo, Squeak and Gemstone. I also think itâs actively ported to VA.
That's great. But having such dependency is exactly what I, and not only me, don't want if it would be for only one or two methods. The aim is to provide a simple solution for simple cases, not a silver bullet. Jan
cheers Johan
On 05 Oct 2014, at 09:00, stepharo <stepharo@free.fr> wrote:
Hi jan
Thanks for the proposal. I thought about it and I'm against because it goes again the idea of dispatch. I prefer to have a class and some dispatch. Seaside with Grease is the way to go from my perspective. Finally I do not want such methods in the systems because I spent my time removing isXXXX because of bad design. Let us see what other people think.
Stef
On 4/10/14 22:14, Jan Vrany wrote:
Hi guys,
I've just opened:
https://pharo.fogbugz.com/f/cases/14160/Introduce-isXXX-dialect-testing-meth...
Introduce isXXX (isPharo, isVisualWorks, ...) dialect testing methods to SmalltalkImage to ease multi-dialect development.
RATIONALE:
Commonly used approach to solve differences among dialect is to use a sort of platform object and dispatch there for troublesome operations that has to be specialized. This platform object is usually in platform specific package. Other option is to load some library like Grease or Sport.
The problem of the first approach is that brings to much (unnecessary) burden when used for two, three things. The amount of of the code and management is way to bigger then the amount of the code that has to be specialized. Loading Grease/Sport on the other hand introduces a dependency on an external package - not worth of for two or three things.
The proposed dialect testing messages would allow for simple, #ifdef-like idiom like:
| stream | ... ((Smalltalk respondsTo: #isSomeCoolDialect) and:[Smalltalk isSomeCoolDialect]) ifTrue:[ stream := CharacterWriteStream on: (String new: 10) ] ifFalse:[ stream := WriteStream on: (String new: 10) ]
The #respondsTo: check, while not nice, is required as at the moment not all dialects could be trusted to have these testing messages.
Putting these methods may not stick with Pharo standard (whatever it is), but Smalltalk global is probably one of the very few that are present in pretty much every Smalltalk implementation. Other option would be to place them to the class side of an Object (which is amost certainly present everywhere), however
Smalltalk isPharo
reads better than
Object isPharo.
Best, Jan
Would using Metacello's knowledge of the platform work for you? e.g. (MetacelloPlatform current defaultPlatformAttributes includes: '#squeak') ifTrue:[ ... ] (MetacelloPlatform current defaultPlatformAttributes includes: '#pharo1.2') ..... (MetacelloPlatform current defaultPlatformAttributes includes: '#gemstone2.4') ..... Or are you trying to get very very cross platform (e.g. GST, VAST, etc...) ? Jan Vrany wrote
On Sun, 2014-10-05 at 10:29 +0200, Johan Brichau wrote:
Itâs true that when you do a lot of cross-dialect development, such a method is often what you desire. However, I think itâs better to do feature detection instead of dialect detection. So, something like:
((Smalltalk includesKey: #CharacterWriteStream) ifTrue:[ stream := CharacterWriteStream on: (String new: 10) ] ifFalse:[ stream := WriteStream on: (String new: 10) ]
Right, in this example it could eventually work. Another concrete example I bumped just yesterday. The "feature testing" code would look like
((Character respondsTo: #to:) and:[($a to: $z) isKindOf: Interval]) ifTrue:[ ... ] ifFalse:[ ... ].
(true, in this very case you may be able to get around using different method, but you get the point, no?)
Some time ago Hilaire posted a very nice, 15 lines long code that does reliable "feature detection" whether the system is Pharo 2.0 or 3.0 (or similar, I don't remember exactly).
Is the interval testing code above more robust? Perhaps. Is it more readable, more intention revelaling? I doubt it.
While I can agree that feature testing is is better, however, in my experience it is very tricky if the code does not provide support for such tests.
And yes: use Grease where applicable. We try to maintain Grease across Pharo, Squeak and Gemstone. I also think itâs actively ported to VA.
That's great. But having such dependency is exactly what I, and not only me, don't want if it would be for only one or two methods. The aim is to provide a simple solution for simple cases, not a silver bullet.
Jan
cheers Johan
On 05 Oct 2014, at 09:00, stepharo <
stepharo@
> wrote:
Hi jan
Thanks for the proposal. I thought about it and I'm against because it goes again the idea of dispatch. I prefer to have a class and some dispatch. Seaside with Grease is the way to go from my perspective. Finally I do not want such methods in the systems because I spent my time removing isXXXX because of bad design. Let us see what other people think.
Stef
On 4/10/14 22:14, Jan Vrany wrote:
Hi guys,
I've just opened:
https://pharo.fogbugz.com/f/cases/14160/Introduce-isXXX-dialect-testing-meth...
Introduce isXXX (isPharo, isVisualWorks, ...) dialect testing methods
to
SmalltalkImage to ease multi-dialect development.
RATIONALE:
Commonly used approach to solve differences among dialect is to use a sort of platform object and dispatch there for troublesome operations that has to be specialized. This platform object is usually in platform specific package. Other option is to load some library like Grease or Sport.
The problem of the first approach is that brings to much (unnecessary) burden when used for two, three things. The amount of of the code and management is way to bigger then the amount of the code that has to be specialized. Loading Grease/Sport on the other hand introduces a dependency on an external package - not worth of for two or three things.
The proposed dialect testing messages would allow for simple, #ifdef-like idiom like:
| stream | ... ((Smalltalk respondsTo: #isSomeCoolDialect) and:[Smalltalk isSomeCoolDialect]) ifTrue:[ stream := CharacterWriteStream on: (String new: 10) ] ifFalse:[ stream := WriteStream on: (String new: 10) ]
The #respondsTo: check, while not nice, is required as at the moment not all dialects could be trusted to have these testing messages.
Putting these methods may not stick with Pharo standard (whatever it is), but Smalltalk global is probably one of the very few that are present in pretty much every Smalltalk implementation. Other option would be to place them to the class side of an Object (which is amost certainly present everywhere), however
Smalltalk isPharo
reads better than
Object isPharo.
Best, Jan
-- View this message in context: http://forum.world.st/Issue-14160-Introduce-isXXX-dialect-testing-methods-to... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On Sun, 2014-10-05 at 19:08 -0700, Paul DeBruicker wrote:
Would using Metacello's knowledge of the platform work for you? e.g.
(MetacelloPlatform current defaultPlatformAttributes includes: '#squeak') ifTrue:[ ... ] (MetacelloPlatform current defaultPlatformAttributes includes: '#pharo1.2') ..... (MetacelloPlatform current defaultPlatformAttributes includes: '#gemstone2.4') .....
Actually not. Dependency on Metacello is not what I want. Metacello is is not maintained on GST or VAST, after all.
Or are you trying to get very very cross platform (e.g. GST, VAST, etc...) ?
Yes. Just to make myself clear, I did not proposed this to solve some problem I'm facing now. It's just that this very simple idiom has proved itself over years, and almost certainly cannot break anything, so I decided to contribute. Jan
Jan Vrany wrote
On Sun, 2014-10-05 at 10:29 +0200, Johan Brichau wrote:
Itâs true that when you do a lot of cross-dialect development, such a method is often what you desire. However, I think itâs better to do feature detection instead of dialect detection. So, something like:
((Smalltalk includesKey: #CharacterWriteStream) ifTrue:[ stream := CharacterWriteStream on: (String new: 10) ] ifFalse:[ stream := WriteStream on: (String new: 10) ]
Right, in this example it could eventually work. Another concrete example I bumped just yesterday. The "feature testing" code would look like
((Character respondsTo: #to:) and:[($a to: $z) isKindOf: Interval]) ifTrue:[ ... ] ifFalse:[ ... ].
(true, in this very case you may be able to get around using different method, but you get the point, no?)
Some time ago Hilaire posted a very nice, 15 lines long code that does reliable "feature detection" whether the system is Pharo 2.0 or 3.0 (or similar, I don't remember exactly).
Is the interval testing code above more robust? Perhaps. Is it more readable, more intention revelaling? I doubt it.
While I can agree that feature testing is is better, however, in my experience it is very tricky if the code does not provide support for such tests.
And yes: use Grease where applicable. We try to maintain Grease across Pharo, Squeak and Gemstone. I also think itâs actively ported to VA.
That's great. But having such dependency is exactly what I, and not only me, don't want if it would be for only one or two methods. The aim is to provide a simple solution for simple cases, not a silver bullet.
Jan
cheers Johan
On 05 Oct 2014, at 09:00, stepharo <
stepharo@
> wrote:
Hi jan
Thanks for the proposal. I thought about it and I'm against because it goes again the idea of dispatch. I prefer to have a class and some dispatch. Seaside with Grease is the way to go from my perspective. Finally I do not want such methods in the systems because I spent my time removing isXXXX because of bad design. Let us see what other people think.
Stef
On 4/10/14 22:14, Jan Vrany wrote:
Hi guys,
I've just opened:
https://pharo.fogbugz.com/f/cases/14160/Introduce-isXXX-dialect-testing-meth...
Introduce isXXX (isPharo, isVisualWorks, ...) dialect testing methods
to
SmalltalkImage to ease multi-dialect development.
RATIONALE:
Commonly used approach to solve differences among dialect is to use a sort of platform object and dispatch there for troublesome operations that has to be specialized. This platform object is usually in platform specific package. Other option is to load some library like Grease or Sport.
The problem of the first approach is that brings to much (unnecessary) burden when used for two, three things. The amount of of the code and management is way to bigger then the amount of the code that has to be specialized. Loading Grease/Sport on the other hand introduces a dependency on an external package - not worth of for two or three things.
The proposed dialect testing messages would allow for simple, #ifdef-like idiom like:
| stream | ... ((Smalltalk respondsTo: #isSomeCoolDialect) and:[Smalltalk isSomeCoolDialect]) ifTrue:[ stream := CharacterWriteStream on: (String new: 10) ] ifFalse:[ stream := WriteStream on: (String new: 10) ]
The #respondsTo: check, while not nice, is required as at the moment not all dialects could be trusted to have these testing messages.
Putting these methods may not stick with Pharo standard (whatever it is), but Smalltalk global is probably one of the very few that are present in pretty much every Smalltalk implementation. Other option would be to place them to the class side of an Object (which is amost certainly present everywhere), however
Smalltalk isPharo
reads better than
Object isPharo.
Best, Jan
-- View this message in context: http://forum.world.st/Issue-14160-Introduce-isXXX-dialect-testing-methods-to... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Speaking as the maintainer of an external package (OSProcess/CommandShell) I agree with both Stef and Johan. Feature detection is better, because "pharo" (or "squeak", or "gemstone") is meaningless over time as the dialect changes. If you need to test for some feature, it is better to test for it explicitly than to assume that it exists in all versions of a specified dialect. As Stef says, Seaside with Grease is the way to go. The test for any given feature belongs in an external package (Grease), not in the core images. For a significant external package such as Seaside, use the abstraction layer of Grease. For simpler cases (e.g. OSProcess) put the required tests directly into that external package. But either way the isFoo tests belong in the external packages, and not in pharo/squeak/gemstone proper. Dave On Sun, Oct 05, 2014 at 10:29:26AM +0200, Johan Brichau wrote:
It?s true that when you do a lot of cross-dialect development, such a method is often what you desire. However, I think it?s better to do feature detection instead of dialect detection. So, something like:
((Smalltalk includesKey: #CharacterWriteStream) ifTrue:[ stream := CharacterWriteStream on: (String new: 10) ] ifFalse:[ stream := WriteStream on: (String new: 10) ]
And yes: use Grease where applicable. We try to maintain Grease across Pharo, Squeak and Gemstone. I also think it?s actively ported to VA.
cheers Johan
On 05 Oct 2014, at 09:00, stepharo <stepharo@free.fr> wrote:
Hi jan
Thanks for the proposal. I thought about it and I'm against because it goes again the idea of dispatch. I prefer to have a class and some dispatch. Seaside with Grease is the way to go from my perspective. Finally I do not want such methods in the systems because I spent my time removing isXXXX because of bad design. Let us see what other people think.
Stef
On 4/10/14 22:14, Jan Vrany wrote:
Hi guys,
I've just opened:
https://pharo.fogbugz.com/f/cases/14160/Introduce-isXXX-dialect-testing-meth...
Introduce isXXX (isPharo, isVisualWorks, ...) dialect testing methods to SmalltalkImage to ease multi-dialect development.
RATIONALE:
Commonly used approach to solve differences among dialect is to use a sort of platform object and dispatch there for troublesome operations that has to be specialized. This platform object is usually in platform specific package. Other option is to load some library like Grease or Sport.
The problem of the first approach is that brings to much (unnecessary) burden when used for two, three things. The amount of of the code and management is way to bigger then the amount of the code that has to be specialized. Loading Grease/Sport on the other hand introduces a dependency on an external package - not worth of for two or three things.
The proposed dialect testing messages would allow for simple, #ifdef-like idiom like:
| stream | ... ((Smalltalk respondsTo: #isSomeCoolDialect) and:[Smalltalk isSomeCoolDialect]) ifTrue:[ stream := CharacterWriteStream on: (String new: 10) ] ifFalse:[ stream := WriteStream on: (String new: 10) ]
The #respondsTo: check, while not nice, is required as at the moment not all dialects could be trusted to have these testing messages.
Putting these methods may not stick with Pharo standard (whatever it is), but Smalltalk global is probably one of the very few that are present in pretty much every Smalltalk implementation. Other option would be to place them to the class side of an Object (which is amost certainly present everywhere), however
Smalltalk isPharo
reads better than
Object isPharo.
Best, Jan
OK. I think enough has been said. No need to waste more time on it. I closed the issue. Thanks Nicolai for making the slice for me! Best, Jan On Sat, 2014-10-04 at 21:14 +0100, Jan Vrany wrote:
Hi guys,
I've just opened:
https://pharo.fogbugz.com/f/cases/14160/Introduce-isXXX-dialect-testing-meth...
Introduce isXXX (isPharo, isVisualWorks, ...) dialect testing methods to SmalltalkImage to ease multi-dialect development.
RATIONALE:
Commonly used approach to solve differences among dialect is to use a sort of platform object and dispatch there for troublesome operations that has to be specialized. This platform object is usually in platform specific package. Other option is to load some library like Grease or Sport.
The problem of the first approach is that brings to much (unnecessary) burden when used for two, three things. The amount of of the code and management is way to bigger then the amount of the code that has to be specialized. Loading Grease/Sport on the other hand introduces a dependency on an external package - not worth of for two or three things.
The proposed dialect testing messages would allow for simple, #ifdef-like idiom like:
| stream | ... ((Smalltalk respondsTo: #isSomeCoolDialect) and:[Smalltalk isSomeCoolDialect]) ifTrue:[ stream := CharacterWriteStream on: (String new: 10) ] ifFalse:[ stream := WriteStream on: (String new: 10) ]
The #respondsTo: check, while not nice, is required as at the moment not all dialects could be trusted to have these testing messages.
Putting these methods may not stick with Pharo standard (whatever it is), but Smalltalk global is probably one of the very few that are present in pretty much every Smalltalk implementation. Other option would be to place them to the class side of an Object (which is amost certainly present everywhere), however
Smalltalk isPharo
reads better than
Object isPharo.
Best, Jan
Jan Vrany wrote:
OK.
I think enough has been said. No need to waste more time on it. I closed the issue. Thanks Nicolai for making the slice for me!
Best, Jan
Thanks for the attempt. Even though I didn't like the isAxxx pattern, and feature testing is better, you have me thinking that a common paradigm for dialect testing in a more OO fashion could be useful. There was no feedback on my earlier proposal. I've refactored it slightly. I see the following advantages: * Promotes an OO pattern * Low overhead is USER code for a "small" number of methods * When you grow beyond a "small" number of such methods, its easier to refactor them out to your own dialect specific classes. ====WITH THE FOLLOWING IN ALL SMALLTALK DIALECT RELEASES==== Object subclass: Dialect classVariable: 'CurrenDialect'. ---- Dialect subclass: DialectPharo. ---- Dialect subclass: DialectVAST. ---- Dialect>>dialect " ^ DialectPharo " "In Pharo" " ^ DialectVAST " "In VAST" ====USERS COULD HAVE THE FOLLOWING AS EXTENSIONS==== Dialect>>myWhoAmI self dialect myMethod: aString" ---- DialectPharo>>myWhoAmI ^ 'I am Pharo' ---- DialectVAST>>myWhoAmI ^ 'I am VAST' ---- ====USED LIKE THIS==== Dialect>>someWorkingMethod Transcript show: Dialect myWhoAmI. What is not to like? :) Could I reopen that ticket(renamed "Introduce dialect testing classes")? cheers -ben
On Sat, 2014-10-04 at 21:14 +0100, Jan Vrany wrote:
Hi guys,
I've just opened:
https://pharo.fogbugz.com/f/cases/14160/Introduce-isXXX-dialect-testing-meth...
Introduce isXXX (isPharo, isVisualWorks, ...) dialect testing methods to SmalltalkImage to ease multi-dialect development.
RATIONALE:
Commonly used approach to solve differences among dialect is to use a sort of platform object and dispatch there for troublesome operations that has to be specialized. This platform object is usually in platform specific package. Other option is to load some library like Grease or Sport.
The problem of the first approach is that brings to much (unnecessary) burden when used for two, three things. The amount of of the code and management is way to bigger then the amount of the code that has to be specialized. Loading Grease/Sport on the other hand introduces a dependency on an external package - not worth of for two or three things.
The proposed dialect testing messages would allow for simple, #ifdef-like idiom like:
| stream | ... ((Smalltalk respondsTo: #isSomeCoolDialect) and:[Smalltalk isSomeCoolDialect]) ifTrue:[ stream := CharacterWriteStream on: (String new: 10) ] ifFalse:[ stream := WriteStream on: (String new: 10) ]
The #respondsTo: check, while not nice, is required as at the moment not all dialects could be trusted to have these testing messages.
Putting these methods may not stick with Pharo standard (whatever it is), but Smalltalk global is probably one of the very few that are present in pretty much every Smalltalk implementation. Other option would be to place them to the class side of an Object (which is amost certainly present everywhere), however
Smalltalk isPharo
reads better than
Object isPharo.
Best, Jan
2014-10-06 22:26 GMT-03:00 Ben Coman <btc@openinworld.com>:
Dialect>>someWorkingMethod Transcript show: Dialect myWhoAmI.
What is not to like? :) Could I reopen that ticket(renamed "Introduce dialect testing classes")?
I prefer feature detection, but if you go through this Dialect thing please use something else as the name of the root class instead of plain "Dialect". E.g. SmalltalkDialect. :) Regards!
participants (7)
-
Ben Coman -
David T. Lewis -
Esteban A. Maringolo -
Jan Vrany -
Johan Brichau -
Paul DeBruicker -
stepharo