On 09/30/2010 02:35 PM, Hans Dieter Pearcey wrote:
We don't like the fact that lazy_build autogenerates public clear_$attr and has_$attr methods for you. OK, I can get behind that; those often don't belong as part of the "public" API, and yes, people will consider them public if they don't have a leading underscore, even if they aren't documented.Thing is, having the "_build_$attr" convention is very, very useful -- I've seen people get really confused when they try to provide their own builder, similar to how people are confused by writer. For some reason when people have to specify 'builder => "build_my_foo"', they get super confused. Also, they tend to name each of them differently, which breaks the really handy clue of "this has no state, it just returns a value" that you get from _build_foo. Anyway, we were kicking around ideas for how to get rid of these clearers and predicates in #moose-dev. I suggested 3 things: 1) reuse 'builder', i.e. 'builder => 1' is special cased to be the same as 'builder => "_build_$attr"' Someone said "what about subs named '1'?" but I think we're probably all OK with ignoring anyone crazy enough to do that. 2) make a new option 'build => 1', which is like 'lazy_build => 1' but without the 'lazy_', and also without the clearer and predicate. Downside for both 1& 2: a bunch of people who aren't using clearer or predicate have to change their code for basically no reason. 3) make the clearers and predicates generated by lazy_build issue deprecation warnings the first time they're called that suggest specifying a clearer and/or predicate, and ship a Moose::Deprecated::LazyBuildPublicMethods (or whatever) to shut them up. Upside: people who aren't affected don't have to care, people who are affected have a simple solution ("just add 'use Moose::Deprecated::blahblah' to your class"). Also, we never have to actually remove the clearers/predicates and risk breaking people's code if we don't want to. Obviously I've been leaning more and more towards #3 as I write this, but I'm curious what the rest of you think. hdp.
The first few times I used moose, I intuitively did "builder => 1" to mean "expect a builder called _build_$attribute". For no good reason it didn't ever occur to me I'd want a builder that was named differently (obscurely?). I realize the "having to change your code for no good reason" isn't awesome, but it *would* make their code more readily accessible to declare those explicitly.
To me, option 1 feels more like the "clean" way to implement, if it were being implemented from scratch; so I favor that =)
-Sir
