Hi
My (not strongly held) opinion is that Philippe is on to something.
Most of the time my applications don't have any shutdown logic. So the
shutdown() method is already a corner case.
My design choice would be to create 2 new listener API's:
interface IShutdownVetoListener {
boolean canShutdown();
}
interface IShutdownListener() {
onShutdown();
}
Because there are going to be times when the program does not have a
choice about shutting down (e.g. System Update forced a reboot).
Thus we need to separate the "can shutdown" flag from the "shutting down
now" action.
Regards, Noel.
Philippe Lhoste wrote:
> On 23/06/2009 15:10, Greg Brown wrote:
>> It might be clearer for shutdown()'s return value to mean "yes,
>> cancel shutdown" (true) or "no, do not cancel shutdown" (false).
>> Also, by default, Eclipse provides a stub method that returns false.
>> An unsuspecting developer could easily be tripped up by this and
>> create an application that will never shut down.
>
> Personal taste: I find the name confusing already, seeing it without
> context would make me think the method does the shutdown.
>
> Since it it a callback function (presumably to clean up resources or
> to defer closing if doing a lengthly operation), I would prefer to see
> it named onShutdown() or something similar.
> Of course, then, you would have to name the other functions onStartup,
> onSuspend, onResume.
> These names break my personal policy of starting function names by a
> verb, but somehow it shows their status of callback. Not sure if there
> is a better convention. allowShutdown() is a bit restrictive, and
> opposed to your proposal. shouldCancelShutdown() is a bit verbose.
> Both seems to restrict to pure yes/not without the clean-up
> implication. And doesn't fit with the other methods.
>
> Just my opinion, you might be vehemently opposed to such
> conventions... :-)
>
