WeakArray>>isFinalizationSupported

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

WeakArray>>isFinalizationSupported

Sean P. DeNigris
Administrator
As I port code from Sophie, I keep running into WeakArray>>isFinalizationSupported calls.  

Why was this method removed from Pharo?  I want to make sure I understand what I'm doing when I remove these calls.

Thanks.
Sean
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: WeakArray>>isFinalizationSupported

Igor Stasenko
On 30 December 2010 23:11, Sean P. DeNigris <[hidden email]> wrote:
>
> As I port code from Sophie, I keep running into
> WeakArray>>isFinalizationSupported calls.

This is strange..
this code was introduced only since Pharo 1.2
and Squeak 4.2 images jut couple of months ago.
And of course, Pharo 1.1 images,  where you porting know nothing about
this method.

You can patch Pharo 1.1. by putting
WeakArray>>isFinalizationSupported
 ^ false
 in this method.

But i don't understand what you doing... how it could happen that
Sophie knows about (and using) this recently introduced code?

Or perhaps you trying to port Collections-Weak? which i would not
recommend to do,
because it is a part of Kernel.


>
> Why was this method removed from Pharo?  I want to make sure I understand
> what I'm doing when I remove these calls.
>
> Thanks.
> Sean
> --
> View this message in context: http://forum.world.st/WeakArray-isFinalizationSupported-tp3168849p3168849.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: WeakArray>>isFinalizationSupported

Levente Uzonyi-2
On Thu, 30 Dec 2010, Igor Stasenko wrote:

> On 30 December 2010 23:11, Sean P. DeNigris <[hidden email]> wrote:
>>
>> As I port code from Sophie, I keep running into
>> WeakArray>>isFinalizationSupported calls.
>
> This is strange..
> this code was introduced only since Pharo 1.2
> and Squeak 4.2 images jut couple of months ago.
> And of course, Pharo 1.1 images,  where you porting know nothing about
> this method.
>
> You can patch Pharo 1.1. by putting
> WeakArray>>isFinalizationSupported
> ^ false
> in this method.
>
> But i don't understand what you doing... how it could happen that
> Sophie knows about (and using) this recently introduced code?
>
> Or perhaps you trying to port Collections-Weak? which i would not
> recommend to do,
> because it is a part of Kernel.
You are mixing the methods. #isFinalizationSupported used to answer what
it's name suggests: "does the VM support any form of finalization?". What
you're thinking about is WeakFinalizationList class >> #hasNewFinalization
(or so) which is unrelated. The method was removed during a "cleanup". And
as you know, backwards compatibility is not a priority for Pharo.


Levente

>
>
>>
>> Why was this method removed from Pharo?  I want to make sure I understand
>> what I'm doing when I remove these calls.
>>
>> Thanks.
>> Sean
>> --
>> View this message in context: http://forum.world.st/WeakArray-isFinalizationSupported-tp3168849p3168849.html
>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>
Reply | Threaded
Open this post in threaded view
|

Re: WeakArray>>isFinalizationSupported

Igor Stasenko
2010/12/31 Levente Uzonyi <[hidden email]>:

> On Thu, 30 Dec 2010, Igor Stasenko wrote:
>
>> On 30 December 2010 23:11, Sean P. DeNigris <[hidden email]> wrote:
>>>
>>> As I port code from Sophie, I keep running into
>>> WeakArray>>isFinalizationSupported calls.
>>
>> This is strange..
>> this code was introduced only since Pharo 1.2
>> and Squeak 4.2 images jut couple of months ago.
>> And of course, Pharo 1.1 images,  where you porting know nothing about
>> this method.
>>
>> You can patch Pharo 1.1. by putting
>> WeakArray>>isFinalizationSupported
>> ^ false
>> in this method.
>>
>> But i don't understand what you doing... how it could happen that
>> Sophie knows about (and using) this recently introduced code?
>>
>> Or perhaps you trying to port Collections-Weak? which i would not
>> recommend to do,
>> because it is a part of Kernel.
>
> You are mixing the methods. #isFinalizationSupported used to answer what
> it's name suggests: "does the VM support any form of finalization?". What
> you're thinking about is WeakFinalizationList class >> #hasNewFinalization
> (or so) which is unrelated. The method was removed during a "cleanup". And
> as you know, backwards compatibility is not a priority for Pharo.
>
>
Ah... phew.. sorry for confusion :)

> Levente
>
>>
>>
>>>
>>> Why was this method removed from Pharo?  I want to make sure I understand
>>> what I'm doing when I remove these calls.
>>>
>>> Thanks.
>>> Sean
>>> --
>>> View this message in context:
>>> http://forum.world.st/WeakArray-isFinalizationSupported-tp3168849p3168849.html
>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: WeakArray>>isFinalizationSupported

Schwab,Wilhelm K
In reply to this post by Levente Uzonyi-2
Hopefully that can eventually be said as "backward compatibility with good stuff is a priority for Pharo."   Moving targets are perhaps best left moving for now.



________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Levente Uzonyi [[hidden email]]
Sent: Thursday, December 30, 2010 6:13 PM
To: [hidden email]
Subject: Re: [Pharo-project] WeakArray>>isFinalizationSupported

(or so) which is unrelated. The method was removed during a "cleanup". And
as you know, backwards compatibility is not a priority for Pharo.


Levente


Reply | Threaded
Open this post in threaded view
|

Re: WeakArray>>isFinalizationSupported

johnmci
Well the question as pointed out was does this vm support weak object
finalization? and since all closure vm support finalization, then
asking the question was mute, so it was ditched. Sophie from the 2003
era had to ask.


On 12/30/10, Schwab,Wilhelm K <[hidden email]> wrote:

> Hopefully that can eventually be said as "backward compatibility with good
> stuff is a priority for Pharo."   Moving targets are perhaps best left
> moving for now.
>
>
>
> ________________________________________
> From: [hidden email]
> [[hidden email]] On Behalf Of Levente Uzonyi
> [[hidden email]]
> Sent: Thursday, December 30, 2010 6:13 PM
> To: [hidden email]
> Subject: Re: [Pharo-project] WeakArray>>isFinalizationSupported
>
> (or so) which is unrelated. The method was removed during a "cleanup". And
> as you know, backwards compatibility is not a priority for Pharo.
>
>
> Levente
>
>
>


--
===========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================

Reply | Threaded
Open this post in threaded view
|

Re: WeakArray>>isFinalizationSupported

Sean P. DeNigris
Administrator
John M McIntosh wrote
since all closure vm support finalization, then asking the question was mute
Okay, so I will remove these unnecessary checks.

Sean
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: WeakArray>>isFinalizationSupported

Stéphane Ducasse
In reply to this post by johnmci
Thanks john.
Some people think that we are just total idiot and reality is somehow different and fun to look at it.

Stef

On Dec 31, 2010, at 1:57 AM, John McIntosh wrote:

> Well the question as pointed out was does this vm support weak object
> finalization? and since all closure vm support finalization, then
> asking the question was mute, so it was ditched. Sophie from the 2003
> era had to ask.
>
>
> On 12/30/10, Schwab,Wilhelm K <[hidden email]> wrote:
>> Hopefully that can eventually be said as "backward compatibility with good
>> stuff is a priority for Pharo."   Moving targets are perhaps best left
>> moving for now.
>>
>>
>>
>> ________________________________________
>> From: [hidden email]
>> [[hidden email]] On Behalf Of Levente Uzonyi
>> [[hidden email]]
>> Sent: Thursday, December 30, 2010 6:13 PM
>> To: [hidden email]
>> Subject: Re: [Pharo-project] WeakArray>>isFinalizationSupported
>>
>> (or so) which is unrelated. The method was removed during a "cleanup". And
>> as you know, backwards compatibility is not a priority for Pharo.
>>
>>
>> Levente
>>
>>
>>
>
>
> --
> ===========================================================================
> John M. McIntosh <[hidden email]>
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
>


Reply | Threaded
Open this post in threaded view
|

Re: WeakArray>>isFinalizationSupported

Levente Uzonyi-2
In reply to this post by johnmci
On Thu, 30 Dec 2010, John McIntosh wrote:

> Well the question as pointed out was does this vm support weak object
> finalization? and since all closure vm support finalization, then
> asking the question was mute, so it was ditched. Sophie from the 2003
> era had to ask.

The need for the check it outdated, but the method is still sent by
external packages. With proper deprecation policy the method would be
still available. It would simply return true and raise a deprecation
warning.


Levente

>
>
> On 12/30/10, Schwab,Wilhelm K <[hidden email]> wrote:
>> Hopefully that can eventually be said as "backward compatibility with good
>> stuff is a priority for Pharo."   Moving targets are perhaps best left
>> moving for now.
>>
>>
>>
>> ________________________________________
>> From: [hidden email]
>> [[hidden email]] On Behalf Of Levente Uzonyi
>> [[hidden email]]
>> Sent: Thursday, December 30, 2010 6:13 PM
>> To: [hidden email]
>> Subject: Re: [Pharo-project] WeakArray>>isFinalizationSupported
>>
>> (or so) which is unrelated. The method was removed during a "cleanup". And
>> as you know, backwards compatibility is not a priority for Pharo.
>>
>>
>> Levente
>>
>>
>>
>
>
> --
> ===========================================================================
> John M. McIntosh <[hidden email]>
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
>
>

Reply | Threaded
Open this post in threaded view
|

Re: WeakArray>>isFinalizationSupported

Nicolas Cellier
On the other hand, if old packages are usefull, they should be
maintained and upgraded.

If Pharo wants to remove these deprecated methods, an alternative
policy is to move deprecated methods in a separate backward
compatibility package.

Nicolas

2010/12/31 Levente Uzonyi <[hidden email]>:

> On Thu, 30 Dec 2010, John McIntosh wrote:
>
>> Well the question as pointed out was does this vm support weak object
>> finalization? and since all closure vm support finalization, then
>> asking the question was mute, so it was ditched. Sophie from the 2003
>> era had to ask.
>
> The need for the check it outdated, but the method is still sent by external
> packages. With proper deprecation policy the method would be still
> available. It would simply return true and raise a deprecation warning.
>
>
> Levente
>
>>
>>
>> On 12/30/10, Schwab,Wilhelm K <[hidden email]> wrote:
>>>
>>> Hopefully that can eventually be said as "backward compatibility with
>>> good
>>> stuff is a priority for Pharo."   Moving targets are perhaps best left
>>> moving for now.
>>>
>>>
>>>
>>> ________________________________________
>>> From: [hidden email]
>>> [[hidden email]] On Behalf Of Levente Uzonyi
>>> [[hidden email]]
>>> Sent: Thursday, December 30, 2010 6:13 PM
>>> To: [hidden email]
>>> Subject: Re: [Pharo-project] WeakArray>>isFinalizationSupported
>>>
>>> (or so) which is unrelated. The method was removed during a "cleanup".
>>> And
>>> as you know, backwards compatibility is not a priority for Pharo.
>>>
>>>
>>> Levente
>>>
>>>
>>>
>>
>>
>> --
>>
>> ===========================================================================
>> John M. McIntosh <[hidden email]>
>> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
>>
>> ===========================================================================
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: WeakArray>>isFinalizationSupported

Igor Stasenko
On 31 December 2010 11:03, Nicolas Cellier
<[hidden email]> wrote:
> On the other hand, if old packages are usefull, they should be
> maintained and upgraded.
>
> If Pharo wants to remove these deprecated methods, an alternative
> policy is to move deprecated methods in a separate backward
> compatibility package.
>

+1
I would call it 'Pharo-Cruft'
:)

> Nicolas
>
> 2010/12/31 Levente Uzonyi <[hidden email]>:
>> On Thu, 30 Dec 2010, John McIntosh wrote:
>>
>>> Well the question as pointed out was does this vm support weak object
>>> finalization? and since all closure vm support finalization, then
>>> asking the question was mute, so it was ditched. Sophie from the 2003
>>> era had to ask.
>>
>> The need for the check it outdated, but the method is still sent by external
>> packages. With proper deprecation policy the method would be still
>> available. It would simply return true and raise a deprecation warning.
>>
>>
>> Levente
>>
>>>
>>>
>>> On 12/30/10, Schwab,Wilhelm K <[hidden email]> wrote:
>>>>
>>>> Hopefully that can eventually be said as "backward compatibility with
>>>> good
>>>> stuff is a priority for Pharo."   Moving targets are perhaps best left
>>>> moving for now.
>>>>
>>>>
>>>>
>>>> ________________________________________
>>>> From: [hidden email]
>>>> [[hidden email]] On Behalf Of Levente Uzonyi
>>>> [[hidden email]]
>>>> Sent: Thursday, December 30, 2010 6:13 PM
>>>> To: [hidden email]
>>>> Subject: Re: [Pharo-project] WeakArray>>isFinalizationSupported
>>>>
>>>> (or so) which is unrelated. The method was removed during a "cleanup".
>>>> And
>>>> as you know, backwards compatibility is not a priority for Pharo.
>>>>
>>>>
>>>> Levente
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> ===========================================================================
>>> John M. McIntosh <[hidden email]>
>>> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
>>>
>>> ===========================================================================
>>>
>>>
>>
>>
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: WeakArray>>isFinalizationSupported

Igor Stasenko
On 31 December 2010 12:45, Igor Stasenko <[hidden email]> wrote:

> On 31 December 2010 11:03, Nicolas Cellier
> <[hidden email]> wrote:
>> On the other hand, if old packages are usefull, they should be
>> maintained and upgraded.
>>
>> If Pharo wants to remove these deprecated methods, an alternative
>> policy is to move deprecated methods in a separate backward
>> compatibility package.
>>
>
> +1
> I would call it 'Pharo-Cruft'
> :)

Sorry for quick comment. I think this idea is userful to safely remove
anything from system and it can be even automated

Utilities moveDeprecatedToCruft
  "put all senders of #deprecated to '*Pharo-Cruft' category"
  ...

Because a package author who wants to upgrade his package can be
always sure that he can fix it,
because he can use Pharo-Cruft for checking what removed methods was doing,
and what is analogous functionality he can use in modern image (all
deprecated methods should contain a comment describing, why it was
removed and what should be used instead).

Just removing methods, as it shown by this topic
(isFinalizationSupported), could lead to unnecessary questions and
confusion.



>
>> Nicolas
--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: WeakArray>>isFinalizationSupported

Stéphane Ducasse
In reply to this post by Levente Uzonyi-2
Thanks for the usual rant. This is good to have you here because we could have forgotten.
Now of course we apply deprecation (we are probably the guy responsible to get the methods in Squeak long long time ago)
but there are moments when there is too much to deprecate or when people forget.
And forgetting is humane. Now if your company has lot of money, we can hire another engineer and work full speed
and apply even more software engineering practices.
Now it does not mean that we do not pay attention. We pay attention to people and to their product.
May be each community needs its pain in the ass after all it shows that we get cooler and cooler. But it would be nice
if you could give us a break.

Stef


On Dec 31, 2010, at 10:22 AM, Levente Uzonyi wrote:

> On Thu, 30 Dec 2010, John McIntosh wrote:
>
>> Well the question as pointed out was does this vm support weak object
>> finalization? and since all closure vm support finalization, then
>> asking the question was mute, so it was ditched. Sophie from the 2003
>> era had to ask.
>
> The need for the check it outdated, but the method is still sent by external packages. With proper deprecation policy the method would be still available. It would simply return true and raise a deprecation warning.
>
>
> Levente
>
>>
>>
>> On 12/30/10, Schwab,Wilhelm K <[hidden email]> wrote:
>>> Hopefully that can eventually be said as "backward compatibility with good
>>> stuff is a priority for Pharo."   Moving targets are perhaps best left
>>> moving for now.
>>>
>>>
>>>
>>> ________________________________________
>>> From: [hidden email]
>>> [[hidden email]] On Behalf Of Levente Uzonyi
>>> [[hidden email]]
>>> Sent: Thursday, December 30, 2010 6:13 PM
>>> To: [hidden email]
>>> Subject: Re: [Pharo-project] WeakArray>>isFinalizationSupported
>>>
>>> (or so) which is unrelated. The method was removed during a "cleanup". And
>>> as you know, backwards compatibility is not a priority for Pharo.
>>>
>>>
>>> Levente
>>>
>>>
>>>
>>
>>
>> --
>> ===========================================================================
>> John M. McIntosh <[hidden email]>
>> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
>> ===========================================================================
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: WeakArray>>isFinalizationSupported

Nicolas Cellier
Stephane,
You can't be serious: you learn something usefull from students acid
comments and nothing from the ones of Levente ?
Comm'on!
It's guaranteed that you'll get complaints. Only who doesn't do anything won't.
Forgetting is human, mistakes are, and unfortunately your are human too.
You must accept to fail, and you must accept some critics: it's up to
you to turn these in positive feedback.

cheers

Nicolas

2010/12/31 Stéphane Ducasse <[hidden email]>:

> Thanks for the usual rant. This is good to have you here because we could have forgotten.
> Now of course we apply deprecation (we are probably the guy responsible to get the methods in Squeak long long time ago)
> but there are moments when there is too much to deprecate or when people forget.
> And forgetting is humane. Now if your company has lot of money, we can hire another engineer and work full speed
> and apply even more software engineering practices.
> Now it does not mean that we do not pay attention. We pay attention to people and to their product.
> May be each community needs its pain in the ass after all it shows that we get cooler and cooler. But it would be nice
> if you could give us a break.
>
> Stef
>
>
> On Dec 31, 2010, at 10:22 AM, Levente Uzonyi wrote:
>
>> On Thu, 30 Dec 2010, John McIntosh wrote:
>>
>>> Well the question as pointed out was does this vm support weak object
>>> finalization? and since all closure vm support finalization, then
>>> asking the question was mute, so it was ditched. Sophie from the 2003
>>> era had to ask.
>>
>> The need for the check it outdated, but the method is still sent by external packages. With proper deprecation policy the method would be still available. It would simply return true and raise a deprecation warning.
>>
>>
>> Levente
>>
>>>
>>>
>>> On 12/30/10, Schwab,Wilhelm K <[hidden email]> wrote:
>>>> Hopefully that can eventually be said as "backward compatibility with good
>>>> stuff is a priority for Pharo."   Moving targets are perhaps best left
>>>> moving for now.
>>>>
>>>>
>>>>
>>>> ________________________________________
>>>> From: [hidden email]
>>>> [[hidden email]] On Behalf Of Levente Uzonyi
>>>> [[hidden email]]
>>>> Sent: Thursday, December 30, 2010 6:13 PM
>>>> To: [hidden email]
>>>> Subject: Re: [Pharo-project] WeakArray>>isFinalizationSupported
>>>>
>>>> (or so) which is unrelated. The method was removed during a "cleanup". And
>>>> as you know, backwards compatibility is not a priority for Pharo.
>>>>
>>>>
>>>> Levente
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> ===========================================================================
>>> John M. McIntosh <[hidden email]>
>>> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
>>> ===========================================================================
>>>
>>>
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: WeakArray>>isFinalizationSupported

Igor Stasenko
ahahaa.. you guys are killing me..
You are taking things too serious.
Yeah.. i would be gladly hear from Levente, what is 'the proper
deprecation policy'.
But since nobody described it, we are doomed to use one, invented before :)

Nothing is perfect, but its not the reason to fight.

On 31 December 2010 15:34, Nicolas Cellier
<[hidden email]> wrote:

> Stephane,
> You can't be serious: you learn something usefull from students acid
> comments and nothing from the ones of Levente ?
> Comm'on!
> It's guaranteed that you'll get complaints. Only who doesn't do anything won't.
> Forgetting is human, mistakes are, and unfortunately your are human too.
> You must accept to fail, and you must accept some critics: it's up to
> you to turn these in positive feedback.
>
> cheers
>
> Nicolas
>
> 2010/12/31 Stéphane Ducasse <[hidden email]>:
>> Thanks for the usual rant. This is good to have you here because we could have forgotten.
>> Now of course we apply deprecation (we are probably the guy responsible to get the methods in Squeak long long time ago)
>> but there are moments when there is too much to deprecate or when people forget.
>> And forgetting is humane. Now if your company has lot of money, we can hire another engineer and work full speed
>> and apply even more software engineering practices.
>> Now it does not mean that we do not pay attention. We pay attention to people and to their product.
>> May be each community needs its pain in the ass after all it shows that we get cooler and cooler. But it would be nice
>> if you could give us a break.
>>
>> Stef
>>
>>
>> On Dec 31, 2010, at 10:22 AM, Levente Uzonyi wrote:
>>
>>> On Thu, 30 Dec 2010, John McIntosh wrote:
>>>
>>>> Well the question as pointed out was does this vm support weak object
>>>> finalization? and since all closure vm support finalization, then
>>>> asking the question was mute, so it was ditched. Sophie from the 2003
>>>> era had to ask.
>>>
>>> The need for the check it outdated, but the method is still sent by external packages. With proper deprecation policy the method would be still available. It would simply return true and raise a deprecation warning.
>>>
>>>
>>> Levente
>>>
>>>>
>>>>
>>>> On 12/30/10, Schwab,Wilhelm K <[hidden email]> wrote:
>>>>> Hopefully that can eventually be said as "backward compatibility with good
>>>>> stuff is a priority for Pharo."   Moving targets are perhaps best left
>>>>> moving for now.
>>>>>
>>>>>
>>>>>
>>>>> ________________________________________
>>>>> From: [hidden email]
>>>>> [[hidden email]] On Behalf Of Levente Uzonyi
>>>>> [[hidden email]]
>>>>> Sent: Thursday, December 30, 2010 6:13 PM
>>>>> To: [hidden email]
>>>>> Subject: Re: [Pharo-project] WeakArray>>isFinalizationSupported
>>>>>
>>>>> (or so) which is unrelated. The method was removed during a "cleanup". And
>>>>> as you know, backwards compatibility is not a priority for Pharo.
>>>>>
>>>>>
>>>>> Levente
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> ===========================================================================
>>>> John M. McIntosh <[hidden email]>
>>>> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
>>>> ===========================================================================
>>>>
>>>>
>>>
>>
>>
>>
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: WeakArray>>isFinalizationSupported

Sean P. DeNigris
Administrator
In reply to this post by Nicolas Cellier
nicolas cellier-2 wrote
On the other hand, if old packages are usefull, they should be
maintained and upgraded.
This is a great ideal, but in reality there are a ton of useful, out-of-date packages out there.  Anything that helps restore them to usability for the community is a plus.  For example, some projects I use all the time in my personal image that I had to update for current Squeak and/or Pharo:
Applescript
CommandShell
ExternalWebBrowser
HTML (Validating Parser)
KeyBinder
Keymapping
MathMorphs
rST
SHWorkspace (World Menu Fix)
sqlite3
SSpec
SVI
Sophie MP3 playing
Sophie QuickTime video playing

Sean
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: WeakArray>>isFinalizationSupported

Sean P. DeNigris
Administrator
In reply to this post by Igor Stasenko
Igor Stasenko wrote
On 31 December 2010 12:45, Igor Stasenko <siguctua@gmail.com> wrote:
> On 31 December 2010 11:03, Nicolas Cellier
> <nicolas.cellier.aka.nice@gmail.com> wrote:
>> If Pharo wants to remove these deprecated methods, an alternative
>> policy is to move deprecated methods in a separate backward
>> compatibility package.

Utilities moveDeprecatedToCruft
  "put all senders of #deprecated to '*Pharo-Cruft' category"
  ...
Yes, awesome idea! This would be so helpful.  When rescuing an old package, one could load it into an image with Cruft installed, and...

Igor Stasenko wrote
(all deprecated methods should contain a comment describing, why it was
removed and what should be used instead).
This is the key!  It would be almost trivial to upgrade old packages if the debugger explained how the code should be changed!  There could even be a link to a relevant help topic, if one exists.

Sean
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: WeakArray>>isFinalizationSupported

Miguel Cobá
In reply to this post by Levente Uzonyi-2
El vie, 31-12-2010 a las 10:22 +0100, Levente Uzonyi escribió:

> On Thu, 30 Dec 2010, John McIntosh wrote:
>
> > Well the question as pointed out was does this vm support weak object
> > finalization? and since all closure vm support finalization, then
> > asking the question was mute, so it was ditched. Sophie from the 2003
> > era had to ask.
>
> The need for the check it outdated, but the method is still sent by
> external packages. With proper deprecation policy the method would be
> still available. It would simply return true and raise a deprecation
> warning.

But having a deprecated existing method also encourage to never update
the external packages, so old bits are floating around even if not
needed. Given the refactoring-mindset of the smalltalk community I'd say
that better to have tha package be broken so the next one that *really*
need that package update it as soon as discovered the flaw. That is a
little pain in the short term for the dude that suffered the blow up of
the package but overall good for the community once the package is
upgraded to the new times.

Cheers
--
Miguel Cobá
http://twitter.com/MiguelCobaMtz
http://miguel.leugim.com.mx




Reply | Threaded
Open this post in threaded view
|

Re: WeakArray>>isFinalizationSupported

Levente Uzonyi-2
In reply to this post by Igor Stasenko
On Fri, 31 Dec 2010, Igor Stasenko wrote:

> ahahaa.. you guys are killing me..
> You are taking things too serious.
> Yeah.. i would be gladly hear from Levente, what is 'the proper
> deprecation policy'.
> But since nobody described it, we are doomed to use one, invented before :)

I described my ideas here, so I won't repeat it. But I can tell you that
removing a method which wasn't deprecated at all is _not_ a proper
deprecation policy.

>
> Nothing is perfect, but its not the reason to fight.

There's no fight.


Levente

>
> On 31 December 2010 15:34, Nicolas Cellier
> <[hidden email]> wrote:
>> Stephane,
>> You can't be serious: you learn something usefull from students acid
>> comments and nothing from the ones of Levente ?
>> Comm'on!
>> It's guaranteed that you'll get complaints. Only who doesn't do anything won't.
>> Forgetting is human, mistakes are, and unfortunately your are human too.
>> You must accept to fail, and you must accept some critics: it's up to
>> you to turn these in positive feedback.
>>
>> cheers
>>
>> Nicolas
>>
>> 2010/12/31 Stéphane Ducasse <[hidden email]>:
>>> Thanks for the usual rant. This is good to have you here because we could have forgotten.
>>> Now of course we apply deprecation (we are probably the guy responsible to get the methods in Squeak long long time ago)
>>> but there are moments when there is too much to deprecate or when people forget.
>>> And forgetting is humane. Now if your company has lot of money, we can hire another engineer and work full speed
>>> and apply even more software engineering practices.
>>> Now it does not mean that we do not pay attention. We pay attention to people and to their product.
>>> May be each community needs its pain in the ass after all it shows that we get cooler and cooler. But it would be nice
>>> if you could give us a break.
>>>
>>> Stef
>>>
>>>
>>> On Dec 31, 2010, at 10:22 AM, Levente Uzonyi wrote:
>>>
>>>> On Thu, 30 Dec 2010, John McIntosh wrote:
>>>>
>>>>> Well the question as pointed out was does this vm support weak object
>>>>> finalization? and since all closure vm support finalization, then
>>>>> asking the question was mute, so it was ditched. Sophie from the 2003
>>>>> era had to ask.
>>>>
>>>> The need for the check it outdated, but the method is still sent by external packages. With proper deprecation policy the method would be still available. It would simply return true and raise a deprecation warning.
>>>>
>>>>
>>>> Levente
>>>>
>>>>>
>>>>>
>>>>> On 12/30/10, Schwab,Wilhelm K <[hidden email]> wrote:
>>>>>> Hopefully that can eventually be said as "backward compatibility with good
>>>>>> stuff is a priority for Pharo."   Moving targets are perhaps best left
>>>>>> moving for now.
>>>>>>
>>>>>>
>>>>>>
>>>>>> ________________________________________
>>>>>> From: [hidden email]
>>>>>> [[hidden email]] On Behalf Of Levente Uzonyi
>>>>>> [[hidden email]]
>>>>>> Sent: Thursday, December 30, 2010 6:13 PM
>>>>>> To: [hidden email]
>>>>>> Subject: Re: [Pharo-project] WeakArray>>isFinalizationSupported
>>>>>>
>>>>>> (or so) which is unrelated. The method was removed during a "cleanup". And
>>>>>> as you know, backwards compatibility is not a priority for Pharo.
>>>>>>
>>>>>>
>>>>>> Levente
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ===========================================================================
>>>>> John M. McIntosh <[hidden email]>
>>>>> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
>>>>> ===========================================================================
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>
Reply | Threaded
Open this post in threaded view
|

Re: WeakArray>>isFinalizationSupported

Levente Uzonyi-2
In reply to this post by Miguel Cobá
On Fri, 31 Dec 2010, Miguel Cobá wrote:

> El vie, 31-12-2010 a las 10:22 +0100, Levente Uzonyi escribió:
>> On Thu, 30 Dec 2010, John McIntosh wrote:
>>
>>> Well the question as pointed out was does this vm support weak object
>>> finalization? and since all closure vm support finalization, then
>>> asking the question was mute, so it was ditched. Sophie from the 2003
>>> era had to ask.
>>
>> The need for the check it outdated, but the method is still sent by
>> external packages. With proper deprecation policy the method would be
>> still available. It would simply return true and raise a deprecation
>> warning.
>
> But having a deprecated existing method also encourage to never update
> the external packages, so old bits are floating around even if not
> needed. Given the refactoring-mindset of the smalltalk community I'd say
You're right, those popups with the deprecation warnings are really
encouraging people to not update the code. And who would give a damn about
the deprecation message anyway? It's better to guess why things don't work
or ask someone else (list).


Levente

> that better to have tha package be broken so the next one that *really*
> need that package update it as soon as discovered the flaw. That is a
> little pain in the short term for the dude that suffered the blow up of
> the package but overall good for the community once the package is
> upgraded to the new times.
>
> Cheers
> --
> Miguel Cobá
> http://twitter.com/MiguelCobaMtz
> http://miguel.leugim.com.mx
>
>
>
>
>
12