I don't measure hard by keystrokes. That's not irrelevant, but there are more important things than keystrokes. Don't take this the wrong way, I'm not advocating Cobol or Java here, but there are much bigger deals than keystrokes.
Now, I also realise you're probably just playing with a bit of sarcasm, so I just want to point out where traditional new wins out. Maintainability. Every perl programmer expects to create new objects through new. That's why we have that convention - we stole it from other languages. It made things really easy. There was nothing inherent in perl that says it must be new, we just do it by convention. And, as I said before, it's not even technically correct, it's only loosely analogous, since perl's constructors, whether called new or something else, are more factory like (since it's actually bless doing the work, technically, not new, and we actually call that in our constructors, unlike every other language where the object reference is created for you prior to the constructor being called, which makes this much more like an object factory in other languages). However, regardless of the mechanics, it's still the convention.
This means that the learning curve to other objects that also use new as their factory is that much less. It means that code that just calls new and expects an object back Just Works. Following convention means it's easier for everyone.
That you do something weird under the covers inside your own "private" classes, types that aren't intended to be instantiated directly, but through other factories that are more traditional in their factoriness (yes, that is now a word), doesn't matter quite so much. Though even there, I would still encourage following convention as much as possible for the guy who gets to follow you in maintaining that package (having inherited a couple of modules over time, I always appreciate when there is little to learn about its innards because most of it matches general perl convention).
And, in your specific example, which I also understand is a very tiny bit of a significant ecosystem providing some DSL to provide a lot of functionality, I would point out, what does that keystroke save? Because I'm gonna have to look it up each time to know which non-standard constructor to use. The problem here, at least from my perspective, is unnecessary mental load. And by unnecessary, I mean that it doesn't seem to provide any benefit over the standard convention, which makes it more to remember, even if convention is that one extra keystroke longer. I already have to remember all the new ways of doing things in the rest of your ecosystem, but those, at least at first glance, look to provide functionality and thus value - bringing down a lot of boilerplate that I might otherwise skip and thus not check things that I can use your system to handle for little cost. So learning and remembering that stuff seems to be likely to be a worthwhile addition to my knowledgebase. (I'm assuming - I haven't looked that closely, and so I am only going on the quality of code I've seen from you in the past. I don't know you for generally writing Acme-style or -quality code.) But that new constructor style... well, perl definitely allows it. I'm just not seeing the benefit.
But maybe that's just me. Most of my professional life has been more about maintenance than writing new code, and so that's just what I see.
In reply to Re^4: Override new in Moose for flyweight objects
by Tanktalus
in thread Override new in Moose for flyweight objects
by Aaronrp
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |