Re: virtual attributes (was Re: A branch to review: topic/strict-constructor)
On Mar 4, 2010, at 5:55 PM, Karen Etheridge wrote: On Wed, Mar 03, 2010 at 12:52:56PM -0800, Darren Duncan wrote: Now, perhaps a bigger question that one might ask, is why wouldn't Moose use MooseX::StrictConstructor's semantics by default? The main reason I can think of for the current behavior is that you may want objects to have constructor parameters that don't correspond to attributes, and you would be using BUILD to map them. I've wondered this myself. I don't want arbitrary fields springing into existence in my object, They won't, Moose will *not* add any slots to you object instance other then the ones you define as attributes. The extra params are not added to the instance, they are simply passed in the $params HASH to BUILD only. - Stevan
Re: A branch to review: topic/strict-constructor
I have to agree with the above assessment. Tying 'strict' and 'immutability' doesn't make sense. They are orthogonal concepts. And, I am not a fan of Moose::Strict either. Yet another packages to remember, separate documentation. If you fork into use Moose and use Moose::Strict, someone will come along and create MX::UserProof, unaware of Moose::Strict. 'use Moose -strict' is sweet. It puts the right functionality in the right place. Just my thoughts, Chris Christopher Brown On Tue, Mar 2, 2010 at 11:52 PM, Goro Fuji g.psy...@gmail.com wrote: hdp: Strict constructors, on the other hand, can work unchanged regardless of the metaclass's mutability or lack thereof. Well, what you said is reasonable. make_immutable(strict_constructor = 1) is not a good interface. Internally, $pkg-meta-strict(1) is the best, but it requires too much typing, so I need a sweet interface. use Moose::Strict seems good, but use Moose -strict seems more sweet, I think. -- Goro Fuji (藤 吾郎)
Re: A branch to review: topic/strict-constructor
hdp: Strict constructors, on the other hand, can work unchanged regardless of the metaclass's mutability or lack thereof. Well, what you said is reasonable. make_immutable(strict_constructor = 1) is not a good interface. Internally, $pkg-meta-strict(1) is the best, but it requires too much typing, so I need a sweet interface. use Moose::Strict seems good, but use Moose -strict seems more sweet, I think. -- Goro Fuji (藤 吾郎)
Re: A branch to review: topic/strict-constructor
http://github.com/gfx/moose/commits/topic/strict-constructor2 I have implemented use Moose -strict command. How about it? -- Goro Fuji (藤 吾郎)
Re: A branch to review: topic/strict-constructor
On Sun, 28 Feb 2010, Goro Fuji wrote: http://github.com/gfx/moose/commits/topic/strict-constructor2 I have implemented use Moose -strict command. How about it? I really wish you'd use the Moose repo like everyone else. It makes it a lot easier for me to review your code that way, and probably for others who aren't too git-savvy. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: A branch to review: topic/strict-constructor
On Sun, Feb 28, 2010 at 15:21, Dave Rolsky auta...@urth.org wrote: On Sun, 28 Feb 2010, Goro Fuji wrote: http://github.com/gfx/moose/commits/topic/strict-constructor2 I have implemented use Moose -strict command. How about it? I really wish you'd use the Moose repo like everyone else. It makes it a lot easier for me to review your code that way, and probably for others who aren't too git-savvy. You may already know this but here's how you review changes from a remote repository: $ git remote add gfx git://github.com/gfx/moose.git $ git fetch $ git fetch gfx $ git branch -l -a | grep strict-constructor2 remotes/gfx/topic/strict-constructor2 $ git checkout -b gfx-topic-strict-constructor2 remotes/gfx/topic/strict-constructor2 $ git diff master.. Once you've added a remote getting changes is just a matter of another `git fetch` command.
RE: A branch to review: topic/strict-constructor
Hello, Use Moose -strict looks very unusual. Why not something more usual for Perl like use Moose::Strict? -Original Message- From: Goro Fuji [mailto:g.psy...@gmail.com] Sent: Sunday, February 28, 2010 10:47 AM To: Dave Rolsky; Moose ML Subject: Re: A branch to review: topic/strict-constructor http://github.com/gfx/moose/commits/topic/strict-constructor2 I have implemented use Moose -strict command. How about it? -- Goro Fuji (藤 吾郎)
Re: A branch to review: topic/strict-constructor
Dave: I really wish you'd use the Moose repo like everyone else. It makes it a lot easier for me to review your code that way, and probably for others who aren't too git-savvy. Oh, sorry. I forked it from force of habit. Well, let's get back to the subject. Although I implemented the '-strict' option, I don't like it as Alexander does. Rather, I prefer make_immutable(strict_construcotr = 1). Dave said that constructor strictness should not be tied to immutability, but I don't think so. This is because existing options to make_immutable, namely constructor_name and inline_construcotr, etc., are irrelevant to immutability. The fact that those existing options are passed to make_immutable is not logically reasonable. 'strict_constructor' may be irrelevant to immutability, but there is no reason not to be tied to make_immutable. -- Goro Fuji (藤 吾郎)
Re: A branch to review: topic/strict-constructor
Excerpts from Goro Fuji's message of Sun Feb 28 21:09:29 -0500 2010: Dave said that constructor strictness should not be tied to immutability, but I don't think so. This is because existing options to make_immutable, namely constructor_name and inline_construcotr, etc., are irrelevant to immutability. You can't inline the constructor (or anything else) before the metaclass is immutable or future changes to the MOP won't be reflected in the inlined stuff. Even if you want to argue that inlining a constructor can/should be separated from make_immutable, there's still a clear dependency between inlining (including the decision whether or not to do it) and immutability. Strict constructors, on the other hand, can work unchanged regardless of the metaclass's mutability or lack thereof. I have to side with Dave on this one. hdp.
Re: A branch to review: topic/strict-constructor
On Mon, Mar 1, 2010 at 02:35, Hans Dieter Pearcey h...@pobox.com wrote: I have to side with Dave on this one. Yeah on one hand the -import() namespace is being polluted and on the other hand meta-make_immutable() is being used to do something not relating to immutability. If it's going to be added to core why not use Moose::Strict as suggested above or simply add another thing to meta to do e.g. C $pkg-meta-set_attributes( strict = 1 ) ?
Re: A branch to review: topic/strict-constructor
On Sat, 27 Feb 2010, Goro Fuji wrote: I really don't think this feature should be tied into immutability. The existing MX module works regardless of whether or not the class is made immutable. What interface do you like? I'm not really sure. I just know that this shouldn't be tied to immutability. I don't stick with the interface, but I'd like to avoid to break compatibility, which other interfaces like use Moose -strict or new sugary functions might result in. Would use Moose -strict actually break back-compat? It seems like it should work fine. We'd just have to change Moose::Exporter to allow an arbitrary list of flags the import method wants to see. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: A branch to review: topic/strict-constructor
On Fri, 26 Feb 2010, Goro Fuji wrote: The strict constructor is enabled by the 'strict_constructor' option of make_immutable: __PACKAGE__-meta-make_immutable(strict_constructor = 1); I really don't think this feature should be tied into immutability. The existing MX module works regardless of whether or not the class is made immutable. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
