view release on metacpan or  search on metacpan

lib/Object/Anon.pm  view on Meta::CPAN

becomes similar in function to:

    package random::class::1;
    sub bar { "baz" }
    package random::class::2;
    sub foo { bless {}, "random::class::1" }
    $o = bless {}, "random::class::2";

except that all the bless stuff happens up-front, not at call time.

=item arrays

Arrays of hashes are similarly handled, returning instead an array of objects.

=item coderefs

Coderefs are installed as-is, that is:

    $o = anon { foo => sub { "bar" } };

becomes:

    package random::class::1;
    sub foo { "bar" }
    $o = bless {}, "random::class::1";

=back

=head2 Overloading

If a hash key is one of the overload operators (see L<overload>) then an
overload function will be installed instead of the named key:

    $o = anon { foo => "bar", '""' => "baz" };

becomes something like:

    package random::class::1;
    sub foo { "bar" }
    use overload '""' => sub { "baz" };
    $o = bless {}, "random::class::1";

Be aware that simple strings won't suffice for many kinds of overload (like
comparison operators), so much of the time you'll want to pass a coderef.
C<Object::Anon> won't do anything special with the code it generates for
overloads, so things like this can give odd results:

    $o = anon { "+" => "foo" }; # addition overload
    say $o + 3; # prints "foo";

=head1 TODO

Much of this is design that I haven't quite figured out yet (mostly because I
haven't had a strong need for it yet). If you have thoughts about any of this,
please let me know!

=over 4

=item *

Class caching. It'd be nice for the same return in a busy function to be able
to reuse the class that was generated last time. The only difficulty is
determining when to do this. L<Net::Twitter> does this with data returned from
the Twitter API by taking a SHA1 of the returned keys and uses that as a cache
key for a Moose metaclass. That's a nice approach when you know the incoming
hash is always JSON, but doesn't work as well when you can't predict the value
type (especially if the value is a coderef). Including the value type in the
cache key and not caching at all when coderefs are seen might work, but may be
too limiting. Another approach might involve looking at the caller, on the
basis that the same point in the code is probably returning the same structure
each time.

=item *

Overload clashes. Some overloaded operators are common words. If a hash had a
key of that name it would generate an overload, not a method of that name,
which isn't want you want. The only ways I can think of to deal with this is to
either limit the set of possible overload operators to ones unlikely to clash
(the symbol ones), or to make overload specified by an option or similar.
Neither of these options particularly appeal to me though.

=item *

Return hash. Should it be filled with the original data so you can access the
data as a hash as well as via the methods? I'm inclined to think not,
particularly since that makes it modifiable which then brings up a question of
whether or not those changes should be reflected in the the data return from
the methods. But if you wanted to then pass the hash to something else, it
won't do the right thing either. Maybe a hash deref overload?

=back

=head1 SEE ALSO

=over 4

=item *

L<Object::Result> - another way of addressing the same problem. This was
actually the direct inspiration for C<Object::Anon>. I liked the idea, but
hated that it defined its own syntax and required L<PPI>.

=back

=head1 SUPPORT

=head2 Bugs / Feature Requests

Please report any bugs or feature requests through the issue tracker
at L<https://github.com/robn/Object-Anon/issues>.
You will be notified automatically of any progress on your issue.

=head2 Source Code

This is open source software. The code repository is available for
public review and contribution under the terms of the license.

L<https://github.com/robn/Object-Anon>

  git clone https://github.com/robn/Object-Anon.git