Dave, Thanks for the reply. As always I greatly value criticism; and yours is particularly cogent. Please see my responses below.
On Wed, Dec 17, 2008 at 5:47 AM, Dave Rolsky <auta...@urth.org> wrote: > > On Wed, 17 Dec 2008, Christopher Brown wrote: > >> There are several advantages for prototype mechanism: >> 1. Favors reusable attributes that allows for customization ( the goal ). >> 2. Clean, readable code. Attributes are specified as attributes have always >> been specified: >> has 'attribute' => ( ... ); ( a requirement? ) >> 2a. Easier to debug >> 2b. Less code > > I'm really not so sure about 2a. This seems like it could be just too much > abstraction, and could get really confusing. > '2a. Easier to debug' was as opposed to the situation where you have abstracted your attributes into a role. When you have abstracted attributes into roles and want to examine class attributes it is not clear where to look, in the class or in the role. Which role? The prototype suggestion would make finding attribute definitions easier. Thus easier to debug. I think the general case also true. Who doesn't want a set of attributes that come with tests a la Test::Moore. If the developer reasonably knows that all attributes are well vetted, it frees her from writing (some number of) attribute tests. > I'm also not so sure about 2. It's simple code, yes, but you're basically > defining custom Moose-like sugar on the fly with every import, which could > get quite confusing. I struggle with this as well. Thus my question to the list. What I am arguing is that this will be less confusing with the right design. One ( albeit weak ) argument is that Moose is mostly syntactic sugar ( + framework ) that allows easy meta-stuff and aspect-stuff. This is no different, but provides flexibility. Prototypes concept with sensible defaults simplifies things for the end-user just as any CPAN module can. If, however, you meant performance hit rather than confusing. I will concede this point. There is likely to be a performance hit. How much, I cannot say outside of some implementation. > >> 3. By default, the attribute is an attribute out-of-the-box >> 4. Makes it easy for CPAN authors to Moose-ify their modules. ( ancillary >> benefit ) >> 5. Other languages/platform have similar abilities ( competitive ) > > Re #5: really? What languages? Well, the M$ ones for example. In M$ world, I can create a class place a object in a slot and name that slot anything, all with very little specifications. Okay, so this prototypes proposal advocates a bit more, but the affect is the same: easy, sensible defaults, flexibilty, less code. >> Why do I care? Well, I think that 95%+ of attributes are very rote. It >> would be easy to put together a list of 100 attributes . And have 95% of my >> attribute writing done. Of the three things that programs do 1) accept >> input 2) program logic 3) output. This would nearly eliminate the accepting >> of the input. My day-to-day job as a programmer gets 1/3 easier. ( >> Actually .95 * 1/3 easier ) > > The question is whether those 100 attributes are really shareable amongst > different programmers. I suspect that each programmer will want to tweak each > attribute slightly differently, so you end up with 100 prototypes, each of > which has 10 knobs to turn. Sounds confusing to me. This is exactly my point! There are already ( more than ) 10 knobs in attribute specification and set-up. Some are very standard, e.g. is, isa, default, required. Others are not, those that use Metaclass traits, for instance. I am not advocating the removal of those knobs, only a mechanism to set them to sensible defaults. I do concede your point that most developers turn knobs. But in the vast majority of the cases they will turn one, maybe two -- not 10. Why should the developer have to specify 10 every class, when he can specify only the one or two that differ from the default? Moreover, you have probably found yourself in the position I have been in. I have created a Moose based application in which the attribute specifications account for 80% of the code, while 20% is methods/program logic. I don't think that this needs to or should be the case. As an aside, I think that Shawn is solving the same problem with MXRP, at least with one of his use cases. Shawn allows the developer to specify sensible defaults but allow the end-user to provide overriding parameters. Thanks again Dave! Chris
