[Linux-aus] Moose, JSON Question

[Daniel Pittman]

David Lloyd <lloy0076 at adam.com.au> writes:
> (Daniel said the things that have a 0 or 1 level of quotation depeding on what
> index you start arrays):

[...]

>> Well, you should probably think of a Moose "role" as a Java
>> "interface", kind of, except that it comes with implementation as
>> well.
>
> Yeah, a mixin type thing. An interface with some implementation that
> could be overridden.

*nod*  I was hesitant to use the term mixin, even though it is correct,
since many people don't know it — C++ doesn't have 'em, or something. ;)

[...]

>> Those "shenanigans" are the basic ingredients of method calling in Perl;
>> would you really want an OO system that completely and utterly changed
>> the calling convention of the language?
>
> YES.
>
> I wanted a Java like object system where imported "things" couldn't be
> seen from the outside.

OK, I can see that.  Moose isn't going to be that, at least by default:
one of their design goals is to be like the default Perl object system,
in which trust is more highly valued than software based protection.

Personally, I think the Perl approach is nicer, but this is one of those
areas where opinions vary wildly.

> And it's worse - it's class specific random things (if you don't use a
> method, it seems whatever whacko export method JSON uses doesn't
> expose it)

The conventional way to handle this is:

    use JSON ();

The 'use' statement takes two arguments, the package name and the
arguments to the 'import' method of that package.  An empty list, by
default, means 'import nothing'.

So, that will ask JSON not to fiddle with your namespace, which is
probably what you want to do.  (More pure-OO modules export only on
demand, so you have to ask for fiddling.  JSON, not so much.)

> so the behaviour changes depending on what you've written EVEN IF it's
> not called.

Well, kind of, yes.  OTOH, this is consistent with the rest of the Perl
OO layer, so changing it in Moose would be surprising to people who do
know the standard patterns.

> That said, do you think it's possible to write a "Moose::Strict"
> module that:
>
> * Only exposed methods explicitly defined as "subs" on that class, its
>   children or mixins/roles
>
> I suspect it's possible.

Absolutely.  In fact, you probably want to add 'no Moose' at the end of
your module, which removes the Moose sugar from the class (like the
'has' method).

For the rest of it you want namespace::clean, used like is documented
in the module:
http://search.cpan.org/~flora/namespace-clean-0.09/lib/namespace/clean.pm#Moose

That will sanitize out all the methods from your namespace, but leaves
the code in place.  You can use that to provide 'private' methods:

    package Test
    use strict;
    use warnings;

    sub private { ... }
    use namespace::clean;

    sub public { ...; private(); }

Then you will get the effect you want:

    Test->public()  => works, including the call to 'private'
    Test->private() => throws "method not found" error

Regards,
        Daniel