Orphaned autoboxed methods
Bruno Vecchi
currently implements itself.
Originally, Scott talked about pulling some of them to autobox::Core.
After the etherpad session, in which a new bunch of methods were
suggested, he decided against the idea of bloating ::Core, and that an
accessory module would be a better fit for the new methods. I
volunteered, and have a sketch of autobox::Utils up on github:
www.github.com/brunov/autobox-Utils/
Now all of this happened after Scott had released autobox::Core 0.7,
which includes the following new methods from perl5i:
* SCALAR:
* center
* wrap
* title_case
* trim, rtrim, ltrim
* ceil
* floor,
* round_up,
* round_down,
* round
* is_positive
* is_negative
* is_integer
* is_decimal
* HASH
* flip
* merge
I didn't know this until after I finished my first attempt at
autobox::Utils and, besides those methods that were agreed upon on the
etherpad session, I also took almost all of the methos listed above.
In order not to have name clashes or redundant methods, I think we
should agree on the concerns of:
* autobox::Core
* autobox::List::Util
* autobox::Util
* perl5i
So basically I'd like us to agree on what methods go where so that we
don't step into each others' toes.
My preference would be to keep autobox::Core as much ::Core as possible;
keep autobox::List::Util just as it is, and put the rest of the in-house
methods in autobox::Util so that perl5i just acts as a thin wrapper
around this modules.
Thoughts?
Michael G Schwern
This list is getting away from "core" but they're arguable what the core
should do. Also, they're simple and have no non-core deps.
> * HASH
>
> * flip
> * merge
HASH->flip is handy, so is merge, but merge does require a non-core module.
> In order not to have name clashes or redundant methods, I think we
> should agree on the concerns of:
>
> * autobox::Core
> * autobox::List::Util
> * autobox::Util
> * perl5i
>
> So basically I'd like us to agree on what methods go where so that we
> don't step into each others' toes.
>
> My preference would be to keep autobox::Core as much ::Core as possible;
> keep autobox::List::Util just as it is, and put the rest of the in-house
> methods in autobox::Util so that perl5i just acts as a thin wrapper
> around this modules.
As long there's a grand poomba autobox module that pulls it all together.
From a user utility standpoint for autobox::Core, you don't really want to
draw the line at core functions. Perhaps "core functionality" would be
better. Core functions and modules which ship with the core. So roll in
List::Util and Scalar::Util and Hash::Util. Roll in trim and center and
things which are simple perlfaqs, don't require a lot of code and are easy
interfaces.
The flip side is maintainability. Things like diff() and is_equal() would be
out because they're complicated. %hash->merge() requires a non-core module,
so that's questionable. The List::MoreUtils is non-core and the set of
methods to take in is in question.
I'd say think of it like autobox::Core is the safe and straightforward stuff
and then autobox::Util (not very descriptive) is the more controversial or
harder to maintain stuff. And some things can be left for perl5i if
necessary, like is_equal().
autobox::Util... doesn't say much what it does. Is this going to be the grand
"let's do all the things you wish you could to with Perl data structures" module?
--
52. Not allowed to yell "Take that Cobra" at the rifle range.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
Bruno Vecchi
> the line at core functions. Perhaps "core functionality" would be better.
> Core functions and modules which ship with the core. So roll in List::Util and
> Scalar::Util and Hash::Util. Roll in trim and center and things which are
> simple perlfaqs, don't require a lot of code and are easy interfaces.
>
> The flip side is maintainability. Things like diff() and is_equal() would be
> out because they're complicated. %hash->merge() requires a non-core module, so
> that's questionable. The List::MoreUtils is non-core and the set of methods to
> take in is in question.
>
> I'd say think of it like autobox::Core is the safe and straightforward stuff
> and then autobox::Util (not very descriptive) is the more controversial or
> harder to maintain stuff. And some things can be left for perl5i if necessary,
> like is_equal().
That makes sense. It diverts a little with scrottie's desire not to go crazy
with adding stuff, but I think he'll be ok with it now that more people have
commit bits and can help him tame the module.
So assuming that's settled, there's little room for autobox::Util now, so maybe
it'd be just fine to have the remaining methods (List::MoreUtils stuff and the
diffs, intersects and is_equal) in perl5i.
I set up a free-to-edit spreadsheet with a list of all the autoboxed methods
that we are shuffling and their proposed destinations:
http://tinyurl.com/ybq76lr
Most of the stuff is where it should be; we just need to port most of the
tests and docs to autobox::Core, remove them from perl5i, and move the
remaining methods that are currently only in the short-lived autobox::Util
(tail, head, first_index, last_index, range and slice) to perl5i.
Sounds ok?
> autobox::Util... doesn't say much what it does. Is this going to be the grand
> "let's do all the things you wish you could to with Perl data structures"
> module?
Well, originally I thought that it would aggregate List::MoreUtils,
Scalar::Utils, Hash::Utils and the rest of the simple methods that are now in
perl5i. But if we can let ::Core absorb most of that, I don't see much of a
case for ::Utils anymore.
Bruno.
2010/3/8 Michael G Schwern <sch...@pobox.com>: