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