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