On May 2, 2011, at 6:49 PM, Ted F.A. van Gaalen wrote:
>
> I might suggest. for instance:
> - leave deprecated classes in. when ever possible!
> if you can't, then rewrite them as a sort of emulation
> encapsulation, thus a kind of shell, invoking your new
> replacement class.
We want a system that is understandable. Look at Squeak with
Etoys. How can you do *anything* with that code base if you
keep it 100% compatible? Look at Pharo. How do you think you can
do anything of relevance in 2019 if you keep the system source level
compatible to 100%? This is a running Museum! And a crappy one, even.
Why do you select Pharo of 2011, why aren't we compatible to Smaltalk 80,
the orginal one. Or Smallalk 76? 72?
Why invent Smalltalk at all? Why not just be compatible to what was before?
I would even argue that etoys got into the state that it is *exactly*
because it was never refactored and cleaned up and pushed forward.
The Projects that are parts-of-images kind of force etoys to be
exactly what you want: binary compatible forever... that is why people
didn't improve the one Button, but made their own Button, because "some project
might use this class, I can not touch it".
So maybe Squeak is the solution to your problem... I am 100% sure that Squeak
in 2019 will be the same as it is now.
But it will be 100% irrelevant, *because* it will be the same as it is now.
(Or it will do what Pharo does, there is a reason for the light-house logo ;-)
Marcus
--
Marcus Denker -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.
