On Sep 30, 2010, at 2:35 PM, Hans Dieter Pearcey <h...@pobox.com> 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.


I am probably an odd man out in that I often want a public clearer and
predicate method, or at least I don't mind that one is created for me.
I happily however will embrace option three if the
"Moose::Deprecated::LazyBuildPublicMethods" is a Trait and not in the
Deprecated namespace.

-Chris

Reply via email to