Garage-OpenDBX does not load on Pharo 50 because it uses Timestamp

for your info...

     Garage-OpenDBX does not load on Pharo 50 because it uses Timestamp

Stef

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.
I will go back to code with Pharo 40

stef

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 <[hidden email]> escribió:

for your info...

     Garage-OpenDBX does not load on Pharo 50 because it uses Timestamp

Stef

Yes!!!! marcus it would be a good idea.

Stef

On 02 Sep 2015, at 12:32, stepharo <[hidden email]> 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 <[hidden email]> escribió:

for your info...

     Garage-OpenDBX does not load on Pharo 50 because it uses Timestamp

Stef

But Timestamp was already removed completely from 4.0, why re-add it, even deprecated ?

I am sure many external packages are already modified, I know I did it for mine.

On 9/2/15, Sven Van Caekenberghe <[hidden email]> 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.

--HH

> I am sure many external packages are already modified, I know I did it for
> mine.

On 9/2/15, Marcus Denker <[hidden email]> wrote:                                                                              +1

> On 03 Sep 2015, at 06:01, H. Hirzel <[hidden email]> wrote:
>
> On 9/2/15, Sven Van Caekenberghe <[hidden email]> 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.

On Thu, Sep 3, 2015 at 1:33 PM, Sven Van Caekenberghe <[hidden email]> wrote:
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

We should update Garage :)

Stef


Le 2/9/15 13:35, Sven Van Caekenberghe a écrit :