[accidentally first sent to Shlomi only] On Wed, Feb 9, 2011 at 7:43 PM, Shlomi Fish <[email protected]> wrote: > > 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.
*shrug* > > > > > 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. If your case was different, maybe it didn't belong as an example here :-) > > 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 I dislike $_[n] myself, for different reasons. I don't think it's inappropriate here. The argument made there is that positional arguments don't scale because you need to maintain the indexes explicitly. This doesn't pertain to our case because the function is trivial and has only one parameter. Indeed, these are the kinds of cases where unscalable syntax is a a kind of an advantage, because if you ever find yourself tempted to add features to the code at hand, the syntax reminds you to leave the design as is or refactor more thoroughly. For better or worse (worse mostly) Perl does not have formal routine parameters and ALL access to arguments is essentially positional and fragile, even if you don't refer to explicit indexes. "$x = shift" is an awful construct, and personally, I only use it when I want to separate the invocant out in OOP code so I can then reuse @_ to delegate to some other method. > 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. References are a "violation of immutability" as much as aliases. They're just clearer to see at the call site. I missed Yuval's talk, but I do believe he was advising against mutability in design at large, where objects carry a lot of state. Embedding substitutions that consume parse input inside helper functions (or having them anywhere, really) is a violation of that idea whatever the mechanism you use to mutate state. The result in a parser, for example, is that it's harder to backtrack and attempt a different parse using composite parsers. Elsewhere it can be that serialization is trickier than for immutable data. On occasion it's performance, or ease of distribution across machines, ease of reasoning about computation, or whatever. > > 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. I'm not arguing about taste. If you don't like it, TMTOWTDI :-) > > 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. Right. (<-> makes the param rw.) > 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 . -- Gaal Yahas <[email protected]> http://gaal.livejournal.com/ -- Gaal Yahas <[email protected]> http://gaal.livejournal.com/ _______________________________________________ Perl mailing list [email protected] http://mail.perl.org.il/mailman/listinfo/perl
