Re: deprecating (part of) lazy_build
Hans == Hans Dieter Pearcey h...@pobox.com writes: Hans We don't like the fact that lazy_build autogenerates public Hans clear_$attr and has_$attr methods for you. I'm not part of we then. I've used lazy_build everywhere, and I'm perfectly happy that it generates public methods. Just a datapoint. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 mer...@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion
Re: deprecating (part of) lazy_build
On Thu, Sep 30, 2010 at 02:35:13PM -0400, Hans Dieter Pearcey wrote: We don't like the fact that lazy_build autogenerates public clear_$attr and has_$attr methods for you 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. That was me, but I want to make clear that even I am not so crazy to do that :) 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. I like option #3 best, but doing #1 as well might be quite useful too -- I can forsee an outcry what, you mean I need to type out my builder method names? 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. deprecations++. Thanks for writing this up, Hans! -- A: To be or not to be. Q: What is the square-root of four b-squared? . ... . Karen Etheridge, ka...@etheridge.ca GCS C+++$ USL+++$ P+++$ w--- M++ http://etheridge.ca/ PS++ PE-- b++ DI e++ h(-)
Re: deprecating (part of) lazy_build
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
Re: deprecating (part of) lazy_build
On 30.9.2010 22:34, Sir Robert Burbridge wrote: On 09/30/2010 02:35 PM, Hans Dieter Pearcey wrote: 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' 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 =) Hello, I also favour option one. Actually that is what I most of the times do manually as it somehow makes it mentally more clear to me. Even though I never use any other names for builders than _build_$attr. Regards, Jiri
Re: deprecating (part of) lazy_build
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. I made this suggestion, *years* ago (even providing a patch for it iirc). Stevan rejected it because he was uncomfortable with the attribute taking both String, and Bool. It was always his position to have has($_, isa = Str, is = ro, predicate=has_$_) for qw/ foo bar baz/; And the like. Again, I think this is a great idea, but it will never happen. I could even see it going one step further and to make a special token for this. use MooseX::Autoname qw(generate_by_name); has foo = ( isa = Str , is = rw , predicate = generate_by_name , builder = generate_by_name ); Or, something. -- Evan Carroll - m...@evancarroll.com System Lord of the Internets web: http://www.evancarroll.com ph: 281.901.0011
Re: deprecating (part of) lazy_build
On 01/10/2010, at 7:17 AM, Chris Prather wrote: 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. Agreed; I like the current behaviour but will also embrace a shift to a trait. Perhaps I didn't read or understand hdp's mail properly - but I'm not actually clear on why having public clearer and predicates created poses a problem? Tom
