<div dir="ltr"><div dir="ltr"><div dir="ltr">Hi, <div>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)</div><div><br></div><div>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 .</div><div>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. </div><div>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.</div><div>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.</div><div>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. </div><div>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....</div><div><br></div><div>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.</div><div> 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 ...)</div><div><br></div><div>long life Smalltalk :) and thank you all for the work done (all of you...)</div><div><br></div><div>giorgio</div><div><br></div><div>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.<br></div><div><br></div><div><br></div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 20, 2019 at 2:18 PM David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Wed, Feb 20, 2019 at 09:23:55AM +0100, Tudor Girba wrote:<br>
> <br>
> Hi,<br>
> <br>
> I have seen that code, and the issue I wanted to address is to have the<br>
> decision about which dialect a piece of code is ran on in one single place.<br>
> This should make it easier to find statically.<br>
> <br>
> Indeed, this will not necessarily be guaranteed to work when moving from<br>
> one version of Pharo to another. But, that problem can be addressed by<br>
> tracing releases in a reproducible fashion. And in the VMMaker case, the<br>
> scenario is about a development environment not a production system. So,<br>
> it should be reasonable to point developers to a working configuration<br>
> that pairs the Pharo/Squeak version and the VMMaker version.<br>
> <br>
> What do you think?<br>
> <br>
> Cheers,<br>
> Doru<br>
> <br>
<br>
Hi Doru and Eliiot,<br>
<br>
The approach that I have been using to address this in OSProcess is<br>
to put the compatibility methods in one place, in the 'compatibility'<br>
category in class OSProcess. This allows support for the different<br>
file system interfaces in Cuis, Pharo and Squeak.<br>
<br>
For example, one of the compatibility methods is:<br>
<br>
OSProcess class>>directoryExists: path<br>
"Answer true if a directory of the given name exists. The given name may<br>
be either a full path name or a local directory within this directory."<br>
<br>
^ self useFileMan<br>
ifTrue: [((Smalltalk at: #DirectoryEntry) perform: #withPathName: with: path) exists]<br>
ifFalse: [self useFileSystem<br>
ifTrue: [ (path perform: #asFileReference) exists ]<br>
ifFalse: [ (Smalltalk at: #FileDirectory) default directoryExists: path ]]<br>
<br>
<br>
And the tests for Cuis/Pharo/Squeak are in these two methods:<br>
<br>
OSProcess class>>useFileSystem<br>
"If true use FileSystem, otherwise use traditional FileDirectory. See senders<br>
for methods with file system dependencies."<br>
<br>
^ Smalltalk hasClassNamed: #FileReference<br>
<br>
OSProcess class>>useFileMan<br>
"If true use FileMan for directory and file access. See senders for methods with file<br>
system dependencies."<br>
<br>
^ Smalltalk hasClassNamed: #FileIOAccessor<br>
<br>
<br>
This is ugly but it does work, and I been able to maintain OSProcess and<br>
CommandShell for the Squeak diaspora over a number of years in this manner.<br>
It also means that I do not need to worry if Squeak moves to FileMan(*) or<br>
FileSystem at some point in the future.<br>
<br>
I don't think that VMMaker should have a hard dependency on OSProcess,<br>
but as a practical matter you probably have OSProcess loaded in the VM<br>
development image anyway, so you could try using these methods directly<br>
and see how ugly things get.<br>
<br>
HTH,<br>
Dave<br>
<br>
* Personally I like the FileMan approach in Cuis best, but that is<br>
another topic entirely ;-)<br>
<br>
<br>
<br>
</blockquote></div>