Re: MX-Singleton credits (C) 2001 Shawn Moore
2001 is years before I got involved in Perl. Huh. I'm also guessing a Dist::Zilla screwup. Anders Nor Berle (Debolaz) wrote the first version of MooseX::Singleton. I took over once I needed to have singleton magic in my code, because the initial implementation was insufficient. MooseX::Singleton 0.01 was a role that wrapped your "new" method. I basically rewrote it entirely to provide a metaclass instead. Dave got involved a few versions later to help clean up. He's still in the process of doing that. But he did not "make" MooseX::Singleton. MooseX::Singleton 0.25 had the correct copyright information: Copyright 2007-2009 Infinity Interactive MooseX::Singleton 0.26 released (by Dave) changed it to: This software is copyright (c) 2001 by Shawn M Moore. I haven't touched MX::Singleton in years, because I stopped doing stuff with singletons. Shawn 2011/4/9 Stevan Little : > I KNEW IT! Sartak is a time traveller, this is PROOF! PROOF I TELL YOU! > > > > On Apr 9, 2011, at 4:35 PM, Darren Duncan wrote: > >> Dave, >> >> As I've been testing the Moose 2 release candidate today ... >> >> I noticed that the latest MooseX::Singleton 0.26 is full of >> copyright/license statements that credit it to Shawn M Moore for 2001, which >> seems wrong on both counts, both since AFAIK you made it and also because >> Moose itself is only half that old. >> >> Might this be Dist::Zilla messing with you? >> >> -- Darren Duncan > >
Re: Meta::Attribute::Native::Trait vs MooseX::AttributeHelpers
On Tue, Oct 27, 2009 at 1:41 PM, Evan Carroll wrote: > It is hard to have these discussions being banned from IRC, but maybe > - beyond a notice in MX:AH deprecation - some functionality notifying > the user of an API change is required? No API change is required. Old code can continue to use MXAH. New code should use native attributes. > Like something in MX:AH that > when used with a Moose > .90 the attribute traits would output a nice > warning message. > > Warning the functionality of MooseX::AttributeHelpers has been moved > to core, please reference "Moose::Meta::Attribute::Native" for the new > API. I don't see any reason to start warning about it. The code will continue to work fine. MXAH is not really deprecated (we're not going to remove it from CPAN), it's more just superseded. > I've often thought that warnings were better explicit and overly > verbose in libraries and disabled via -X by the end user, but maybe an > env DEVELOPMENT flag would be just as useful. There are at least a few > examples of where as a developer I was stung with stuff that was > currently supported but deprecated, supported but retarded, or > implemented but unsupported. > > -- > Evan Carroll > System Lord of the Internets > http://www.evancarroll.com > Shawn
Re: testing if an object has an attribute?
On Wed, Oct 14, 2009 at 11:08 AM, Yuri Shtil wrote:
>> $obj->meta->has_attribute('foo')
>>
>> Reading through the Class::MOP docs is helpful in finding out how to
>> access all of the class definition information that gets stored.
>>
>> -doy
>>
>
> Sorry for reopening an old subject.
> This does not work if the attribute is inherited.
>
> --
>
> Yuri
>
>
$obj->meta->find_attribute_by_name('foo') will check superclasses too.
Shawn
MooseX-AttributeHelpers 0.18_01 needs smoking
Hey folks, Yesterday I uploaded a new release of MooseX-AttributeHelpers. The big new feature is that your attributes can have method providers as a *trait* instead of a new metaclass. This means MXAH plays much better with other extensions. We kept the old metaclass interface for backwards compatibility, so you should not have to edit your code at all. I did the initial work months ago but let it bitrot. Yesterday doy modernized it. There certainly could be some bugs lurking outside of the reach of MXAH's own tests. I'd appreciate it if you tested your apps and libraries that use MXAH against this dev release. Please let us know of any problems, however small. Thanks, Shawn
Re: Moose Talks at YAPC::NA
The results are in. 16 talks with tag Moose accepted, out of 17. We've got the largest tag in the cloud. :) http://yapc10.org/yn2009/talks/tag/moose Great job everyone. I look forward to seeing most of your talks! Shawn
Re: how to trigger actions on Role use
On Fri, Apr 24, 2009 at 12:16 PM, Hans Dieter Pearcey wrote:
> See Moose::Exporter. (MooseX::Attributes::Curried *almost* does this, but the
> predicate isn't currently possible using it; Sartak, any good ideas?)
This doesn't currently work, but 0.02 will have it:
package YourApp::Attrs;
use MooseX::Attributes::Curried (
boolean_filter => sub {
my $name = shift;
return {
is => 'ro',
isa => 'Bool',
predicate => "has_$name",
};
},
);
Shawn
Re: Unfun with roles.
On Thu, Apr 23, 2009 at 11:13 PM, Elliot Shank wrote:
> with
> Foo => { exclude => 'foo' },
> Bar => {};
The key is actually "excludes" not "exclude".
Moose really needs to use Params::Validate and MooseX::StrictConstructor. :(
Shawn
Re: updating the Moose Quick-Ref Card
On Tue, Apr 21, 2009 at 4:10 PM, Darren Duncan wrote: > Sartak wrote: >> >> * Please remove my MooseX::Singleton from the choice related modules :) > > Is this just to save space due to MooseX::Singleton being simple or is it > deprecated? I think it's valuable, currently being the only MooseX I use, > and I'm not aware of another module that provides its feature. -- Darren > Duncan > There's nothing *technically* wrong with it -- it's implemented pretty well (thanks Ricardo and Dave). Singletons are questionable design (a necessary evil in my eyes), so I think the space would be better served by something excellent like MooseX::Declare. Shawn
Re: updating the Moose Quick-Ref Card
Hey Oliver, On Tue, Apr 21, 2009 at 3:36 AM, Oliver Gorwits wrote: > I'd be grateful if you could take a quick look, and let me know (on > or off list) of anything missing or incorrect that could be improved > upon, or new features to be included: * I'm not sure that $coderef is useful doc for "around". How about $next_method? * "dump" is not an exported function, it's a method in Moose::Object. * For is => rw/ro, perhaps instead of "forget", "exclude"? It's perfectly valid to not use "is". * required doesn't imply a value being passed through a constructor (e.g. with default). Perhaps "This attribute must always have a value." * The description of reader/writer/clearer makes it sounds like the user must define them. They are provided by Moose, you just need to tell Moose which name you want. Same with accessor. * builder: "Better [than default] for subclassing" * Some new types: RoleName under Str, Maybe[TypeName] * The idiomatic check of value's class has improved to: class_type 'SomeClass' * Please remove my MooseX::Singleton from the choice related modules :) * Some newer worthy MooseX modules: MooseX::Declare, MooseX::StrictConstructor, MooseX::ClassAttribute, MooseX::Role::Parameterized Shawn
Re: Moose Talks at YAPC::NA
I believe the Moose talks (with varying degrees of Moose focus) that have been submitted are: * Introduction to Moose (dhoss) * To Moose or Not to Moose (stevan) * Moose for Managers (gphat) * Extending Moose for Applications (sartak) * Fey (autarch) * Kioku (stevan) * XML::Toolkit (perigrin) That's really good! We could always use more though :) You have until Friday to submit a talk. You're welcome to speak even if you've never given a talk - after all, everybody who has ever presented at YAPC has had a first time. You don't need to be a Moose developer; I'd love to hear from a Moose novice about what still sucks about Moose. Shawn
Re: Moose Talks at YAPC::NA
On Fri, Apr 17, 2009 at 3:36 PM, Stevan Little wrote: > Anyone out there either submitted a Moose talk or is pondering submitting > one? >From my experience at Frozen Perl 2009, most people know what Moose is and have seen Moose code. While we should certainly give an Intro to Moose talk, but I think we're ready to really start branching out for Moose talk topics. I've submitted an Extending Moose talk that will focus entirely on the MOP for 50 minutes. It will kick ass! I encourage every one of you to give a talk. Some possible topics include: * Intro to Moose * Why roles kick ass (stevan gave a talk about this last year and it went very well) * A survey of useful MooseX modules (pimp your own!) * Types * Extending some non-Moose class like WWW::Mechanize * How Moose revitalized my project/business/marriage/misanthropy * Why you should (or should not) use Mouse * Killing roles once and for all with SIGNESes [tentative name] (Ricardo, I want to see this talk, okay?) Finally, there absolutely needs to be a MooseX::Declare lightning talk. The deadline for submission is Friday, April 24th. You have a week. Remember, speakers get in the door free! Shawn
Mouse needs a maintainer
Hey all, As many of you are well aware, I really don't like Mouse. I sincerely want everyone to use Moose instead. I even added this line to Mouse's POD for today's 0.20 release: B I also observed in #moose: Mouse is the PHP of the Moose world Although I started Mouse (to learn how Moose's meta-model fits together), I quite dislike maintaining this codebase. Unfortunately, Mouse needs a maintainer, because people are using it for important projects. In particular, Schwern has been using Mouse::Tiny, which bundles every class together in one easy-to-ship file, for Test::Builder2. Best Practical uses Any::Moose for Prophet and SD. Several important modules, like Data::Visitor, use Any::Moose. Quite a few people have come into #moose asking Mouse questions, because their bosses, clients, or users won't let them use Moose. Is there anyone who wants to take the maintenance torch? My only demand is that you deem Moose compatibility as nothing short of critical. Any::Moose *must* continue to work well, because Mouse is (hopefully) going to be deprecated some day. We just need to make Moose fast. (Alas, Mouse has been the only successful "fast Moose"!) Once Moose really does get fast, we need to ensure that it's trivial for Mouse users to come back to Moose. For this reason, Mouse should also do nothing beyond what Moose does. Any additional feature that core Moose does not have should be implemented as an extension and not be put into core Mouse. Beyond that, the new maintainer can call all the shots. Feel free to contact me in public or in private about this. Shawn
Re: triggers and the single meta-attr object
On Sun, Mar 29, 2009 at 9:25 PM, Stevan Little wrote: > If we want to keep it, lets keep it, but if we don't really have a reason, > lets just get rid of it. Get rid of it. We don't pass in the meta-attr for default or builder either. It's just going to bite us in the future when we try to avoid generating metaobjects. It's not like its removal will hinder anybody. Shawn
Re: Trait injection - request for ad hominem attacks
On Wed, Mar 25, 2009 at 12:08 AM, Sartak wrote:
> The issue I'm running into is make_immutable. Within the
> MooseX::InstanceTracking role (to be applied to Moose::Meta::Class),
> there's no way to hook into the *inlined* constructor.
Dave Rolsky pointed out that I could use MetaRole to achieve the
functionality I need. "use MooseX::InstanceTracking" uses
Moose::Util::MetaRole to give the calling class a role, and its
constructor class a role. The ENTIRE implementation is provided at the
end of this mail.
It doesn't do exactly what I wanted (traits injecting more traits) but
it's good enough.
Shawn
package MooseX::InstanceTracking;
use strict;
use warnings;
use Moose::Exporter;
use MooseX::InstanceTracking::Role::Class;
Moose::Exporter->setup_import_methods();
sub init_meta {
shift;
my %p = @_;
Moose->init_meta(%p);
return Moose::Util::MetaRole::apply_metaclass_roles(
for_class => $p{for_class},
metaclass_roles => [ 'MooseX::InstanceTracking::Role::Class' ],
constructor_class_roles => [
'MooseX::InstanceTracking::Role::Constructor' ],
);
}
Trait injection - request for ad hominem attacks
Hi all,
I wrote an extension, MooseX-InstanceTracking. It's on CPAN (
http://search.cpan.org/~sartak/MooseX-InstanceTracking/lib/MooseX/InstanceTracking.pm
) and github ( http://github.com/sartak/moosex-instancetracking/tree/master
). The idea of this extension is that metaclasses will cache all
instances of the class. It cleanly modifies several metaclass methods
such as construct_instance, clone_instance, rebless_instance, etc.
The issue I'm running into is make_immutable. Within the
MooseX::InstanceTracking role (to be applied to Moose::Meta::Class),
there's no way to hook into the *inlined* constructor. The inlined
constructor intentionally does not call meta methods because that's
what's slow to begin with!
I could easily define a trait for Moose::Meta::Method::Constructor
that calls track_instance on the metaclass. The problem is telling my
metaclass to use this constructor trait. Moose *does* have some
support for allowing a subclass to declare that it wants to use a
different constructor metaclass. Unfortunately, this is not enough.
Two extensions that want to provide behavior in inlined constructors
cannot compose. This sucks!
Attributes have some special magic where you can set a metaclass and
some traits. It'd be great to extend this pluggability to all
"associated metaclass" methods. Moose::Meta::Class would have a
constructor_traits method that by default returns an empty list. Roles
can modify this method to inject new traits. To be more concrete, what
I'd ultimately love to do is:
package My::Class::Trait;
use Moose::Role;
around constructor_traits => sub {
my $orig = shift;
my @traits = $orig->(@_);
push @traits, 'My::Constructor::Trait';
return @traits;
};
package My::Constructor::Trait;
use Moose::Role;
around _generate_instance => sub {
};
This way extensions that need to inject traits into associated
metaclasses would be able to compose. However, do you guys think this
would have unhappy implications for metaclass compatibility? It's one
topic I've not pondered too deeply over. (I really need to finish
reading AMOP!) Can anyone think of other potential issues?
Shawn
Re: Moose Accessor Suggestion
Hi Derek,
On Tue, Mar 10, 2009 at 9:48 PM, Derek Price wrote:
> Just a quick thought that occurred to me as I was reading
> Moose::Unsweetened... I hope the API isn't set in stone yet...
What getters and setters return certainly is set in stone. We'd break
to many apps if we changed it three years in.
But that's okay..
> If the
> accessors presented there are correct, then the accessor functionality
> might be slightly more efficient from a caller's perspective if the
> "old" (also "current", with no arg) value was always returned. Then,
> something like the following could be useful:
>
> my $old = $user->email_address($new);
>
> Whereas now, the above call would return $new, which is already known by
> the caller and therefore not useful.
>
> The new accessor would look something like this:
>
> sub email_address {
> my $self = shift;
> my $v = $self->{email_address};
>
> if (@_) {
> $self->_validate_email_address( $_[0] );
> $self->{email_address} = $_[0];
> }
>
> return $v;
> }
>
> Regards,
>
> Derek
Moose is quite extensible. If you're adventurous enough, you could
make this work as an extension to Moose. I don't know if we have for
handy examples of modifying accessors, even in the MooseX ecosystem.
I do know that a few people really want "chained" setters, which
return the object, so that you could do:
$datetime->set_hour(0)->set_minute(0)->set_second(0);
Your proposed extension would have a very similar structure, being
different in only a few lines. We'd be happy to help you write it!
If you want to start poking, check out the following documentation:
Moose::Manual::MOP
Moose::Manual::MooseX
As well as the "meta" and "extending" chapters of the Cookbook.
Shawn
Re: implications of using Any::Moose
Hi Jonathan, On Fri, Feb 27, 2009 at 7:27 PM, Jonathan Swartz wrote: > (resent - first attempt seemed to have gotten lost) > > I'm thinking of switching the CHI distribution from Moose to Any::Moose, as > a way to reduce install dependencies and overhead. The Mouse feature set is > adequate for my needs. > > But I realized that classes could get split between Moose and Mouse > depending on if/when Moose was loaded. e.g. This is certainly an issue that we ran into with Squirrel. One of the reasons I wrote Any::Moose (other than having the far better name) was to address this issue. Once Any::Moose chooses Moose or Moose at runtime, it will continue to use the same backer. If you find that's not the case please let me know. There's a test in Any::Moose to ensure this happens: http://tinyurl.com/bgyzvf . Notice how on line 27 Moose is loaded, but the line 32 Any::Moose still gives you Mouse. Shawn
Re: Attribute reset
has 'list' =>
( is => 'rw',
isa => 'ArrayRef',
lazy=> 1,
default => sub { [] },
clearer => '_clear_list',
);
> Wow. I have to re-read the docs. I missed that one. Thanks for your patience.
The "clearer" option to "has" is what's causing the _clear_list method
to be created for you.
Shawn
Fwd: simultaneous defined attributes and triggers
I accidentally replied to just Christopher:
-- Forwarded message --
From: Sartak
Date: Thu, Jan 29, 2009 at 8:07 PM
Subject: Re: simultaneous defined attributes and triggers
To: Christopher Brown
On Thu, Jan 29, 2009 at 7:54 PM, Christopher Brown
wrote:
> Hi Moose Folks,
Hey Christopher,
> Now, suppose that I use the syntax for defining attributes simultaneously,
>
>has [ qw(foo bar ) ] => (
>is => 'rw' ,
>isa => 'Int' ,
>trigger => sub {
>$_[0]->{foo} = $_[1]+2 ;
> #
>} ,
>);
Here's how I'd do this:
for my $name (qw(foo bar)) {
has $name => (
is => 'rw' ,
isa => 'Int' ,
trigger => sub {
$_[0]->{$name} = $_[1]+2 ;
} ,
);
}
Shawn
Re: Requiring roles
On Thu, Jan 15, 2009 at 8:46 AM, Elliot Shank wrote: > Is there a way to avoid the duplication here: > > use Foo (); > with 'Foo'; > > Is there a way to get "with" (or something similar) to do a require? > This works for me. If you're using a really old version of Moose you may need to upgrade. perl -Moose -e 'with "MooseX::Getopt"; Class->new_with_options' # doesn't explode :) Shawn
Re: Possible to disable/rename meta() method
On Wed, Jan 7, 2009 at 4:49 AM, Howe, Tom (IT) wrote: > Would be nice to be able to optionally rename or prefix it. > > I don't think a object meta class should add methods to the main interface > unless the object specifically needs to expose them. > > So by default there could be a _moose_meta() method and an easy way to create > a meta() -> _moose_meta() handler if required (per class). This could be a > global option if want to retain compatibility with existing modules that > require it. Yes, we all agree that it would be useful to give users the ability to rename or not install a meta. The problem is that in quite a few places in Class::MOP, Moose, and all of MooseX, we call $pkg->meta with the expectation that it'll be there and return the metaclass. It's just a small design problem, one we can fix with enough grunt work. :) > > Thanks Shawn > Ps. How do I subscribe to the mail list? Send mail to moose-subscr...@perl.org.
Re: Possible to disable/rename meta() method
On Tue, Jan 6, 2009 at 11:58 PM, Chris Prather wrote: > On Tue, Jan 6, 2009 at 11:56 PM, Yuval Kogman > wrote: >> 2009/1/7 Stevan Little >> >>> Tom, >>> >>> Nope, sorry 'meta' is used internally in Moose too much to override. >> >> >> Actually this is not as true today as it used to be... But we're still a bit >> too far off from being able to disable it. >> I think realistically it can be done in a branch in a few hours of work if >> anybody wants to try. > > How much of CPAN will it break if/when switched off ... The fix for CPAN modules is easy: instead of using $package->meta or Class::MOP::Class->initialize($package), use Class::MOP::get_metaclass_by_name($package). Also, it'll only break if you actually rename or don't install ->meta, so it's not going to break any back compat. It'll only break if you use a naughty MooseX, and it will generally break spectacularly. There's no reason not to do this. I'll get started on the branch. > > -Chris > Shawn
Re: Moose quick-ref card
On Tue, Jan 6, 2009 at 7:49 PM, Oliver Gorwits wrote: > Please mail me if you spot any errors or omissions. Hi Oliver, Looks great. In the interests of pedantry I'm going to have to cite you on a few details. ;) You have: has +$name => %options I think it'd be a good idea to quote the "+$name" so that users aren't bitten by Perl's quirk of +foo being valid.. but evaluating to just foo. I've seen a few users bitten by this. The "not ever set to undef" description of required is slightly wrong. Values in a hash can be nonexistent or undefined. required says they must exist. It is the type constraint that usually says the attribute cannot be undef. trigger may eventually stop passing $meta to the coderef. Just saying $self and $newval should be enough for didactic purposes, since $meta is not that useful, especially not to our non-Yuval users. lazy_build (and thus perhaps builder) should be listed after predicate and clearer, since it refers to them. __PACKAGE__->meta->make_immutable definitely deserves a mention as finalizing your class to make it faster. Thanks for this valuable resource! Shawn P.S. Looks like ProFont for the code snippets, but what font is that for the prose? I really like it.
Re: Prototype Attributes
On Wed, Dec 17, 2008 at 3:07 AM, Christopher Brown
wrote:
> package MooseX::Attribute::DateTime;
>
>has 'datetime' => (
>is => 'rw' ,
>isa => 'DateTime' ,
>coerce => 1 ,
>metaclass => 'MooseX::Getopt::Meta::Attribute',
>cmd_aliases => 'time'
>);
I hope that the Getopt options here wouldn't actually be in the
generic MooseX::Attribute::DateTime!
> package myApp;
>use Moose;
>with 'MooseX::Attribute::DateTime';
>
>has 'begin' => ( prototype => 'datetime', cmd_aliases => 'begin' );
>has 'end' => ( prototype => 'datetime', cmd_aliases => 'end' );
>...
I don't think overriding "has" is the right solution. How's this? I
rather like it:
package myApp;
use Moose;
use MooseX::Attribute::DateTime;
has_date begin => (cmd_aliases => 'begin');
has_date end => (cmd_aliases => 'end');
"has_date" could be configurable, you just pass the keyword you want
to "use MooseX::Attribute::DateTime". Alternatively, you could go even
further and allow extra parameters to be specified in the "use" line,
such as:
use MooseX::Attribute::DateTime (
'has_date',
needs_date => {
required => 1,
},
);
needs_date begin => (cmd_aliases => 'begin');
has_date end => (cmd_aliases => 'end');
Data::OptList (already used in several places in Moose as you know)
would make this trivial.
Shawn
Re: Can someone explain the logic behind Maybe (and I suppose Defined and Undef)?
On Wed, Oct 22, 2008 at 8:42 PM, Elliot Shank <[EMAIL PROTECTED]> wrote: > Why isn't there simply a part of an attribute specification where you say > whether undef is allowed or not? > Types are useful outside of the context of attributes. For example, MooseX::Method and MooseX::Method::Signatures both let you have Moose types on function parameters. Also, because Maybe is part of the type system, you could have a type which is an array reference of Maybe[Int]. Shawn
Re: Bug in empty method of MooseX::AttributeHelpers::MethodProvider::List?
Hi Tod,
On Thu, Oct 9, 2008 at 6:39 PM, Tod Hagan <[EMAIL PROTECTED]> wrote:
> All,
>
> Shouldn't
>
>sub empty : method {
>my ($attr, $reader, $writer) = @_;
>return sub {
>scalar @{$reader->($_[0])} ? 1 : 0
>};
>}
>
> instead say:
>
>scalar @{$reader->($_[0])} ? 0 : 1
Yes. Unfortunately it's way too late to break back-compat. :(
It's documented somewhere in the dist that the empty method is
deprecated because of exactly this.
> Also, I'm unfamiliar with the ': method' business after the subroutine
> name, can someone explain?
That's to tell Perl to not generate the warning "Ambiguous call
resolved as CORE::foo". perldoc attributes has more information.
>
> Thanks.
>
> Tod
Shawn
Mouse and Coat
Hi Alexis, I've been aware of Coat since you started it. (But I hadn't seen the value of a lite Moose until much later). I had even contributed two patches. :) I started Mouse (originally called Neutrino) a few months ago for fun, to better understand how Moose fits together. It wasn't going to be anything serious or used by anything. But then I mentioned it to a few people and here we are. Mouse strives very hard to be a *compatible*, fast, light replacement for Moose. Coat is the latter two. It's marginally compatible, but running s/Coat/Moose/g will probably not work for a decent sized project. There are too many details that are different. For example, if you leave out the "is" option to "has" in Coat, you get a read-write accessor. In Moose, you get no accessor (not even read-only). Coat probably did this to optimize for convenience. But it is something you have to know about when upgrading from Coat to Moose. I've tried to model even Mouse's internals on Moose as well. I have Mouse::Meta::Attribute, Mouse::Meta::Class->linearized_isa, etc. Mouse does provide a very barebones MOP, but that's often all you need. Almost all of the features provided by Mouse's MOP are given the same name and functionality as Moose. Even if you use the MOP you can probably safely upgrade from Mouse to Moose. Coat's MOP is quite a bit different (not bad, just different). There are a number of Moose features (such as practically all the type features) that Coat has that Moose doesn't have yet. Coat::Persistent is also nowhere to be seen in Mouse. So I think there's plenty of room in this space for two (or five) lightweight Mooses. :) Shawn
Re: Moose -> Mouse -> Mouse::Tiny/Muscle
Hey gang, I uploaded Mouse 0.08 just now. It has no hard dependencies. Scalar::Util is required only if you use weaken. Class::Method::Modifiers is required only if you use before/after/around. I'll see about inlining the latter. The only loss in functionality is the feature set provided by Sub::Exporter. But, as Yuval said, it is okay to make that kind of compromise. I haven't gotten to a (one-file) Mouse::Tiny but that's next. Shawn On Tue, Sep 9, 2008 at 9:30 PM, Michael G Schwern <[EMAIL PROTECTED]> wrote: > Sartak wrote: >> On Tue, Sep 9, 2008 at 4:20 AM, Michael G Schwern <[EMAIL PROTECTED]> wrote: >>> I looked at just copying in Mouse, but Mouse has dependencies which >>> themselves >>> have dependencies, some of them with XS. Ideally, what I want is >>> Mouse::Tiny, >>> or as I like to put it, "Muscle". [2] A stand-alone, single file, no >>> non-core >>> dependencies, 5.6 compatible implementation of 80% of Moose. That way I can >>> just copy it into the Test::Builder2 distribution and have a real OO system. >> >> I'd love to see Mouse itself go this way. There's little point in >> having a lightweight Moose that has a number of dependencies >> (especially XS). It looks like we could make all the dependencies >> optional, and only required if you use the features. > > Excellent. > > >> Here are Mouse's direct dependencies, and why we have them: >> >> * Sub::Exporter is used for a more powerful export. I use its extra >> features (as a user of a Sub::Exporter module) very infrequently, so >> being able to drop down to regular Exporter would be useful. > > It looks like extends(), has() and with() all depend on Sub::Exporter's > ability to customize by caller. However, that's easily emulated. > > >> * Scalar::Util is used for blessed, weaken, looks_like_number, and >> openhandle. It's in core as of 5.8, but if we need 5.6 then I think we >> can make it work: >> >> - looks_like_number and openhandle are used only for the Num and >> FileHandle type constraints. These aren't used very often as far as I >> know, so perhaps we can delay-require Scalar::Util. >> >> - weaken is only used whenever you want weak refs for an attribute. I >> personally do this with some frequency. But if you don't use it >> >> - blessed is used a lot. "use Mouse" also exports it. We could >> probably provide an alternate implementation that uses ref and makes >> sure it isn't a builtin type. > > looks_like_number(), openhandle() and blessed() all have short, pure Perl > versions that can be easily copied. > > weaken requires XS and weak ref support, but it's perfectly fine to load that > on demand. > > >> * MRO::Compat is used for get_linear_isa. We could implement this in >> Perl (and using mro::get_linear_isa if $] >= 5.10). > > It looks like that can all be separated from Class::C3. I wonder what the > performance hit will be? > > >> * Class::Method::Modifiers are used for before/after/around. I wrote >> this one, so we have more flexibility here. It's only a few pages of >> code, so we could just add it into Mouse::OneFile, or again delay-load >> it. > > That appears to only depend on MRO::Compat which we have to deal with anyway, > so it looks like a straight copy is possible. before, after and around will > be useful for TB2. > > > -- > E: "Would you want to maintain a 5000 line Perl program?" > d: "Why would you write a 5000 line program?" >
Re: Moose -> Mouse -> Mouse::Tiny/Muscle
On Tue, Sep 9, 2008 at 4:20 AM, Michael G Schwern <[EMAIL PROTECTED]> wrote: > I looked at just copying in Mouse, but Mouse has dependencies which themselves > have dependencies, some of them with XS. Ideally, what I want is Mouse::Tiny, > or as I like to put it, "Muscle". [2] A stand-alone, single file, no non-core > dependencies, 5.6 compatible implementation of 80% of Moose. That way I can > just copy it into the Test::Builder2 distribution and have a real OO system. I'd love to see Mouse itself go this way. There's little point in having a lightweight Moose that has a number of dependencies (especially XS). It looks like we could make all the dependencies optional, and only required if you use the features. Here are Mouse's direct dependencies, and why we have them: * Sub::Exporter is used for a more powerful export. I use its extra features (as a user of a Sub::Exporter module) very infrequently, so being able to drop down to regular Exporter would be useful. * Scalar::Util is used for blessed, weaken, looks_like_number, and openhandle. It's in core as of 5.8, but if we need 5.6 then I think we can make it work: - looks_like_number and openhandle are used only for the Num and FileHandle type constraints. These aren't used very often as far as I know, so perhaps we can delay-require Scalar::Util. - weaken is only used whenever you want weak refs for an attribute. I personally do this with some frequency. But if you don't use it - blessed is used a lot. "use Mouse" also exports it. We could probably provide an alternate implementation that uses ref and makes sure it isn't a builtin type. * MRO::Compat is used for get_linear_isa. We could implement this in Perl (and using mro::get_linear_isa if $] >= 5.10). * Class::Method::Modifiers are used for before/after/around. I wrote this one, so we have more flexibility here. It's only a few pages of code, so we could just add it into Mouse::OneFile, or again delay-load it. Anyway! I'd love to continue working on Mouse.
Moose 0.55 and Class-MOP 0.64 now on CPAN
Hello forest friends, I've just uploaded Moose 0.55 and Class-MOP 0.64 to the CPAN. The largest and most numerous changes are not to the code, but to the documentation. Dave Rolsky has expanded and reorganized the cookbook, so now we have chapters of recipes. Be sure to check out the new recipes on meta! Dave and Paul Fenwick have also cleaned up a lot of the documentation all throughout the codebase. Thanks a lot, guys! Codewise, we have only a few fixes: * Coerce can now accept anonymous types, just like subtype * Fix the $_ that is available in ->message of a type constraint (RT #37569) * Various immutable/inlined consistency fixes Moose! Shawn M Moore
Re: Trigger before/around/after stuff
On Tue, Jul 22, 2008 at 10:18 AM, Paul Driver <[EMAIL PROTECTED]> wrote:
> I think the major benefit of the "around" trigger was being able to filter
> the value going into the setter. I don't have any use case for 'before'
> that couldn't be accomplished with older "standard" (after) triggers - so
> some kind of setter-filter (needs a better name) would probably do just as
> well. That could be done by a MooseX, potentially.
Anything that depends on the old value would be a use case for
"before". For example, one of my uses would be:
has type => (
trigger => {
before => sub {
$registry->unregister_tile_by_type($_[0], $_[1]);
},
after => sub {
$registry->register_tile_by_type($_[0], $_[1]);
},
},
);
before is also useful for additional validation. You want to throw the
exception *before* you set an invalid value.
Shawn
Re: checking consistency between attributes
On Tue, Jul 15, 2008 at 8:29 PM, Stevan Little
<[EMAIL PROTECTED]> wrote:
> trigger => {
>before => sub { ... },
>after => sub { ... },
> }
+1 awesome
> The idea would be that the "after" would do the same as the normal trigger,
> and the "before" would get the same arguments as the normal trigger except
> the assignment would not have happened yet. The tricky bits are:
We already have something vaguely like this: method modifiers!
Modeling multi-phase triggers after method modifiers would decrease
cognitive load.
> - do we make the "before" trigger return a value for us to assign?
No. The return value is discarded.
> - do we make the "before" trigger actually do the assignment?
No. The before trigger is only there to perform additional validation
or to call extra methods.
We could have an "around" trigger which *does* wrap the assignment.
> - what happens if an exception is thrown inside the "before", do we catch
> it?
No. Exceptions are generally outside of the scope of Moose. We only
throw them. :)
Besides, before could be used mostly for exceptions, to do multi-value
validation.
> - how would you/should you be able to -- indicate failure or some kind in
> before?
Throw an error. This is what we do and expect practically everywhere
else, right?
Shawn
MooseX::AttributeHelpers 0.11
Hi again,
(Sorry, forgot to include this in the previous mail!)
MooseX::AttributeHelpers 0.11 has a great new features, thanks to
Jason May. You can easily curry in arguments for the created methods.
Here's a simplistic example.
package Class;
has 'foo' => (
metaclass => 'Number',
is => 'rw',
curries => {
set => {
zero_foo => [ 0 ],
one_foo => [ 1 ],
},
mul => {
double_foo => [ 2 ],
triple_foo => [ 3 ],
},
div => {
oh_shit => [ 0 ],
},
},
);
Class->zero_foo; # start at 0
Class->one_foo; # set to 1
Class->triple_foo; # set to 3
Class->triple_foo; # set to 9
Class->halve_foo; # set to 4.5
Class->oh_shit; # explodes because 4.5 / 0 is an error :)
It's pretty nifty! Especially because you can now have multiple
curried methods of one type (see how I have two methods for "set" and
"mul").
Shawn M Moore
__END__
0.11 Thurs. Jun 26, 2008
- add the ability to curry method providers (thanks to jasonmay)
- Counter: add set and allow inc and dec to accept args
- add Bool as an attribute helper (thanks to jasonmay)
- bump all modules to version 0.11 for consistency (sartak)
Moose 0.51
Hi gang,
I uploaded Moose 0.51 to CPAN last night. (I didn't upload a new
Class::MOP because there were only very minor tweaks)
There's a new feature, BUILDARGS. It lets you munge whatever is passed
to ->new. You can now accept any kind of parameters you want; you only
need to return a hashref. This is more convenient than wrapping new,
and it also lets Moose inline the constructor when you make_immutable.
nothingmuch came up with the idea and implementation in record time.
You may have noticed a bunch of MooseX releases -- these were because
if you create an inlined constructor (for immutable), you need to
start taking into account BUILDARGS.
There were some other good changes. Keep on Moosin'!
Shawn M Moore
__END__
0.51 Thurs. Jun 26, 2008
* Moose::Role
- add unimport so "no Moose::Role" actually does
something (sartak)
* Moose::Meta::Role::Application::ToRole
- when RoleA did RoleB, and RoleA aliased a method from RoleB in
order to provide its own implementation, that method still got
added to the list of required methods for consumers of
RoleB. Now an aliased method is only added to the list of
required methods if the role doing the aliasing does not
provide its own implementation. See Recipe 11 for an example
of all this. (Dave Rolsky)
- added tests for this
* Moose::Meta::Method::Constructor
- when a single argument that wasn't a hashref was provided to
an immutabilized constructor, the error message was very
unhelpful, as opposed to the non-immutable error. Reported by
dew. (Dave Rolsky)
- added test for this (Dave Rolsky)
* Moose::Meta::Attribute
- added support for meta_attr->does("ShortAlias") (sartak)
- added tests for this (sartak)
- moved the bulk of the `handles` handling to the new
install_delegation method (Stevan)
* Moose::Object
- Added BUILDARGS, a new step in new()
* Moose::Meta::Role::Application::RoleSummation
- fix typos no one ever sees (sartak)
* Moose::Util::TypeConstraints
* Moose::Meta::TypeConstraint
* Moose::Meta::TypeCoercion
- Attempt to work around the ??{ } vs. threads issue
- Some null_constraint optimizations
New Moose 0.50 and Class::MOP 0.60
Moose, Today I uploaded Class::MOP 0.59 and 0.60, and Moose 0.49 and 0.50. PAUSE failed to index some of Class::MOP because of version numbers it made up. Bumping the version and re-uploading didn't fix it. Hopefully it all works out. If not, well, we'll definitely have the new CMOP and Moose on CPAN before YAPC. :) As with the past few releases, this version features decent speedups. Most were ferreted out by stevan. Some of the changes that made us faster: not inlining a destructor if the user doesn't define one, caching the instance metaclasses where possible, using ref over reftype, and improving the API of *_package_symbol so that it can be made faster. Thanks stevan! Moose, Shawn M Moore
Mouse: Moose without the antlers
Hi gang, I just uploaded Mouse 0.01 to CPAN. It's designed to be an API-compatible, fast replacement for Moose. It supports practically all of "has". It has a very light MOP (mostly what I needed to write "has" :)). Perhaps it's best marketed as Class::Accessor::Moose at the moment, but I do intend to provide more Moose goodness in the near future -- method modifiers and roles. What I like best is that if I s/Mouse/Moose/ on the test suite, only 3 out of the 2045 tests fail. Granted, 1700 of those tests are just battering the type constraints. Also, the tests run in 8 CPU seconds with Moose, 2.5 with Mouse. I haven't yet tested Mouse on the Moose test suite, but I expect it wouldn't go so well. :) Have a look, let me know what you think, or what you'd like to see next! Shawn
Re: Constant attributes
On 5/22/08, Bernardo Rechea <[EMAIL PROTECTED]> wrote:
> Chris Prather wrote:
>
> > which can also be written:
> >
> > sub needs_trinket () { 0 }
> > and
> > sub needs_trinket () { 1 }
> >
> > perl optimizes things with empty prototypes that return a constant.
>
>
> That's quite a wonderful bit of arcana. At least for me: I don't use
> prototypes, so I never paid much attention to the prototypes section in the
> camel book.
>
>
> Bernardo
>
Coincidentally, use constant is just a nicer syntax for this. The
relevant line in constant.pm is:
*$full_name = sub () { $scalar };
Hooray Perl. :)
Shawn
Re: Constant attributes
On 5/21/08, Bernardo Rechea <[EMAIL PROTECTED]> wrote: Hi Bernardo, > I wanted a constant attribute, i.e., one that is read-only and not settable > at construction time. Does it have to be a full attribute? It could just be a method that returns a constant. I often have this in my classes: package Parent; use constant needs_trinket => 0; package Child; use constant needs_trinket => 1; Otherwise, if you need a full attribute, you could use: has needs_trinket => ( init_arg => undef, # I think this works... is => 'ro', default => 0, ); > Bernardo Shawn
Re: Run code on object creation after new() and bless?
On 4/3/08, Tod Hagan <[EMAIL PROTECTED]> wrote: > Hi all, > > [...] > > Is there a way to run code following object creation and the blessing of > the object? Or should I give up trying to hide the extra method call and > require calling a method following the creation of the object? Hi Tod, Define a BUILD method for your class, and that will be called with the blessed object, before new returns it. > Thanks. > > Tod Shawn
