I'll try to parse what you've posted:
Basically, about C as Perl you _all_ have it wrong.I don't see how you can plausibly make that assertion given the vagueness of your original post. A few monks parsed roughly the same ideas from your posting, and responded to them in a reasonable fashion.
However, if we've misunderstood what you tried to say, it's likely because you were too broad, not clear, and overly rhetorical.
I use (pointers) a lot in my Perl (by reference) unless you went to school when they misinterpreted value/reference. For another time.Anyone who seriously uses Perl deals with references routinely. I'm pretty sure we all understand the analogue w.r.t C pointers. Perl's references, however, are typed in a manner such that errors are actually evident (irrespective of manipulation).
My original thought about 'until' as being somewhat like a properly wrapped C macro which would say do{...}while(0) is that C doesn't have 'until' and I've seen where it can and should be used. until else is a non-sequitor for the most part.I believe the exact opinion you stated was "haha - they remind me of macros ...". Your detailed explanation notwithstanding, the statement still makes no sense. You've examined the statement-modifier form of until, noticed a slight similarity with respect to the do-while construct in C and extrapolated a relationship that's incomplete and mostly irrelevant.
until else is a non-sequitor for the most part.In what sense? A 'non-sequitor' is a classification of logical error which deals with one point of argument/proof not following logically from its predecessor. I still don't understand what you want to say there. Were you after 'double negative'?
Other C things are;Perl subroutines take a flat list as argument. That's all. Entirely unlike C. Stating that a lexical declaration coupled with destructuring assignment "seems quite clear" doesn't advance your argument at all.sub func { my($hr_h, $ar_l, $this) = @_; # instead of all the shift, shift, shift # seems quite clear my @these; # I'll try to wantarray too. foreach my $i (keys(%$hr_h)) { if($i == $$ar_l[$i] && $hr_h->{$i} == $this) { .... push(@these, $ar_l->[$i]); } } wantarray? @these: \@these; } # not the best of examples but shows 2 ways to talk with # an array pointer and uses (for good) of wantarray as the # return value.
Since Perl's subroutine arguments come packaged in an array, programmers have the freedom to use all available built-in (or other) functions and other constructs which deal with arrays/lists. Some folks like to avoid copying. Others like destructuring assignment. Others still enjoy treating the arguments as a list. Lots of choice: no "best practices" positive correlation to C can be established without discarding lots of elegant code.
I've no idea what you intend to say about wantarray.
Your insistence on using unnecessary parentheses in order to make the code more C-like just results in Perl code that's cluttered and less idiomatic.
I can't figure out where you've advanced an argument that by writing in this style that (allegedly) mirrors C any advantage is incurred w.r.t either of
The fact that its a textarea is bad enough, but come on folks, if code is involved, let's get a bit more indentation-centric. That's not a word, I'm sure. I wouldn't write any real code without tabs and some smarts. Can I help you 'monks'? Indenting is _not_ 'press the space bar'. Nonsense.Oh, the irony.
If you have more questions, especially you 'chromatic', send them on over to here http://www.theworld.com/~morourke/You're unlikely to get many takers (AFAICT, you've only provided an email address). The discussion here is quite robust, if somewhat biased at times. Your website shows no danger of promoting any such quality.
-David
In reply to Re^2: its simpler
by erroneousBollock
in thread its simpler
by MichaelORourke
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |