Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Re: RFC: automating modular classes

by blindluke (Hermit)
on Jan 26, 2015 at 19:18 UTC ( [id://1114553]=note: print w/replies, xml ) Need Help??


in reply to RFC: automating modular classes

The more, the merrier. Personally, I like the minionize($hashref) option better, mostly because it avoids creating two packages for every class I want.

The implementation of the methods passed as anonymous subroutines in the %Class hash seems a bit difficult to read though. Still, this could probably be avoided:

use Minions (); my %Method; # maybe this hash could be already imported into # the namespace with a param passed to Minions my %Class = ( name => 'Counter', interface => [qw( next )], implementation => { methods => { next => $Method{'next'}, }, has => { count => { default => 0 }, }, }, ); $Method{'next'} = sub { my ($self) = @_; # maybe this could be avoided with some sugar $self->{-count}++; }; Minions->minionize(\%Class);

If there would be some more sugar to facilitate writing the package this way, I would like it even more. Is the line interface => [qw( next )], needed? Maybe it could be replaced with public_methods => {...} section within implementation, and all the methods added there would automagically land in interface => []?

The documentation says nothing (or I did not read it carefully enough to find it) about how Minions behaves when stuff goes wrong. On the other hand, the fact that you provide code examples wrapped in simple tests, is wonderful. More examples should be written this way.

Looking forward to future updates. Best luck with your distribution.

- Luke

Replies are listed 'Best First'.
Re^2: RFC: automating modular classes
by Arunbear (Prior) on Jan 27, 2015 at 17:59 UTC
    Thanks for the feedback. I was considering leaving that section out of the documentation, because it doesn't scale up very well, but I ended up leaving it in for completeness.

    The subs in the "implementation" section don't really need to be anonymous - they could be also be refs to named subs defined elsewhere.

    The interface => [...] is needed because the whole point of this module is to encourage programming in terms of interfaces, and interfaces should be independent of a particular implementation.

    This is also the reason for having separate packages (but also having the just the interface and POD in one file, it's easier to get an overview compared to having to swim through a sea of code).

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1114553]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others imbibing at the Monastery: (4)
As of 2024-03-29 09:29 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found