Re: AttributeHelpers in core (take 2)
On Tue, Jul 07, 2009 at 01:51:16PM -0400, Hans Dieter Pearcey wrote: > I'm going to rename everything to live under > Moose::Meta::Attribute::Trait::Native (yes, I've come around). Short names > will stay the same. > > I'm going to remove Collection:: from the trait names; I think it's > unnecessary, especially since Trait::Collection is empty. I meant: I will remove Collection from the short names, too. I don't think 'Collection::Array' is useful. hdp.
Re: AttributeHelpers in core (take 2)
FWIW Set::Bag exists on the CPAN and provides much more functionality with a cleaner API.
Re: AttributeHelpers in core (take 2)
On Jul 7, 2009, at 2:54 PM, Yuval Kogman wrote: 2009/7/7 Hans Dieter Pearcey : Bag is going to be renamed to Hash::Counter, probably. Counter is secretly Num::Counter, or something, though not really since Num doesn't exist (yet). Do we really need to keep Bag? I don't think it has many practical applications. The API is intended to implement an actual bag (that is, a member can appear multiple times), but is obviously flawed: 1. it exposes implementation details if the hash is readable 2. it doesn't support arbitrary data, it stringifies So I think it's best if we keep it in MX::AttributeHelpers for compatibility, but simply drop it from core. I second this. Bag was really written as an example of how you could use MX::AH with any data structures, not just the perl built-ins. And I whole heartedly agree, the implementation is shit.
Re: AttributeHelpers in core (take 2)
2009/7/7 Hans Dieter Pearcey : > Bag is going to be renamed to Hash::Counter, probably. Counter is secretly > Num::Counter, or something, though not really since Num doesn't exist (yet). Do we really need to keep Bag? I don't think it has many practical applications. The API is intended to implement an actual bag (that is, a member can appear multiple times), but is obviously flawed: 1. it exposes implementation details if the hash is readable 2. it doesn't support arbitrary data, it stringifies So I think it's best if we keep it in MX::AttributeHelpers for compatibility, but simply drop it from core.
Re: AttributeHelpers in core (take 2)
On Jul 7, 2009, at 1:51 PM, Hans Dieter Pearcey wrote: On Fri, Jun 26, 2009 at 04:06:28PM -0500, Dave Rolsky wrote: Here's some initial TODOs: * POD docs for every method provided. Some providers have docs, some don't. I'm going to move all POD into the Trait classes. I'm leaning towards thinking that the MethodProviders are an implementation detail that should be hidden. Yes agreed, the only reason that it was that way originally was because of pod-coverage.t * I just took a look at Bag for the first time, and it's not a bag, it's a CountingHash (CounterHash, HashCounter?). A bag is a multi-set (like a set, but allows dupes). Now is a good time to rename it. I'm going to rename everything to live under Moose::Meta::Attribute::Trait::Native (yes, I've come around). Short names will stay the same. :) I'm going to remove Collection:: from the trait names; I think it's unnecessary, especially since Trait::Collection is empty. Works for me. Bag is going to be renamed to Hash::Counter, probably. Counter is secretly Num::Counter, or something, though not really since Num doesn't exist (yet). Sounds good. Things we want to do in the future that do not block coring: * inlining * real delegation, somehow, instead of faked-up delegation (this requires some kind of real boxing, either redone or through making sure that Moose::Autobox agrees on method names with AH) Things that this isn't: * boxing * a standard set of interfaces for common types/data structures All sounds sane to me.
