I think we have 3 categories of things, at least in my mind ...
1) Low-level immutable data structures:
ImmutableHash
List
These have no mutation operations available and are building blocks
for the other mutable versions (see below). I doubt people actually
use these ones directly (at least not often).
2) Basic data-structures and values:
Array
Hash
Bool
String
Number
Bag
Array is an "extension" of List and Hash is an "extension" of
ImmutableHash, both providing additional mutation operations. Bool,
String and Number are just your basic values. Bag is just a poorly
named and badly implemented data structure. Now, these do not really
map to the Perl Scalar, Array, Hash types. However some of them do map
to some of the basic Moose types (Bag being the exception).
3) Code Patterns
Counter
We only have one of these, but I can see other patterns like some kind
of StringBuffer maybe (sure you could do that with String, but this
would provide sensible defaults). The key thing about these is that
they provide sensible types, default values and a subset of
operations. They have a clarity of purpose which makes them more self
documenting and therefor very useful.
---
So, not sure this really helps. I wouldn't mind splitting these things
into 3 different categories or something. I mean, we are breaking back
compat with MX::AH so we are free to rethink this if we want.
- Stevan
On Jul 2, 2009, at 2:38 PM, Hans Dieter Pearcey wrote:
I hate to keep coming back to this, but I'm unsettled and
unemployed, so I
might as well keep at it until I feel like I've got it right.
We've been talking about the roles that AH provides as being "Perl5"
or
"Native", but they're really not -- some of them are (Str) but some
of them
aren't (Counter, Bool, ImmutableHash, etc.). It doesn't even match
up exactly
with Moose's builtin types, so "Moose" isn't a good name either.
It's a collection of common, simple data types. I can't think of a
good name
for this. (And it's not even correct -- Counter is very useful, but
isn't
really a "data structure" so much as it is a common code pattern.)
The fact that the underlying data structures are normal Perl hashes,
arrays,
scalars, etc. is also not something we really want to draw attention
to; after
all, the whole point is that you use $self->push_things instead of
push
@{$self->things}, so that consumers of your API don't hardcode that
sort of
thing.
In the end of I'm not saying much different than I have before: what
is the
most precise way to distinguish these particular attribute traits
from other
traits?
I also keep coming back to something Dave said, along the lines of
"well, if
these values actually had methods, we'd just delegate to them
instead of
special-casing it", and wondering how much work it would take to
solve auto- or
manual boxing in a way that people would like. I don't want to be
distracted
by that and end up with nothing to show for the hackathon work that
we did on
AH, though.
hdp.
