On Thu, Sep 3, 2015 at 1:33 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 03 Sep 2015, at 06:01, H. Hirzel <hannes.hirzel@gmail.com> wrote:
On 9/2/15, Sven Van Caekenberghe <sven@stfx.eu> wrote:
But Timestamp was already removed completely from 4.0, why re-add it, even deprecated ?
Because it will be added in a compatibility layer package which is only loaded by packages which need it. There might be other things in the Pharo 5/4 compatibility package.
But still, if external packages do load that code, they will never have to change, and the class will remain in the image forever.
It is like when you load certain Squeak packages that are 'ported' with compatibility layers to Pharo: they just add again all the methods that we tried to clean up.
Unfortunately this is a pragmatic engineering approach to porting. I haven't done a lot of this in practice, but I expect much of the effort in replacing deprecated methods in applications is ensuring that the replacement *really* is functionally equivalent. So the quickest route is reintegrating those methods. The downside is that: * When reading existing code, use of deprecated method is not obvious. * Deprecated methods can be accidently reused for new code. So just brainstorming... perhaps these downsides can be addressed by a deprecation-compatability package that makes use of it more explicit by prepending each deprecated method with "deprecatedNN", e.g... SomeClass>>xyz self deprecated: 'Blahblah' on: 'April 2015' in: #Pharo4.0. self deprecated40xyz. SomeClass>>deprecated40xyz "original code or call to replacement code..." So this splits porting into a few steps. 1. Loading the deprecation-compatability package gives *functional-equivalence* with Deprecation Warnings turned off. 2. Gradually (manually or with rewrite tool) replacing #xyz calls with #deprecated40xyz calls, results in *functionally-equivalent* but *ugly* and obvious code. 3. Gradually migrate #deprecated40xyz calls to whatever the final replacement is. 4. Easy to search for remaining users of #deprecated40 and when none are left (btw, is there a deprecation-compatability package/repository somewhere? I couldn't see one on Smalltalkhub) cheers -ben
--HH
I am sure many external packages are already modified, I know I did it for mine.
On 02 Sep 2015, at 13:19, Marcus Denker <marcus.denker@inria.fr> wrote:
On 02 Sep 2015, at 12:32, stepharo <stepharo@free.fr> wrote:
Hi guille
there is not stress. I just wanted to let you know. I was wondering if just subclassing DateAndTime would not be enough for now.
Yes, as far as I remember Timestamp was just an empy subclass.
We could:
-> add it back to Deprecated50 or maybe even to a âCompatibilityâ package -> Write a Quality Check rule.
I will go back to code with Pharo 40
stef
Le 2/9/15 10:30, Guillermo Polito a écrit :
If somebody can check it and fix it it would be good :). I've just started my new job and my evenings are busy looking for an apartment or staying in a hostel without a proper internet connection...
If not, I think we can wait a bit. The first step should be enabling CI jobs for pharo5. Also, I do not think the intersection between 'people using garage opendbx' and 'people using pharo5' is that big to justify a rush.
Guille
El mié., 2 de sept. de 2015 a la(s) 10:12 a. m., stepharo <stepharo@free.fr> escribió: for your info...
Garage-OpenDBX does not load on Pharo 50 because it uses Timestamp
Stef