subject:"Re\: \[Pharo\-dev\] Issue 14160\: Introduce isXXX dialect testing methods to SmalltalkImage to ease cross\-dialect development"

Re: [Pharo-dev] Issue 14160: Introduce isXXX dialect testing methods to SmalltalkImage to ease cross-dialect development

2014-10-06 Thread Jan Vrany

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 lt;

stepharo@

gt; 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 is 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-methods-to-SmalltalkImage-to-ease-cross-dialect-development

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

Re: [Pharo-dev] Issue 14160: Introduce isXXX dialect testing methods to SmalltalkImage to ease cross-dialect development

2014-10-06 Thread Jan Vrany

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-methods-to-SmalltalkImage-to-ease-cross-dialect-development

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 proposed dialect testing messages would allow for simple,
#ifdef-like idiom like:

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

Re: [Pharo-dev] Issue 14160: Introduce isXXX dialect testing methods to SmalltalkImage to ease cross-dialect development

2014-10-06 Thread Ben Coman

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.

Dialectdialect
^ DialectPharo In Pharo
^ DialectVASTIn VAST

USERS COULD HAVE THE FOLLOWING AS EXTENSIONS
DialectmyWhoAmI
self dialect myMethod: aString

DialectPharomyWhoAmI
^ 'I am Pharo'

DialectVASTmyWhoAmI
^ 'I am VAST'

USED LIKE THIS
DialectsomeWorkingMethod
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-methods-to-SmalltalkImage-to-ease-cross-dialect-development

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 proposed dialect testing messages would allow for simple,
#ifdef-like idiom like:

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

Re: [Pharo-dev] Issue 14160: Introduce isXXX dialect testing methods to SmalltalkImage to ease cross-dialect development

2014-10-06 Thread Esteban A. Maringolo

2014-10-06 22:26 GMT-03:00 Ben Coman b...@openinworld.com:
 DialectsomeWorkingMethod
 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!

Re: [Pharo-dev] Issue 14160: Introduce isXXX dialect testing methods to SmalltalkImage to ease cross-dialect development

2014-10-05 Thread Johan Brichau

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 steph...@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 is 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-methods-to-SmalltalkImage-to-ease-cross-dialect-development
 
 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

Re: [Pharo-dev] Issue 14160: Introduce isXXX dialect testing methods to SmalltalkImage to ease cross-dialect development

2014-10-05 Thread Ben Coman


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-practices-on-cross-device-development

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 steph...@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 is 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-methods-to-SmalltalkImage-to-ease-cross-dialect-development

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...

--

CrossPlatformplatform
^ CurrentPlatform ifNil: [ --class variable
CurrentPlatform := self class subClasses detect:
[   :candidatePlatformClass |
candidatePlatformClass isCurrentPlatform

CrossPlatform subclass: SomeCoolDialect.

SomeCoolDialectisCurrentPlatform
^ (Smalltalk version includesSubstring: 'SomeCoolDialect')

--

CrossPlatformwriteStreamOn: aString
self platform writeSteamOn: aString

SomeCoolDialectwriteStreamOn: 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

Re: [Pharo-dev] Issue 14160: Introduce isXXX dialect testing methods to SmalltalkImage to ease cross-dialect development

2014-10-05 Thread Jan Vrany

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.

Jan

cheers
Johan

On 05 Oct 2014, at 09:00, stepharo steph...@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 is 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-methods-to-SmalltalkImage-to-ease-cross-dialect-development

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 proposed dialect testing messages would allow for simple,
#ifdef-like idiom like:

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

Re: [Pharo-dev] Issue 14160: Introduce isXXX dialect testing methods to SmalltalkImage to ease cross-dialect development

2014-10-05 Thread Paul DeBruicker

Would using Metacello's knowledge of the platform work for you? e.g.