use Perl

Eek, roles behaviour differently depending on whether you do them separately or together?
It's that it's a gotcha that the API should never have allowed.

Actually there are very good reasons why there are two ways to compose roles.

The ideal way to compose roles is to do it all at once like Ovid showed. This takes better advantage of conflict checking because it first creates a composite role of all the roles passed to with and then applies that role to the class.

The second way is to have multiple with statements. This way is not really recommended because it bypasses the conflict checking, which, oddly enough, is exactly why it is useful. As dagolden said, Moose expects you to know what you're doing.

This is (IMO) very perlish as we suggest (in the docs) that you do it correctly, but we know that the real world is messy, so we allow you the option of the not-so-correct way if you need it.

b) Use this SECOND heavy sugar layer on top of the FIRST sugar layer, on top of Class::MOP.

Funny, doesn't MooseX::Atom qualify as exactly that?

And now the primary interface to Moose is using D:D or something like it ...

Actually, MooseX::Declare is just another way to use Moose, but very surely not the primary.

Many people are using MooseX::Declare, and find it very nice and elegant, but many others (myself included) are not willing to use MooseX::Declare or Devel::Declare in production because it is not yet mature enough. Personally, my reasoning is that I feel it still exposes too much internals when it errors and makes for some difficult debugging. Of course when MX::Declare no longer has these issues and is more mature, I will no doubt start using it more, but I can assure you that the primary Moose interface is still plain old Perl and will remain to be for the forseeable future.

For the record, I agree with you, ... although I am conflicted. On one hand I can see all the horrors that you see, I saw them (or the potential of them) in Perl 6. On the other hand, I have to agree with chromatic, the language itself cannot be a test bed for experimentation, that type of thing belongs in modules and extensions (we use the same philosophy with Moose and new feature proposals, they have to be a MooseX:: first). Devel::Declare just expands the range within which these experiments can explore. As with all of CPAN, the crap will float to the bottom and the good stuff will rise to the top and perhaps in some cases drive forward the language itself.

- Stevan

It shouldn't take too long since you only have 16 non-core dependencies to go through. FWIW, I am pretty sure there are more then 32 modules on CPAN now, it has grown a lot in the past few years ;)

Sorry, couldn't resist. But in all seriousness we would be happy to help with this either on IRC or the Moose mailing list. The biggest problem I have seen when installing Moose on a bare bones system (and yes I have done it many MANY times so I am empathizing and not mocking) is that we require more up to date versions of the Test:: toolchain, which can get quite ugly sometimes.

- Stevan

Yeah I know, I still have servers running Moose 0.24, so I am with you. We have been discussing trying to make these things smoother in various ways so that people can upgrade and say, get a performance improvement, but opt out of a feature/API change. Similar to the use feature in 5.10. It is still not perfect, but it might help ease those of us (me included) who have to deal with production environments all the time and for whom upgrading it usually not an option.

We have a better object system than you do! Just install Moose (but be aware that it might have backwards-incompatible changes in a few months)

What changes in a few months? I am not aware of such plans. We are generally highly responsible about our backwards incompat changes. Changes happen and sometimes they are hard and ugly, this is the real world after all and they need to happen. But ...

I suspect your just being sarcastic and playing the devils advocate here. Your right, having a decent object system that is not in core and needs to be installed via CPAN is ugly.

- Stevan

Actually the CLR is pretty flexible, it used to be that ILASM was very much just C# written in Assembler, but recent efforts to make the CLR more dynamic (IronPython, etc) seem to have really pushed it forward. While I am not a fan of their OS, Microsoft Research has some really *really* smart people working there who are doing a lot of very cool stuff.

They have had production quality COBOLs on the .NET platform for a little while now. Given how the CLR works it becomes really easy to either have your COBOL call other libraries or your other libraries call COBOL.

If Tom owns it, can we get it back from O'Reilly?

One might think we're overusing roles, but so far, it's worked out extremely well with very few downsides

Well this is good to hear, perhaps all your examples of edge cases and oddities have skewed my perception of your code base. Although, your anti-inheritance stance does make me think perhaps you've gotten a little too drunk on the role kool-aid.

I guess my worry is that your not using all the tools at your disposal and therefore wanting to shape the tools you are using in such ways as to compensate. Inheritance is no more evil then roles when used properly, and delegation is sometimes a far superior solution then either of them. Hell, even multiple inheritance can still come in handy sometimes.

And while I agree that strictness of composition is useful, there is a tradition in the Perl community of giving you enough rope and Moose tries to strike a balance between enough rope and saving you from yourself. But the fact most of your issues stem from (what I perceive as) more extreme or uncommon usage patterns, it makes me think a MooseX module or optional "strict" setting is more appropriate.

- Stevan

Yeah sorry, that was an bad title written off the cuff and then not really considered, I didn't mean it as snarky as it sounds :)

Yes, it is really important that a programmer can see clearly when a trait method is being overridden - just as it is important that it is clear when an inherited method is being overridden.

I agree with Dr. Black on this point, but this is just language theory and not implementation details. It can be argued that reading the source provides this feature. Dr. Black goes on to say ...

Similarly, I agree that if the normal Perl environment does not provide good programming tools, then the implementation of traits for Perl ought to have done something to make it clear that a class method was overriding a trait method.

Perl::Critic is a tool in the modern Perl environment that provides this, so therefore we don't have to resort to something more drastic. You however seem to reject that in this statement ...

I suspect (though I can't prove) that many Moose developers aren't using Perl::Critic and thus aren't likely to benefit from this, thus, I agree with the traits researchers that the safety features should be in the language (or library) level rather than pushed into external tools.

Your conclusion (obviously) leans toward your desires, but I could just have easily had said "if they are not using Perl::Critic, they should be". If people are not willing to use the tools provided them (for free) then why should the core Moose team go out of their way to do still more work simply because someone chooses not to use another perfectly good tool?

In the end, and I have said this before, I think you are overusing roles.

While roles are an excellent replacement for multiple inheritance they possess many of the same (or similar) dead ends and pitfalls if used too heavily. It is my opinion is that using the alias/excludes feature is a code smell and that more than 3 roles being composed into a single class is a mild code smell that if not watched careful will turn into a full blown stink.

These are my opinions in the end so you can take them or leave them, but they are founded on many years of using roles in several big work projects, many CPAN modules and countless discussions had with others on IRC. I have probed the theory, but I have lived the practice.

I don't know that this will necessarily cause movement on anyone's part, but it's nice to know I wasn't totally insane in my reasoning

I think at this point, the movement needs to be yours.

You will note here that any new features for Moose must first be vetted through a MooseX module. At this point (thanks for rafl and others in the Moose team) role composition is now very hookable and you should find it much easier to create a MooseX module to so this now.

- Stevan

Well if you are persistent it shouldn't be a problem ;)

According to the Pickaxe book (figure 18.4) (page 247 of the first edition). Mixins modules are actually proxied. You can see in the diagram that it inserts a Proxy class between Guitar class and the Object class. The Proxy class does not have any methods itself, but instead it has a pointer to the method table of the module it is proxying. This gets more and more ugly and complicated the more modules you mixin, however it does explain the odd "last wins" behavior.

Of course, I am not sure if this is still how it is done, after all the first edition of the Pickaxe book is almost 8 years old now.

- Stevan

I understand your issue, but the number of possible combinations available for has is huge and when you start introducing default values for any of them you are heading down a very slippery slope. As you said in the comment above, you would prefer ro, but some people would expect rw, while still others would rather we support PBP-style accessors and then there is the semi-affordance crowd, and the public reader/private writer crowd, the list can go on and on. In my mind the only solution to all these differing (and equally valid) viewpoints is to favor none of them but allow all of them (which is exactly what Moose does). I think this embodies the spirit of TIMTOWTDI and is therefore (IMO at least) the most "perlish".

The problem with an error message is the same as trying to decide which default to use. Someone wins and someone looses. If I throw a warning when there is no value for 'is', then someone who has a legit use would have to suppress the error. Personally i think that the best solution here is Perl::Critic (same as the role method issue you brought up). Perl::Critic is entirely optional, very configurable and does not impose any runtime or compile-time penalties.

Unfortunately most of this discussion has actually taken place on #moose and therefore is not easily google-able.

- Stevan

MooseX::Declare is part of the overall Moose project, it will almost certainly not deviate too far from what Moose does on key issues like this. However which might be nice is to add support for the Perl-6 style of doing this, like so:

class Foo is rw {
   has bar;
   has baz;
}

Here all of Foos attributes will be (is => rw) automagically. I think the key issue here is that Moose will not and should not do anything you don't ask it to do. DWIMery is very VERY slippery slope, too much of it is really bad and too little gets you tedious code (see also Vanilla Perl OOP). Moose tries to strike a balance and not be too knee-jerk about adding support for DWIMery.

- Stevan