In article <ER32d.2786$Qv5.1325 / newssvr33.news.prodigy.com>,
ChrisO  <ceo / nospam.on.net> wrote:
>Phil Tomson wrote:
>
>> In article <8x%1d.2604$Qv5.529 / newssvr33.news.prodigy.com>,
>> Chris  <ceo / nospan.on.net> wrote:
>> 
>>>(4) Each language has it's own strengths.  IMO one of Perl's strengths 
>>>is the simplicity and consistency of it's parameter passing:
>>>
>>>sub shell {
>>>
>>>   my @output;
>>>   for (@_) { push @output, `$_` }
>>>   chomp( @output );
>>>   return wantarray ? @output : \@output;
>>>
>>>}
>>>
>> 
>> 
>> Actually, I think this is one of the _worst_ things about Perl and it was 
>> one of those nagging little annoyances that when added up finally led me 
>> to seek out alternatives.  The problem with the way parameters are passed 
>> to subroutines in Perl is that you can't tell from a glance how many 
>> params are supposed to be passed into the subroutine and you have no 
>> information about what the params are.  You've got to look down through 
>> the subroutine code to see if there's a 'shift @_' lurking somewhere in 
>> the code (for the uninitiated, you pass params to Perl subroutines via the 
>> '@_' global list; you have to 'manually' shift the params off of that list 
>> - blech! )
>> 
>
>An incredibly interesting point of view though your justification for it 
>is somewhat understandable.  Pathological mistakes can occur this way 
>for those that use this, what I would call an incredibly nice feature, 
>in an undisciplined way.  I'm quite disciplined about spiking out my 
>arguments in Perl at the top of a subroutine.  

Did you do this in comments?  In my faint recollections of Perl I seem to 
recall that there was a way to declare the sub with it's params - but most 
people didn't do this (or perhaps my memory is incorrect). 

> I think your dislike 
>perhaps has been fueled by people that write subroutines in a "hackish" 
>sort of way.  (I would imagine "hacking" Ruby is just as possible to 
>accomplish.)
>


>But aside from the undisciplined uses you've pointed out as reason for 
>eshewing this in Perl, I have to wholy stand by the amazing power this 
>feature brings.  It far outweighs the negatives.  It's one of the 
>"genius" things about Perl.  (Always educational, however, to get 
>someone else's opposite point of view, as you have offered.)

Essentially what you're trying to get is to be able to pass in a variable 
number of arguments to a method (err, function in Perlese).  Ruby lets 
you do that like so:

  def foo(*args)

At least in this case you can tell at a glance that foo can take a 
variable number of arguments.

In perl you could have:
  
  sub foo {
    
    for(@_) {... do whatever...}

  }


In the case of Perl, I've got to actually go and read the body of the 
function to know that it can take multiple arguments.  I don't like it.

The other thing I don't like about it is that it means that argument 
handling in Perl is a do-it-yourself project (like OO Perl)


>
>And to bring this Perl discussion back on topic, in line with your 
>dislike of this "feature" in Perl, am I not correct in understanding 
>that in Ruby, one can create methods on the fly in a class?  How is this 
>that much different (conceptually) than unspecified parameters in a Perl 
>subroutine?  

It could present similar problems, however, creating methods on the fly, 
while possible, it's relatively unusual compared to what we're talking 
about in Perl.  Every sub in Perl requires that I read the body of the sub 
to determine what the args are and how many.  I would also contend that 
the 'problem' of creating methods on the fly is not as big because what is 
happening is that you're getting some new feature (a new method) created 
on the fly (or perhaps you're overriding an old one) that you may not be 
aware of - not knowing about a new method won't break anything because 
you probably won't call what you don't know about. ;-)

>How do you know what methods are there (aside from using 
>the inspection methods available to every class [unless I am mistaken in 
>this regard]).

I'll give you a better example for your the point you're trying to make: yield.

In Ruby you can have:


  def foo
    #...
      yield
    #...
  end

Now there is no indication from looking at the method definition line (the 
'def foo' part) that any argument is passed to this method, yet it 
requires that a block be passed to it, like so:

  foo { puts "Boo!" }

So, it's a bit like the problem I'm talking about with Perl, except that 
in practice it's not as bad because usually there is only one yield in a 
method - but it can be an issue.  That's why it's probably better to do:

  def foo(&b)
    #...
    b.call
    #...
  end

Because it provides the reader of the code with a clear indication that 
the method takes a block.  Also, it's usually a good idea if you do use 
yield to also call 'block_given?' prior to yielding.


Phil