We lose some error checking and ability to use it as role or put type checks or coercion (none of which I did either but some of it would be a one or two line addition)

Any errors will be checked when the underlying array operations are performed. And the messages will be concise and informative.

Unlike those that Moose produces!

for example a web spider object would have a user agent but it would be pleasant to have $spider->get instead of having to write $spider->user_agent->get

But, that can be done in one line with no modules:

package Spider;
...
*get = *{ $self->ua->get };
...
[download]

The bare bones mop that may come into the core in 5.24 or something is an example of how little agreement there is on which features are crucial and which are in the way.

Oh Dog! If Perl core starts coming with a MOP; then I sure hope that they also provide a compile-time -DBukIt to throw it away.

I mean, what good is a MOP without a BukIt :)

For error checking I meant your constructor can be called with incorrect/missing size or “bad” invocant and won’t complain then will complain “cryptically” and not from caller’s perspective on its methods (but only if warnings are on); e.g.: Argument "camel" isn't numeric in numeric eq (==) at Package line number…

Your counter examples are spot on and if stevan couldn’t convince you Moose is a good tool there is no way I ever could. :P The traits give you more flexibly and depending on the package add exactly one line of code. Whereas the aliasing you’re doing would add up to hundreds to achieve the same thing and would not be properly overridable/inheritable/mixable/requirable, Unstandardized and probably untested. Types doing any number of complicated checks and validation with just a line as well and one more to do something like upgrade "http://asfd.qwer" to isa(URI). My examples being mostly toy code is not making a terribly good case I know… :| Since the stuff is just Perl more just Perl can be shown to do the same-ish; we haven’t talked around/after/before either which is quite a bit harder in plain Perl, especially in a way that can be altered or overidden in consuming classes. Some of the strength is that Moo/Moose and friends come with docs, tests, community: consistency and support and extensibility; DRY too. I find it much easier to debug than YAOO system or series of inconsistent idioms executed by 5 different hackers on a code base, all with their own style and rationale.

Your counter examples are spot on and if stevan couldn’t convince you Moose is a good tool there is no way I ever could. :P

You're right. I wrote what is inside the spoiler tags before I thought again about that statement and you're right, I'm arguing with the wrong man. You've been polite and generous enough to conduct a discussion with me -- which is most appreciated -- so, please feel free not to look inside the spoiler. And if you do peek inside, do not feel obliged to respond :)

The problem with my discussions with stvn; are the same problems with the whole Moose documentation. They say what Moose can do; but completely avoid any rigorous discussion of why you might want to do that, or whether, in OO theory and practice terms, it is a good idea.

Then again, I guess if I had expended as much time and effort on a project as he has on Moose; I would also be keen to dodge any discussion that leads to the conclusion that much of it probably shouldn't have been done. Especially when there are few if any good counter arguments beyond accussing me of being "performance obsessed".

I'm not; but I am performance aware; as are many other people; hence the existence of Mouse, Moo, Role::Tiny etc.

The problem I have with Moose, is not (for the most part) what it does; nor the syntax it uses to do it; but rather the way it is implemented. As I demonstrated in Re^12: Data Structures most of what it does, can be done in a couple of dozen lines of fairly ordinary Perl code; more quickly (in terms of compile-time and run-time) and without the need to involve several hundred auxiliary modules, each of which imposes the overhead of dozens or hundreds or thousands of lines of compile time burden and run-time overhead.

Types doing any number of complicated checks and validation with just a line as well and one more to do something like upgrade "http://asfd.qwer" to isa(URI).

Because Moose provides the facility to validate that a parameter is a non-negative, non-palindromic, prime except on the third Tuesday after a blue moon when it can be negative and palindromic, but not prime; doesn't mean that it is either necessary or useful to do so.

Most of the time, most of my subs and methods do not validate that expected numerical inputs are numerical; because: if they really need to be numeric and they aren't, then a very clear message will be issued at the point of use. And I as module user, would much rather receive an error: Argument "a" isn't numeric in substr in Module at line 123 and have to work out from where in my code that line is being invoked than have to try and interpret the 300 lines of gibberish that Moose spews out.

Now, I admit that there are times when I'm using one of the more complex modules on CPA and I get an error from some line deep in the guts of one of the modules used by one of the modules used by the module I'm using (Phew!:), where by tracking down the place in my code that leads to that error is a right royal pain. But I don't believe that every module validating the life out of every input parameter is the answer; because I validate, then the module I use validates, and the modules it uses validate, and the module they use validate...and everything turns to treacle.

A far better response would be to add Carp traceback into the core.

My examples being mostly toy code is not making a terribly good case I know… :|

Actually, the examples in this thread are perfect for showing that unless you routinely write setter & getters for your modules -- and there are very strong arguments that you shouldn't be doing so; especially public accessible ones -- then you end up writing almost exactly the same amount of code using Moose as you do using native Perl. Except that Moose generates a bunch of stuff you don't need and probably shouldn't use.

Since the stuff is just Perl more just Perl can be shown to do the same-ish; we haven't talked around/after/before either which is quite a bit harder in plain Perl,

And that's the nail on the head. Let's start with a simply method:

sub doit {
    my( $self, $a, $b ) = @_;
    $self->{thing} += $a;
    $self->{thing} *= $b;
}
[download]

So now let's say that there are good reasons(*) for validating our args, and also for checking stuff before we allow the call, and some after, and some around it. The code that now must be executed ends up being something like this:

sub doit {
    my( $self, $a, $b ) = @_;
    $self->_validate_self( __PACKAGE__ );
    $self->{validators}{'doit_a'}->( $a );
    $self->{validators}{'doit_b'}->( $b );
    $self->{befores}{'doit'}->( $self, $a, $b );
    my( @results ) = $self->{arounds}{'doit'}->( $self->{setters}{doit
+}, $self, $a, $b  );
    $self->{afters}{'doit'}->( $self, $a, $b );
    return @results;
}
[download]

Eight function calls to add one number to an attribute and multiply it by another!

Write that yourself and you get:

sub doit {
    my( $self, $a, $b ) = @_;
    die unless $self =~ __PACKAGE__ and look_likenumber( $a ) and look
+s_like_number( $b );
    ## do some stuff before
    $self->{thing} += $a;
    $self->{thing} *= $b;
    ## do some stuff after
    return $self->{thing};
}
[download]

Because Moose can't manipulate the AST, every damn keyword in those cute but functionless examples:

  package Parent;
  use Moose;
  sub rant { printf "        RANTING!\n" }
  before 'rant' => sub { printf "    In %s before\n", __PACKAGE__ };
  after 'rant'  => sub { printf "    In %s after\n",  __PACKAGE__ };
  around 'rant' => sub {
      my $orig = shift;
      my $self = shift;
      printf "      In %s around before calling original\n", __PACKAGE
+__;
      $self->$orig;
      printf "      In %s around after calling original\n", __PACKAGE_
+_;
  };
  1;
  package Child;
  use Moose;
  extends 'Parent';
  before 'rant' => sub { printf "In %s before\n", __PACKAGE__ };
  after 'rant'  => sub { printf "In %s after\n",  __PACKAGE__ };
  around 'rant' => sub {
      my $orig = shift;
      my $self = shift;
      printf "  In %s around before calling original\n", __PACKAGE__;
      $self->$orig;
      printf "  In %s around after calling original\n", __PACKAGE__;
  };
  1;
  In Child before
    In Child around before calling original
      In Parent before
        In Parent around before calling original
          RANTING!
        In Parent around after calling original
      In Parent after
    In Child around after calling original
  In Child after
[download]

Adds layer upon layer of subroutine call, and its associated overhead.

In compiled languages, and languages with runtime optimisers and JIT compilers, and those like Lisp that allow programs to operate upon the AST directly, the overhead of the layers of subroutine calls wrapped around tiny code snippets is either optimised away -- ie. in-lined -- or never exists because the tiny code snippets can be injected directly into the generated methods.

Perl is not such a language!

Perl subroutine calls were 80 times slower than interpreted (uncompiled) Java, and that was nearly 10 years ago. Java/JIT has come on leaps and bounds since then; Perl's performance has barely changed.)

(*)There aren't!

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.