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

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

Thread Previous | Thread Next
From:
Joel Roth
Date:
March 9, 2011 16:37
Subject:
Re: Revising Perl's OO docs - a new OO tutorial
Message ID:
20110310003716.GB32282@sprite
On Wed, Mar 09, 2011 at 08:38:38AM +0100, Johan Vromans wrote:
> "David E. Wheeler" <david@kineticode.com> writes:
> 
> > Object::Tiny accessors are read-only, however. This may be intepreted
> > as a feature, of course.
> 
> Yes. A feature that makes it use extremely limited and invites people to
> use the internal structure.
> 
>     package Foo;
>     use Object::Tiny qw{ bar baz };
> 
>     package main;
>     my $object = Foo->new( bar => 1 );
>     print "bar is " . $object->bar . "\n";
> 
>     $object->bar(2);    # doesn't do anything, doesn't complain either
> 
>     # Oh, I need this just once :)
>     $object->{bar} = 2;
> 
> There's just a thin grey area between 'too limited' and 'too powerful'.
> 
> What becomes apparent is that there's a need for a simple and useful
> struct builder.
> 
> A hash (or has ref) can do, but it is too liberate:
> 
>   my $obj = {};
>   $obj->{foo} = 2;
>   say $obj->{foo};
>   $obj->{Foo} = 2;      # typo
>   say $obj->{foo};      # hard to find error


Object::Tiny is useful because it is minimalist.
The code is easy to read and to understand.

I added my own simple setter:

    $obj->set(foo => 2);
    
    $obj->set(Foo => 2); # fails, Foo is not legal key

Because the syntax stands out, it's easy to visually (and
grep-ably) distinguish between read-only and read-write
behavior. A syntax supported cultural solution.

That's enough for my stand-alone app. I don't need 
enforcement.

Regarding the "just this once" issue, the point of 
starting with Object::Tiny is you deal with 
a miniscule code base that you can understand for yourself.

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.

Implementing and debugging these custom features may be a
waste of time for a skilled career programmer, but for
a learner can be more educational than navigating the
depths and shoals of a big framework.

Now that I have experience with simpler tools, I'm better
able to understand how to utilize something fancier.

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?

> Turning this into a straightforward struct builder saves typing of some
> braces and protects against typos:
> 
>   my $obj = Struct qw(foo bar);
>   $obj->foo = 2;
>   $obj->foo(2);         # equivalent to the above
>   say $obj->foo;
>   $obj->Foo = 2;        # runtime error
> 
> This would suffice for a simple struct builder.
> 
> A possible extension: some form of type checking:
> 
>   my $obj = Struct qw( foo => '$', bar => '@' );
> 
> This is what Class::Struct does (except from the lvalue part).
> 
> I wonder whether the checking should be on type, or on content:
> 
>   my $obj = Struct qw( foo => 'i', bar => 's' );
>   $obj->foo = 2;
>   say $obj->foo;
>   $obj->foo = 'bar';        # error: not an integer
> 
> Note that this is not really different from option value checking in the
> style of Getopt::Long.

Moo handles the need for checking very neatly; it doesn't
provide a declaration, but let's you give a code reference.
No hidden magic. Easy to expand.
 
> I think this is where a simple struct builder should end. Anything else
> (more powerful accessors, logic, inheritance) should enter the realm of
> class builders.

It hard to make a choice among "simple" alternatives.

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.
And we don't agree on frameworks, either.

It's indicative of a larger issue of fragmentation:
Choice is good for exploration, experimenting, individuality.

One the other side, Un*x fragmentation led to a decline in
deployments to a more uniform OS family. I read that
multiple competing LISP implementations are implicated in
the decline of that language. Diversity in perl frameworks
may similarly discourage developers (including
organizations) that want a single right answer.

We see to want both the artistic advantages of diversity, and the 
market- and mind-share that comes with uniformity.

I would like to see a happy (or at least satisfactory)
middle ground. While many of us may like the idea of
minimalism plus a small subset of conveniences, it's
hard to agree on which subset.
 
> -- Johan

-- 
Joel Roth

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About