01-06-01 14.57, skrev Rocco Caputo på [EMAIL PROTECTED] följande: >> Message-Id: <[EMAIL PROTECTED]> >> From: "Rocco Caputo" <[EMAIL PROTECTED]> >> To: "The POE Mailing List" <[EMAIL PROTECTED]> >> Date: Thu, 18 Mar 99 09:17:02 -0500 >> Subject: TODO: fix alarms >> >> [...] If there are no objections, this will go into 0.07_01 or so, >> depending on my schedule. [...] >> >> | ***fix alarm semantics (in a way that does not break things) >> | >> | That's easy to say, anyway. How about depreciating &Kernel::alarm >> | and &Kernel::delay, and adding these functions? Why deprecate a working and nice interface? I have tons of code that works well and uses this. I also don't seen any problem with keeping it. > $alarm_id = $kernel->alarm_set($event, $time, @etc); > $status = $kernel->alarm_adjust($alarm_id, $seconds_to_adjust); Can this be optimized or is this just a shortcut for alarm_remove/alarm_set > $status = $kernel->alarm_remove($alarm_id); > >> | Also the delay shortcut, which would return an ID usable by >> | &Kernel::alarm_adjust and &Kernel::alarm_remove: >> | >> | $alarm_id = $kernel->delay_set($event, $seconds, @etc); > > To remove all alarms for a given event or time. I'm not sure how > useful these are yet. > > $status = $kernel->alarm_remove_by_event($event); alarm($event); does it and is very usefull, by all means make alarm_remove_by_event($event) an alias to alarm($event) > $status = $kernel->alarm_remove_by_time($time); This will either cost plenty of memory or cost a lot. Why put the cost of memory on us who won't use it (I don't see a use for it, but hey). It can easily be implmented in userspace where the user can optimize for speed or for memory. > To remove all alarms for the current session: > > $status = $kernel->alarm_remove_all(); > > Should alarm_remove() be alarm_remove_by_id() ? no, keep method names as short as possible artur
