On Thu, Sep 3, 2015 at 1:33 PM, Sven Van Caekenberghe <[email protected]> wrote:
>
>> On 03 Sep 2015, at 06:01, H. Hirzel <[email protected]> wrote:
>>
>> On 9/2/15, Sven Van Caekenberghe <[email protected]> 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 <[email protected]> wrote:
>>>>
>>>>
>>>>> On 02 Sep 2015, at 12:32, stepharo <[email protected]> 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
>>>>>> <[email protected]> escribió:
>>>>>> for your info...
>>>>>>
>>>>>> Garage-OpenDBX does not load on Pharo 50 because it uses Timestamp
>>>>>>
>>>>>> Stef
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
