Skip Menu |
 

This queue is for tickets about the POE CPAN distribution.

Report information
The Basics
Id: 28891
Status: rejected
Priority: 0/
Queue: POE

People
Owner: Nobody in particular
Requestors: nicholasrperez [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: [PATCH] Add (expose really) alias_remove_all() method for POE::Kernel
Date: Fri, 17 Aug 2007 00:02:45 -0500
To: "POE Mailing List" <poe [...] perl.org>
From: "Nicholas Perez" <nicholasrperez [...] gmail.com>
Download (untitled) / with headers
text/plain 715b
Hola, Here is a patch that implements alias_remove_all(). The reason I did this was because I got a bug report in one of my modules that was leaking due to the way I had interpreted the documentation to alias_remove() with no arguments (ie. I'd read it wrong for years). I'm not the only author that has done this. It isn't initially obvious how to remove all aliases other than iterating through them via: $kernel->alias_remove( $_ ) for $kernel->alias_list( $session ); This patch exposes the internal _data_alias_clear_session and does some light checking on the public api. Tests are updated, as are docs for POE::Kernel. Let me know if I screwed up the white space/style/whatever and I'll fix it. Nick

Message body is not shown because sender requested not to inline it.

Download (untitled) / with headers
text/plain 109b
I do believe this failed to make it into the 1.0. Just a reminder that this should be committed at some point
Download (untitled) / with headers
text/plain 334b
This feature is syntactic sugar for a one-line statement. It doesn't enable users to do anything new, so it doesn't belong in POE::Kernel's core feature set. The POE::API namespace exists so that people may extend POE::Kernel without patching the core. Please see POE::API::Peek for precedent on publishing mix-in POE::Kernel APIs.
Subject: Re: [rt.cpan.org #28891] [PATCH] Add (expose really) alias_remove_all() method for POE::Kernel
Date: Sat, 19 Apr 2008 15:37:17 -0500
To: bug-POE [...] rt.cpan.org
From: "Nicholas Perez" <nicholasrperez [...] gmail.com>
I need to disagree with you regarding syntactic sugar. That one liner statement invokes all of the lookup and assertion checking for each and every known alias returned in alias_list. That can be computationally significant when compared to the looping that happens internally within POE::Resource::Aliases::_data_alias_clear_session. Bringing that functionality forward is a positive enhancement, not just syntactic sugar. Why else have other *_remove_all methods on POE::Kernel if you can simply accomplish the same thing with a one liner? On Sat, Apr 19, 2008 at 2:44 PM, RCAPUTO via RT <bug-POE@rt.cpan.org> wrote: Show quoted text
> > <URL: http://rt.cpan.org/Ticket/Display.html?id=28891 > > > This feature is syntactic sugar for a one-line statement. It doesn't > enable users to do anything new, so it doesn't belong in POE::Kernel's > core feature set. > > The POE::API namespace exists so that people may extend POE::Kernel > without patching the core. Please see POE::API::Peek for precedent on > publishing mix-in POE::Kernel APIs. >
-- Nicholas R. Perez
Download (untitled) / with headers
text/plain 1.9k
The only other method of this type is alarm_remove_all(). There is no public method to list alarms, so it's not possible to remove all alarms in a one-liner. In other words, alarm_remove_all() extends the public API to support something that users could not already do. Otherwise I would either have rejected it or now be considering whether to deprecate it. Technically, people could track their alarms with a hash and alarm_set(). This is significantly more work than a one-liner, but I could use it to justify deprecating alarm_remove_all(). Unfortunately it's a lot harder to deprecate a feature than it is to reject one. In the end, alarm_remove_all() may remain in POE::Kernel because it's the path of least resistance. You're still welcome to implement a POE::API module for alias_remove_all(). I'd be interested to see the comparative benchmarks for practical use cases. On Sat Apr 19 16:39:49 2008, nicholasrperez@gmail.com wrote: Show quoted text
> I need to disagree with you regarding syntactic sugar. That one liner > statement invokes all of the lookup and assertion checking for each > and every known alias returned in alias_list. That can be > computationally significant when compared to the looping that happens > internally within POE::Resource::Aliases::_data_alias_clear_session. > Bringing that functionality forward is a positive enhancement, not > just syntactic sugar. Why else have other *_remove_all methods on > POE::Kernel if you can simply accomplish the same thing with a one > liner? > > On Sat, Apr 19, 2008 at 2:44 PM, RCAPUTO via RT <bug-POE@rt.cpan.org>
wrote: Show quoted text
> > > > <URL: http://rt.cpan.org/Ticket/Display.html?id=28891 > > > > > This feature is syntactic sugar for a one-line statement. It doesn't > > enable users to do anything new, so it doesn't belong in POE::Kernel's > > core feature set. > > > > The POE::API namespace exists so that people may extend POE::Kernel > > without patching the core. Please see POE::API::Peek for precedent on > > publishing mix-in POE::Kernel APIs. > >
> > >


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.