Hi,
sorry to jump in the middle of a discussion, and also sorry if this will be
only noise (i don't know about VMMaker), but I had to fight with
compatibility for long time, so, here is what I did and still do (I had to
support and still supporting  some business framework on VASmalltalk,
VSESmalltalk and VisualWorks)

What we did was to define a common layer of services, represented by the
classes needing compatibility work, and replicate that common classes on
every dialect .
The end result was that my code was working against the same classes and
same methods, but every dialect had the specific set of compatibility
classes preloaded.
So, if for example File is the chosen class name, the compatibility package
will include File for the dialect(s) where it is missing, and the
differences will be inside this class, but exposed using a common interface
valid for all of the dialects.
This way we have no if in the code for testing which dialect we are in, and
all of the differences are kept on a single place we load on every
different dialect.
It was pretty easy to add VW when I started working in it after VSE and VA
(just look at all of the compatibility classes/methods and replicate them
for VW) , and I'll use same approach for moving to Pharo, when needed.
It's also easy to increment; As we find a different case, we add methods or
classes. Note that we have also compatibility for things like showing the
user a directory dialog for choosing file, or yes no dialog , etch. it's a
complex business framework....

I don't  know if this can helps, probably it's too late... or is just not
useful based on your taste or your point of view or the problems in hand.
 Hope not bothering the list too much. ( I'm noticing that lately the
Smalltalk community  gets upset easily ... long time passed since
everything resolved in front of a beer or two ...)

long life Smalltalk :) and thank you all for the work done (all of you...)

giorgio

BTW,  I have to say that I really don't understand sometime the continuous
jumping to different names also when it does'n seems needed (but probably
it's my problem... I'm getting old and lazy ). Stay compatible seems for me
a target, we are such a small community... but i'm surely wrong.




On Wed, Feb 20, 2019 at 2:18 PM David T. Lewis <lewis at mail.msen.com> wrote:

> On Wed, Feb 20, 2019 at 09:23:55AM +0100, Tudor Girba wrote:
> >
> > Hi,
> >
> > I have seen that code, and the issue I wanted to address is to have the
> > decision about which dialect a piece of code is ran on in one single
> place.
> > This should make it easier to find statically.
> >
> > Indeed, this will not necessarily be guaranteed to work when moving from
> > one version of Pharo to another. But, that problem can be addressed by
> > tracing releases in a reproducible fashion. And in the VMMaker case, the
> > scenario is about a development environment not a production system. So,
> > it should be reasonable to point developers to a working configuration
> > that pairs the Pharo/Squeak version and the VMMaker version.
> >
> > What do you think?
> >
> > Cheers,
> > Doru
> >
>
> Hi Doru and Eliiot,
>
> The approach that I have been using to address this in OSProcess is
> to put the compatibility methods in one place, in the 'compatibility'
> category in class OSProcess. This allows support for the different
> file system interfaces in Cuis, Pharo and Squeak.
>
> For example, one of the compatibility methods is:
>
> OSProcess class>>directoryExists: path
>         "Answer true if a directory of the given name exists. The given
> name may
>         be either a full path name or a local directory within this
> directory."
>
>         ^ self useFileMan
>                 ifTrue: [((Smalltalk at: #DirectoryEntry) perform:
> #withPathName: with: path) exists]
>                 ifFalse: [self useFileSystem
>                         ifTrue: [ (path perform: #asFileReference) exists ]
>                         ifFalse: [ (Smalltalk at: #FileDirectory) default
> directoryExists: path ]]
>
>
> And the tests for Cuis/Pharo/Squeak are in these two methods:
>
> OSProcess class>>useFileSystem
>         "If true use FileSystem, otherwise use traditional FileDirectory.
> See senders
>         for methods with file system dependencies."
>
>         ^ Smalltalk hasClassNamed: #FileReference
>
> OSProcess class>>useFileMan
>         "If true use FileMan for directory and file access. See senders
> for methods with file
>         system dependencies."
>
>         ^ Smalltalk hasClassNamed: #FileIOAccessor
>
>
> This is ugly but it does work, and I been able to maintain OSProcess and
> CommandShell for the Squeak diaspora over a number of years in this manner.
> It also means that I do not need to worry if Squeak moves to FileMan(*) or
> FileSystem at some point in the future.
>
> I don't think that VMMaker should have a hard dependency on OSProcess,
> but as a practical matter you probably have OSProcess loaded in the VM
> development image anyway, so you could try using these methods directly
> and see how ugly things get.
>
> HTH,
> Dave
>
> * Personally I like the FileMan approach in Cuis best, but that is
> another topic entirely ;-)
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190220/5f5a2455/attachment.html>