>> >>> Hi,
>> >>>
>> >>> is there a way to get the #ifNotNilDo: behavior to write compatible
>> >>> Squeak and Pharo code?
>> >>>
>> >>>
>>     
> >> >> -> do not use ifNotNilDo: >> -> use ifNotNil: without the
> argument. >> >> The real fix of course would be for Squeak adopting
> the optinal args >> changeset >> (this is from 2007...)
> > The Author class is  another
> > incompatibility issue that I expect to have to address via LPF. Are
> > there any more?
> Thousands. Literally.
>
> I am highly skeptical about LPF.
>
> 	Marcus
Hello Marcus,

I don't think that you understand, LPF is only about providing a leg up
for the older code, a migration path for fundamental stuff, like Monticello.

You appear to have adopted the view that LPF (
http://installer.pbwiki.com/LevelPlayingField ) is supposed to make the
whole image up to the same level for everyone. It isn't, it works for
what it was intended to do, that is to provide
Installer/MC/MCC/Sake/Packages/PackageInfo for all images.

In this case, I do hope that Pharo hasn't made thousands of changes
which prevent code from loading and compiling in Squeak. That is the
issue that ifNotNil: [ :a | ] and Author raises, Syntax errors on
loading. I am sure that LPF can help there in the majority of cases.

Most projects are built in layers, the fundamental layers, once ported
may support other layers across all images. LPF is primarily about
loading code across images. Getting that code to work is another problem
entirely which LPF may help with, but is not expected to solve. Perhaps
a concrete example might help illustrate what the issues really are:

You guys developed your Monticello for 3.9, and it wasn't compatible
with 3.8, 3.8 code loaded into 3.9 but not the other way around, and the
3.9 Monticello implementation itself was never designed to be loaded in
3.8. In short the 3.8 Monticello became dead to innovation (a fork by
default rather than by design), and unmaintained overnight, as did a lot
of 3.8 code.

This is the issue that LPF was designed to address. The purpose of LPF
is to help prevent projects getting completely stuck on one image,
particularly to enable projects stuck in 3.8 to move to 3.10.

When you want to port a large commercial project from one image to
another you want to support your existing users in the old image at the
same time as working on the next version in the new base image.. You
want to continue to manage your packages simply without having to keep
two separate branches. MC in 3.9 would not save mcz files that would
load into 3.8, and this fact alone was a real barrier to moving things
forward.

The new 3.11 development process, aims to address this. Tools, fixes,
and API's that may be included in 3.11, will be developed and usable in
3.10. So both the current user base in 3.10, and the early adopters in
3.11 are able to use identical API's and Tools, and migration is both
possible and probable.

The traditional approach that Pharo is using produces a new image,
developed by a new team as a complete break from the past, and everyone
is forced to code to a moving target. This is the process that squeak
has been using since before the flood, and it is this process that I
have identified as the problem. (I accept that I may be wrong)

I myself haven't adopted Pharo, not because you aren't making good
changes, or making things better, but because your development process
guarantees that there will be problems down the line. Not only do you
make it difficult for me to port my current deployments to Pharo with
anything other than a step change, since that is your avowed intent. But
also Pharo 2 will inevitably be incompatible with Pharo1 and so on, due
to the process.

I thank the pharo team for performing lots of useful research on behalf
of the squeak community, I expect that we will be able to adopt most of
your innovations, but this will take time, and will be carefully
considered, with the backward compatabiity issue in mind.

regards

Keith