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.
