Re: Module submission Return::Value
Well, this one isn't actually something that changes control flow. It's more of an object with rich behaviour that a method can hand back to its caller, who can work with it in more ways than your usual return value. It is, like most things these days, intended to be a base class that an author can subclass to get specialized extra behaviour for an application-specific return value object. Would Class::ReturnValue make sense? -j On Wed, Jan 30, 2002 at 11:12:01AM +, Tim Bunce wrote: > On Tue, Jan 29, 2002 at 09:09:11PM -0800, William R Ward wrote: > > [EMAIL PROTECTED] (Perl Authors Upload Server) writes: > > > modid: Return::Value > > > Return::Value is an object which encapsulates most of the standard > > > behaviors for function/method return values. It allows a function to > > > return an object that is treated as a boolean in boolean context, as > > > an array in array context and as a rich object if the caller wants > > > to use advanced features such as stack traces or lists of warnings > > > or complex return datatypes. > > > > I don't think that a "Return" top-level namespace is a very good > > choice for this.. How about (something)::ReturnValue, for some > > reasonable value of (something)? > > Umm, in the 'control flow' section of the module list we currently have > > * AtExit - atexit() function to register exit-callbacks > * Callback - Define easy to use function callback objects > * Hook::PrePostCall - Add actions before and after a routine > * Memoize - Cache results of individual function calls > * Religion - Control where you go when you die()/warn() > > It's kind'a tempting to propose a ControlFlow:: category. > Most/all of the above would have fitted in there nicely > (usually a sign of a good name). > > So how about ControlFlow::ReturnValue ? > > Tim. > -- jesse reed vincent -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] 70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90 I'm reasonably sure that at least two of the electric blue kangeroos I saw were real.
Re: Module submission Return::Value
What do I actually need to do to get Class::ReturnValue into the modules list at this point, then? Thanks, Jesse On Wed, Jan 30, 2002 at 09:28:03PM +, Tim Bunce wrote: > On Wed, Jan 30, 2002 at 10:36:18AM -0500, Jesse wrote: > > Well, this one isn't actually something that changes control flow. It's > > more of an object with rich behaviour that a method can hand back to its > > caller, who can work with it in more ways than your usual return value. > > Sure, but it's role is to carry a value (and baggage) across a > particular kind of flow crontrol. > > (Okay, it's a stretch, but only a small one :) > > > It is, like most things these days, intended to be a base class that an > > author can subclass to get specialized extra behaviour for an > > application-specific return value object. Would Class::ReturnValue > > make sense? > > Yeap. That's fine by me. Thanks. > > Tim. > > > -j > > > > > > > > On Wed, Jan 30, 2002 at 11:12:01AM +, Tim Bunce wrote: > > > On Tue, Jan 29, 2002 at 09:09:11PM -0800, William R Ward wrote: > > > > [EMAIL PROTECTED] (Perl Authors Upload Server) writes: > > > > > modid: Return::Value > > > > > Return::Value is an object which encapsulates most of the standard > > > > > behaviors for function/method return values. It allows a function to > > > > > return an object that is treated as a boolean in boolean context, as > > > > > an array in array context and as a rich object if the caller wants > > > > > to use advanced features such as stack traces or lists of warnings > > > > > or complex return datatypes. > > > > > > > > I don't think that a "Return" top-level namespace is a very good > > > > choice for this.. How about (something)::ReturnValue, for some > > > > reasonable value of (something)? > > > > > > Umm, in the 'control flow' section of the module list we currently have > > > > > > * AtExit - atexit() function to register exit-callbacks > > > * Callback - Define easy to use function callback objects > > > * Hook::PrePostCall - Add actions before and after a routine > > > * Memoize - Cache results of individual function calls > > > * Religion - Control where you go when you die()/warn() > > > > > > It's kind'a tempting to propose a ControlFlow:: category. > > > Most/all of the above would have fitted in there nicely > > > (usually a sign of a good name). > > > > > > So how about ControlFlow::ReturnValue ? > > > > > > Tim. > > > > > > > -- > > jesse reed vincent -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] > > 70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90 > > > > I'm reasonably sure that at least two of the electric blue kangeroos > > I saw were real. > -- jesse reed vincent -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] 70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90 Fame doesn't pay the bills, but infamy gets you laid. --monty
New author and module (DBIx::SearchBuilder)
Well, the new author is me, Jesse Vincent. The module is SearchBuilder.
I've been hacking on a DBIx:: module as part of a trouble ticketing
system called RT that I'm the primary author of. A number of folks have told me
that it would make a good CPAN contribution, so here I am. SearchBuilder
has been discussed in its former life as DBIx::EasySearch on [EMAIL PROTECTED]
Description:
SearchBuilder is a pure-perl abstarction layer on top of DBI which allows
programers to build complex select statements with multiple calls to
a couple fairly simple primitives. This ends up being particularly useful
for "refining" existing searches. It also comes with a class called
DBIx::SearchBuilder::Row which allows simple OO access to the data from
a single database row. SearchBuilder returns its results as a set of
DBIx::SearchBuilder::Rows
Name: Jesse Vincent
Email: [EMAIL PROTECTED]
Preferred CPAN Id: JESSE
Homepage: http://www.fsck.com/
SearchBuilder bdpO OO abstraction for compound searches JESSE
Thanks!
Jesse Vincent
--
jesse reed vincent --- [EMAIL PROTECTED] --- [EMAIL PROTECTED]
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
-
Pelcgb-serrqbz abj!
Re: CPAN - tidying up ownership and indexed releases of Jifty distribution
Hi Neil, Thanks so much for working to clean this stuff up. Everything should move to BPS. I believe we're in a similar situation with GnuPg-Interface, which should, ideally, also all be indexed under BPS. I'm ok with old releases going away, but have always appreciated having the history around. PAUSE really can't cope with having the historical uploads around? On Sun, Aug 23, 2020, at 9:18 AM, Neil Bowers wrote: > Hi Alex, Shawn, Thomas, and Jesse, > > I’m one of the PAUSE admins. I’m tidying up distributions that have shared > first-come ownership, since PAUSE tries now to not let this happen — it > maintains the permissions profile on the lead module, regardless of who > releases (in the past the releaser would get first-come on newly added > modules). Jifty is one of these distributions, caused by multiple people > doing releases over the years, and adding / dropping packages. > > You’ve all done releases of Jifty, you have indexing permissions, and all of > you have old releases in your PAUSE author directory. > > The user BPS has the first-come indexing permission on all packages apart > from Jifty itself, which JESSE has. There’s a mixture of different people > with co-maint. > > In addition to the latest release (from ALEXMV) there are three old releases > of Jifty in the CPAN Index, because package names were dropped / renamed. > > To resolve this: > 1. Should JESSE’s first-come on Jifty be transferred to BPS, or should all > of BPS’s first-comes be transferred to JESSE? > 2. To resolve the old releases appearing in the index, TSIBLEY and SARTAK > could delete all releases in their PAUSE author directory, and ALEXMV could > delete all old releases. I can schedule these deletions on your behalf, if > you’d like? You would get a confirmation email from PAUSE. > Are you happy to delete all old releases, and to let me know how to resolve > the first-come permissions please? > > Cheers, > Neil
Reserving namespace for RT (Request Tracker)
Heya modules folks, RT is a trouble ticketing system in use at several thousand sites around the world. most of RT is perl modules in the RT:: namespace. Might I be able to reserve the RT:: namespace for RT and related modules? Thanks, Jesse -- http://www.bestpractical.com/products/rt -- Trouble Ticketing. Free.
Author Registration Request
Name: Jesse Erlbaum Email Addr: [EMAIL PROTECTED] Homepage: http://www.vm.com/ Preferred user-ID: JERLBAUM Module list description - CGI::Application bmpO Framework for building reusable web-apps Description of Contribution - CGI::Application is intended to make it easier to create sophisticated, reusable web-based applications. This module implements a methodology which, if followed, will make your web software easier to design, easier to document, easier to write, and easier to evolve. The guiding philosophy behind CGI::Application is that a web-based application can be organized into a specific set of "Run-Modes." Each Run-Mode is roughly analogous to a single screen (a form, some output, etc). All the Run-Modes are managed by a single "Application Module" which is a Perl module. In your web server's document space there is an "Instance Script" which is called by the web server as a CGI (or an Apache::Registry script if you're using Apache + mod_perl). CGI::Application is an Object-Oriented Perl module which implements an Abstract Class. It is not intended that this package be instantiated directly. Instead, it is intended that your Application Module will be implemented as a Sub-Class of CGI::Application. This module has been in use for two years at my company. All the programmers (staff and contract) who have worked with us for the past two years have been using this system, and have expressed a strong appreciating of it. They have found it to be simple to use and of very high utility. The techniques enabled by this module have been discussed in public technical groups, where they have been greeted with enthusiasm. It is the strongly voiced opinions of the numerous programmers who are familiar with this system which have inspired me to release this module to CPAN. After being a user of CPAN for many years, I am quite excited to finally have an opportunity to contribute something back! Full Perl docs are available if you wish a closer look at the module. Thanks! -Jesse- -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Jesse Erlbaum ... CTO [EMAIL PROTECTED] . Vanguard Media v: 212.242.5317 x115 .. New York City +-+-+-+-+-+- http://www.vm.com/ +-+-+-+-+-+-+
P5P-owned CPAN modules
Hi folks, Could you please grant RAFL comaint permissions on all modules owned by P5P through whatever mechanism makes most sense on the PAUSE side? In my ideal world, this would be an "add him to the list" mechanism, so that it applies for new modules owned by P5P, but I'm not too picky. Alternatively, could you give me permissions to grant these permissions myself? Thanks! Jesse signature.asc Description: Digital signature
Re: P5P-owned CPAN modules
On Thu, Dec 09, 2010 at 08:19:15AM +0100, Andreas J. Koenig wrote: > Sorry, I have missed what the original question was. Was it RAFL wants > permissions to maintain ExtUtils::Command? RAFL is working to dual life / update the cpan versions of numerous core modules, a few at a time. I'd rather make this easier, rather than harder for him ;)
Re: Data::Alias takeover request
Just for a bit of closure, it appears that xmath has actually blessed the takeover: (#p5p, US/Eastern) 22:00 <@xmath> Zefram: there ya go. I wish you and D::A a merry journey together ;)
