Posted by
Marcus Denker on
Feb 22, 2009; 7:10pm
URL: https://forum.world.st/What-about-ifNotNil-and-ifNotNilDo-tp1309537p1309541.html
On 22.02.2009, at 19:31, Marcus Denker wrote:
I added a comment to the squeak bugtracker to suggest that this should
be done.
>>
>> What would help though is if you told us what you are changing/
>> breaking
>> so that we can do something about it. 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.
To clearify: I am not skeptical about the *intention* of LPF. I am
only very
sure that it is impossible to do. Especially considering complexity
involved
and the interdependencies of changesets.
e.g. we will soon check this fix for the ifNotNil stuff:
http://code.google.com/p/pharo/issues/detail?id=327this for sure overrides code touched by the changeset of vasili. So,
in turn,
LPF can not just load the original changeset for pharo, as it will
revert the fix.
Then, do Lukas compiler changes for literal byte-arrays touch the same
methods? They
should not, but are you sure? So you need to check this, by hand....
As soon as there are changesets that touch the same code, it starts to
get *very* messy.
(it's the same reason why overrides do not work. I override a method,
second package overrides
same method. So my changes are reverted. Ups. So I fix my package to
take the changes into
account. Now two things happen: 1) dependency. my package can only be
installed *after* the
other package. 2) un-installing. Un-installing, even if you track the
method's versions, can
only be done in reverse-order of installation, and thus is useless for
most cases).
Inter-dependencies of changesets is something that I completely
underestimated at first.
Another thing that is true especially for Squeak is that changes have
a very non-linear effect:
everything is entangled. That means that things depend on each other
in ways that are absolutely
astonishing. You change something small, and it breaks something else
in a way that you would bet
your house on that it would have no effect. (like changing a method
comment for a good joke braking
compacting of the .changes, as we saw today).
This means, there is nothing else that one can do then *testing*. And
as sooner code is in general
use, the sooner it will get more stable. There is no other way to work
on Squeak than in tiny increments
and "release early, release often". Everyting else *will* fail.
Marcus
--
Marcus Denker --
[hidden email]
http://www.marcusdenker.de_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project