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 |
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. |
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. 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. > > |
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. > > > 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. |
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 |
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 =========================================================================== |
Administrator
|
Okay, so I will remove these unnecessary checks. Sean
Cheers,
Sean |
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 > =========================================================================== > |
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 > =========================================================================== > > |
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 >> >> =========================================================================== >> >> > > |
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. |
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. |
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 >> =========================================================================== >> >> > |
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 >>> =========================================================================== >>> >>> >> > > > |
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. |
Administrator
|
In reply to this post by Nicolas Cellier
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 |
Administrator
|
In reply to this post by Igor Stasenko
Yes, awesome idea! This would be so helpful. When rescuing an old package, one could load it into an image with Cruft installed, and... 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 |
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 |
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. > > |
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 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 > > > > > |
Free forum by Nabble | Edit this page |