Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Module name proposal for new ordered hash implementation

27 views
Skip to first unread message

Brian Katzung

unread,
Aug 23, 2012, 6:20:54 PM8/23/12
to
I would like to open a discussion regarding a module name for a new ordered-hash module that I've been developing under the proposed name "Data::Hasray" (short for hashed array).

Here's some info from my README file:

FROM THE SYNOPSIS

Data::Hasray provides an object-oriented interface to tied, ordered
hashes. Hash elements may be assigned keys explicitly or automatically
in mix-and-match fashion like arrays in PHP.

It also includes support for trees of nested hasrays, tree traversal,
and conversion to and from native Perl data structures.

Suggested uses include structured configuration information or HTTP
query parameters in which order may at least sometimes be significant,
for passing mixed positional and named parameters, or for porting PHP
code.


ALTERNATIVES (FROM SEE ALSO)

Array::AsHash
An array wrapper to manage elements as key/value pairs

Array::Assign
Allows you to assign names to array indexes

Array::OrdHash
Like Array::Assign, but with native Perl syntax

Tie::IxHash
An ordered hash implementation with a different interface and data
structure and without auto-indexed keys and some of Data::Hasray's
other features

Tie::Hash::Array
Hashes stored as arrays in key sorting-order


RATIONALE AND DIFFERENCES

Hashes are a natural data structure for organizing information, and arrays
are a natural data structure for building ordered lists. Sometimes you
want your organized data (hashes) to be ordered too, like an array. One
example would be resource configuration information, organized by
resource name, for resources that must be loaded in a specific order
(e.g. due to dependencies) rather than some pseudo-random order.

Some of the key features that distinguish Data::Hasray from other
implementations are as follows:

1) The ability to mix-and-match values with and without explicit keys.
Values without keys are assigned a sequential index as key
automatically. PHP, for example, also supports this.

2) Built-in path traversal that supports auto-vivification of nested
data structures just like you would expect when using native hashrefs
and arrayrefs.

3) Easy conversion to or from native Perl hashes and arrays either at
the level of a single hasray or as a nested tree of hasrays, with
either an array-based or hash-based emphasis.

** CUT **

The full pod docs show more about how the interface and syntax differs from other implementations, and I'll be happy to post them upon request.

- Brian

Brian Katzung

unread,
Aug 23, 2012, 9:23:29 PM8/23/12
to
On Thursday, August 23, 2012 5:20:54 PM UTC-5, Brian Katzung wrote:
> I would like to open a discussion regarding a module name for a new ordered-hash module that I've been developing under the proposed name "Data::Hasray" (short for hashed array).
>
> Here's some info from my README file:
>
> FROM THE SYNOPSIS
>
> Data::Hasray provides an object-oriented interface to tied, ordered
> hashes. Hash elements may be assigned keys explicitly or automatically
> in mix-and-match fashion like arrays in PHP.
>
> It also includes support for trees of nested hasrays, tree traversal,
> and conversion to and from native Perl data structures.
>
> Suggested uses include structured configuration information or HTTP
> query parameters in which order may at least sometimes be significant,
> for passing mixed positional and named parameters, or for porting PHP
> code.
> [...]
> - Brian

Another possibility might be something like Tie::Hash::Autokey (constructor/initializer function "thwak()"?), but this class is not intended to be used with tie; the tie is done as part of new() and is more of an implementation detail.

Brian Katzung

unread,
Aug 24, 2012, 9:03:52 AM8/24/12
to
On Thursday, August 23, 2012 5:20:54 PM UTC-5, Brian Katzung wrote:
> I would like to open a discussion regarding a module name for a new
> ordered-hash module that I've been developing under the proposed name
> "Data::Hasray" (short for hashed array).
>
> Here's some info from my README file:
>
> FROM THE SYNOPSIS
>
> Data::Hasray provides an object-oriented interface to tied, ordered
> hashes. Hash elements may be assigned keys explicitly or automatically
> in mix-and-match fashion like arrays in PHP.
>
> It also includes support for trees of nested hasrays, tree traversal,
> and conversion to and from native Perl data structures.
>
> Suggested uses include structured configuration information or HTTP
> query parameters in which order may at least sometimes be significant,
> for passing mixed positional and named parameters, or for porting PHP
> code.
>
> RATIONALE AND DIFFERENCES
>
> Some of the key features that distinguish Data::Hasray from other
> implementations are as follows:
>
> 1) The ability to mix-and-match values with and without explicit keys.
> Values without keys are assigned a sequential index as key
> automatically. PHP, for example, also supports this.
>
> 2) Built-in path traversal that supports auto-vivification of nested
> data structures just like you would expect when using native hashrefs
> and arrayrefs.
>
> 3) Easy conversion to or from native Perl hashes and arrays either at
> the level of a single hasray or as a nested tree of hasrays, with
> either an array-based or hash-based emphasis.

Now I'm thinking more along the lines of Data::XHash, for "extended hash". I think this may be more likely to "hit" on searches for hashes (although the default CPAN search doesn't seem to do partial word searches, however searching distributions does).

Do most mod developers agonize/change their minds this much?? :-)

- Brian
0 new messages