develooper Front page | perl.perl5.porters | Postings from March 2011

Re: Revising Perl's OO docs - a new OO tutorial

Thread Previous | Thread Next
Johan Vromans
March 9, 2011 23:27
Re: Revising Perl's OO docs - a new OO tutorial
Message ID:
Joel Roth <> writes:

> Object::Tiny is useful because it is minimalist.
> [...]
> I added my own simple setter:
> [...]
> That's enough for my stand-alone app.

Basically, you augmented Object::Tiny to the level that I described as
minimal for a struct builder.

> If you're "rolling your own" on top of Object::Tiny,
> you may need to access the hash structure for
> for a set method, or a serialize method, or 
> for some type of AUTOLOAD based delegation.

If you're "rolling your own" on top of Object::Tiny, you'll very soon
incorporate the few lines of O::T code you can still use and drop O::T
alltogether. It is hardly worth the effort to keep it as an additional
layer (and additional dependency) in your module.

> Do our recommendations for OO frameworks consider
> the learning process, or do we assume that a
> newbie should start with Moose because that is
> what an expert would do?

Even with an expert framework like Moose (not my words) there's a
learning curve. Using Moose is not trivial. Installing Moose is even
less trivial. It has a dependency chain of 40 modules, several non-PP.
And even if you overcome that, when something goes wrong you'll be
confronted with the bare metal of Perl's OO system. So a basic
understanding of Perl's OO fundamentals is necessary anyway.

> When I asked Adam Kennedy, "why not add setters to Object::Tiny?" he
> explained that while everyone will want setters, people won't agree on
> syntax.

In other words, O::T is useful since it doesn't do anything that may be
considered controversial.

I'd say: choose a setter syntax, implement it, use it, and cut the
energy-splilling semi-religious battles.

> And we don't agree on frameworks, either.

Same here. 

> Diversity in perl frameworks may similarly discourage developers
> (including organizations) that want a single right answer.

Exactly my point.
There should be choices, alternatives, but based on functionality and
not on cosmetic details.

A final note: I deliberately made the destinction between a struct
builder and an OO framework. I still think a good struct builder would
suit the needs in many situations where now a sort-of-OO framework is

-- Johan

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About