WeakArray>>isFinalizationSupported

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.

On Fri, 31 Dec 2010, Miguel Cobá wrote:

El vie, 31-12-2010 a las 20:05 +0100, Levente Uzonyi escribió:

What you describe here is simply bad practice. One should run the tests
before deploying code (besides testing the complete system thoroughly).
If you use RFB, you can access the GUI in headless mode. Also when a
debugger opens with a deprecation warning, the stack trace is written to
the log file, so you will be notified about the problem even when you
don't have access to the GUI.

Yeah, sure. But if it a second level dependency (a package I use that
uses a package that contains popups deprecation warnings) I have big
chances of being bite by this problem. I concede, this could be avoided
by test-running every and whatnot package in the image but for a system
that updates automatically this will bite.

So you're saying that it's better to get a DNU instead of a deprecation warning with proper description about what and how to update/change?


Levente

Also, even if I can use RFB or read the image logs, I most likely will
monitor the application logs and will pass a time without me knowing
that some part of the application is waiting some user input.
At the end I expect that the maintainer of the package is the
*responsible* of test the application for the image I use, and not the
user of the package. That is what I do with magma on Pharo. I test and
fix the issues generated by the evolution of Pharo and then I release a
new ConfigurationOfMagma that the user can use without knowing that n
deprecations were involved in the upgrade of the package.

Anyway, there's no reason to remove a method (especially an API method)
without deprecating and keeping it around for a few releases.

I agree that is better to not forget to mark some method as deprecated
but, again, I think that this promote the external packages not being
updated to the current pharo image.

Cheers

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

Oh, come on...

Levente, we all agree with you.  Pharo is trying to use that deprecation policy since some months ago...  Sometimes people make mistakes (me included) and don't do it, but we agreed that we have to deprecate and remove after two versions of being deprecated.

I'm tired of this stupid arguments.

I expect the new year will bring us more doing and less discussing :).

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

On Fri, 31 Dec 2010, Miguel Cobá wrote:

El vie, 31-12-2010 a las 20:05 +0100, Levente Uzonyi escribió:

What you describe here is simply bad practice. One should run the tests
before deploying code (besides testing the complete system thoroughly).
If you use RFB, you can access the GUI in headless mode. Also when a
debugger opens with a deprecation warning, the stack trace is written to
the log file, so you will be notified about the problem even when you
don't have access to the GUI.

Yeah, sure. But if it a second level dependency (a package I use that
uses a package that contains popups deprecation warnings) I have big
chances of being bite by this problem. I concede, this could be avoided
by test-running every and whatnot package in the image but for a system
that updates automatically this will bite.

So you're saying that it's better to get a DNU instead of a deprecation warning with proper description about what and how to update/change?


Levente

Also, even if I can use RFB or read the image logs, I most likely will
monitor the application logs and will pass a time without me knowing
that some part of the application is waiting some user input.
At the end I expect that the maintainer of the package is the
*responsible* of test the application for the image I use, and not the
user of the package. That is what I do with magma on Pharo. I test and
fix the issues generated by the evolution of Pharo and then I release a
new ConfigurationOfMagma that the user can use without knowing that n
deprecations were involved in the upgrade of the package.

Anyway, there's no reason to remove a method (especially an API method)
without deprecating and keeping it around for a few releases.

I agree that is better to not forget to mark some method as deprecated
but, again, I think that this promote the external packages not being
updated to the current pharo image.

Cheers

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