Hi Gaal, On Wednesday 09 Feb 2011 17:20:28 Gaal Yahas wrote: > On Tue, Feb 8, 2011 at 12:48 PM, Shlomi Fish <[email protected]> wrote: > > Hi Gaal, > > > > On Tuesday 08 Feb 2011 12:19:01 Gaal Yahas wrote: > >> I suppose you can use a functional idiom to encapsulate this. > >> > >> # not tested > >> sub with_path($&) { > >> my($new_path, $code) = @_; > >> local $ENV{PATH} = $new_path; > >> $code->(); > >> } > >> > >> { > >> # ... > >> with_path((join $path_sep, $ENV{PATH}, $some_dir), { > >> # Code to run with modified path > >> }); > >> } > > > > My problem with my two snippets was not in the call to local, but with > > the fact that $ENV{PATH} is mentioned twice there, which is also the > > case in your snippet (which is also kidna wordy and cluttered, at least > > if done only once.). > > I don't know that this is avoidable. local localizes its argument, so > local ($ENV{PATH} . ...) won't work. Since the new value depends on > the old one there are two distinct places where you have to refer to > the variable.
Yes, it may be unavoidable. Though I recall reading something about a related enhancement to the local keyword in the case of package-scope variables in perl5120delta or perl5100delta . > > As for clutter, that's in the eye of the beholder. If the callsite > syntax becomes clearer in your opinion, putting the ugliness in a > well-named function can be worth it. Right. What Mikhael suggested seems to yield a somewhat cleaner calling syntax, but at the expense of a counter-intuitive (IMO, at least) order of arguments. > > > The general paradigm you are describing can still be considered a valid > > approach, and I've seen it used in several CPAN APIs such as DBIx-Class > > and KiokuDB . But see what I wrote about it here: > > > > http://community.livejournal.com/shlomif_tech/49156.html > > Not sure how general your case is as a counterexample. What you can > close on and the side effects of the closure greatly determine the > usefulness of this style of programming. Well, I didn't say such use of closures was always wrong. closures have many legitimate uses like that as arguments to methods or functions. It's just that I felt in my case it was an abstraction that made things worse - an anti- abstraction if you may. > > You need rw params, and I think using $_[0] would have gotten you them. > Well, I prefer not to use $_[0] because of: http://perl-begin.org/tutorials/bad-elements/#subroutine-arguments Though it may be manageable here. read/write params are also a violation of immutability (see Yuval Kogman's recent TelAviv.pm presentation about it) and they are not exactly what I expect to have in a Perl subroutine (and may be dangerous in this case). I prefer that if I wish to modify the value of a variable I'll spell it by passing it as a reference, which is also safer as "my $var = shift;" and "my ($var1, $var2) = @_;" are not aliases. > The extra length is partly a result of your style preferences (you > didn't HAVE to have a blank line between params and body). Apart from > the first issue -- what localization operates on -- these are > syntactic matters. Possibly true, but I still feel that even with everything condensed it would still add clutter. > FWIW Perl 6 makes them nicer. > I guess it does. In Ruby, blocks can also accept an arbitrary list of named arguments, which makes using this pattern somewhat nicer: [ruby] _with_curr_line do |line| # Do something with line. end [/ruby] (Untested). I think in Perl 6 the -> operator serves a similar purpose. I still think that if we repeat this method-accepting-a-closure-as-an-argument pattern too much it becomes duplicate code, and ideally should be abstracted into a Lisp-like macro or something. And then we have the KISS (Keep it Simple Stupid) vs. DRY (Don't Repeat Yourself) dichotomy all over again: http://tech.groups.yahoo.com/group/hackers-il/message/5094 Misery. Regards, Shlomi Fish > > Regards, > > > > Shlomi Fish > > > > -- > > ----------------------------------------------------------------- > > Shlomi Fish http://www.shlomifish.org/ > > "The Human Hacking Field Guide" - http://shlom.in/hhfg > > > > Chuck Norris can make the statement "This statement is false" a true one. > > > > Please reply to list if it's a mailing list post - http://shlom.in/reply > > . _______________________________________________ > > Perl mailing list > > [email protected] > > http://mail.perl.org.il/mailman/listinfo/perl -- ----------------------------------------------------------------- Shlomi Fish http://www.shlomifish.org/ UNIX Fortune Cookies - http://www.shlomifish.org/humour/fortunes/ Chuck Norris can make the statement "This statement is false" a true one. Please reply to list if it's a mailing list post - http://shlom.in/reply . _______________________________________________ Perl mailing list [email protected] http://mail.perl.org.il/mailman/listinfo/perl
