Hi All instances of HumanBeing
Then, another question remains:
Will my image of 2011 still work correctly
on the VM of AD 2019 (the ones that than probably
run on Ubuntu 2019.10, Windows11 and AppleOS/X 2019)?
or the VM created for a newly emerged computer system?
"All" I wish for is:
-= Backward Source Compatibilty =-
whenever possible because:
-in five years the one could have written a huge amount of coding,
for instance, a large ERP system, or an large internet trading
system. Often these consists of (10)thousands of lines
of coding, even in Smalltalk. Many years of development and
effort, blood sweat and tears have gone in to it.
Finally everything is debugged and tested. And may happy
users depend on it
Assume that throughout this all coding are countless
references to classes that are perfectly normal at the
time of writing. This no exception.
Then one or tow releases later:
If these classes are removed, because The Respectful
Tool Developers (e.g. (not only) Pharo) in their wisdom find it
necessary to render these obsolete, then this has enormous
consequences:
One would have to edit and test, and in some cases rewrite (!)
very large amounts of coding costing considerable amounts
of time=money.
Now, imagine yourself as an application programmer maintaining
this huge amount of coding, which is not working anymore,
not because you did it wrong, but because of chances in the
Developmen Tool? How would feel? Like shit. Tons of work
gone down the drain. Besides, are you going to ask your
customer to pay for this? You can't of course. He/she will
say things like: "Why? It works perfectly!"etc.
Naturally one wishes to migrate to new images releases and
happily utilize the new features that come with it, no question
about it. But as it seems now, this is out of the question,
because with every release, things are taken out, changed
without any respect to backward compatibility.
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.
Why not have the best of both worlds? What's the problem?
Things can live next to each other, if you do it well.
If you don't I can only resort to the most basic of
system core classes. Ergo: limit myself to what I am
(reasonable certain of)
I see lines on this forum like:
"Seems to be unused. I vote for removing.."
Assuming is a bad thing in software development.
How can you be certain that:
No one really uses the component anymore?
You can't.
The essence of it all is:
I saw Pharo fit to write production software,
especially with Seaside!
but how can I use it for this, seen the above
described arguments? If all the things
I write become useless with a next release?
(Sorry, we don't sell tires for your
car anymore, because we chanced
the diameter of them, we recommend
you to change/modify your car.. )
A perfect example:
(most) internet browsers
are backward compatible.
I rest my case, enough said..
Kind regards
Ted
On Mon, May 2, 2011 at 4:03 PM, Igor Stasenko <[email protected]> wrote:
> On 2 May 2011 00:48, Markus Fritsche <[email protected]> wrote:
>> Hi,
>>
>> 2011/4/27 Mariano Martinez Peck <[email protected]>:
>>> And as Marcus said, most of the times (sometimes we had some problems) we
>>> have a deprecation process where we (usually) say which should be used
>>> instead.
>>
>> From a a-little-bit-more-than-user perspective I am looking at
>>
>> SmalltalkImage>>#hasBindingThatBeginsWith: aString
>> self deprecated: 'Use Smalltalk globals'.
>> ^globals hasBindingThatBeginsWith: aString
>>
>> Well, with a bit of analysis, I would be able to figure out, that the
>> author might have intended that I should search the SystemDictionary
>> myself. I feel like an additional comment would have been helpful.
>>
>> Same with the other problem I had with ServiceRegistry - it is gone
>> and it is not easy to find out what that was supposed to do. Next step
>> is to compare squeak and the Pharo releases to find out what happened
>> to it (the issue tracker does not easily yield results for this, but
>> maybe I searched in the wrong way).
>>
>> I know there is no easy fix for this, as "fast deprecation" was what
>> made Pharo manageable compared to other image-based smalltalk dialects
>> (not to mention anything specific ;)) but there is a lot of
>> interesting code on squeaksource that naturally breaks - for those
>> interested in that code, it would be helpful to give a bit more advice
>> on "porting" and "the path of deprecation".
>>
>
> An advice is simple:
> 1. try loading the code using most recent image, try running it.
> 2. fix errors & bugs you found
> 3. Repeat from 1.
>
> This is what package maintainers should usually do all the time.
> And there is no magic: you have to get your hands dirty and make
> things work (again).
>
> Now, if nobody doing it for years, its not a Pharo failure that some
> code turned to be broken.
> I like that pharoers are not afraid to break things (of course if they
> breaking them for good ;).
>
> And besides.. you can always use years old image and happily load all
> code in it and it will work there.
>
> So, you are free to choose either:
> - stay with old image version where all dusty code working
> - running your code on most recent Pharo version and using its new features
> :)
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>
