Perl Protoypes

[Nene]

Can somebody show me examples of prototypes used in Perl and why they are bad.

Please show me a bad example of protoypes and then show me the correct way of writing. Please use simple examples so that I can copy and paste your examples on my computer and run them my self.

I have read Tom's excellent note on prototypes but it's a little too advanced for me, I need to take baby steps for now, and then I'll go back to Tom's article on prototypes. TIA

usaims

 

[Frank Seitz]

Can somebody show me examples of prototypes used in Perl and why they are bad.

Please show me a bad example of protoypes and then show me the correct way of writing. Please use simple examples so that I can copy and paste your examples on my computer and run them my self.

I have read Tom's excellent note on prototypes but it's a little too advanced for me, I need to take baby steps for now, and then I'll go back to Tom's article on prototypes. TIA

usaims

http://bit.ly/MCuTAy

Regards
Frank
--
Dipl.-Inform. Frank Seitz
Anwendungen für Ihr Internet und Intranet | Web-, Database-, Unix-Development
Tel: +49 (0)176/78243503, Hermann-Rohwedder-Straße 16, D-25462 Rellingen

Blog: http://www.fseitz.de/blog

 

[Nene]

http://bit.ly/MCuTAy

I have that book too and read it, still a little above my head :-(

Can somebody explain to me what this code does? I'm more concerned
what the '$$' does and '$code->()'

# A handy shortcut for building a quick-and-dirty command-line interface

sub subcommand($$) {
my ($expected, $code) = @_;
if ($expected eq $ARGV[0]) {
shift @ARGV;
$code->();
exit;
}
}

 

[Tim Watts]

http://bit.ly/MCuTAy

I have that book too and read it, still a little above my head :-(

Can somebody explain to me what this code does? I'm more concerned
what the '$$' does and '$code->()'

# A handy shortcut for building a quick-and-dirty command-line interface

sub subcommand($$) {
my ($expected, $code) = @_;
if ($expected eq $ARGV[0]) {
shift @ARGV;
$code->();
exit;
}
}

Hi,

sub somesub($$)

means that somesub() is expecting 2 arguments, both scalars - note that
"scalar" includes refereneces to other types as in the example where $code
is reference to a subroutine (aka pointer to function in C).

$code->() calles the subroutine (or code block) whose reference is stored in
$code, in this case it is called with no arguments.

HTH

Tim

 

[Rainer Weikusat]

http://bit.ly/MCuTAy

In theory, that's a valid argument. In practice, however, it is
totally futile because everything said in there applies to the builtin
operators of Perl as well: It is not possible to know how the
arguments given to any operator will be evaluated without knowing the
'signature' of this operator. This problem is - of course - multiplied
when the same is also true for user-defined subroutines but
nevertheless 'by design' part of Perl. The fact that this text isn't
an all-out criticism of this design descision but claims to be about
'subroutine prototypes' makes it somewhat disingenious.

Considering that Perl works the way it does in this respect,
subroutine prototypes have one useful function: They can enable the
compiler to throw an error when a subroutine is called with less
arguments than required. It is up to the person who writes the code to
decide it this is more important than being able to use an @array to
pass arguments. In my opinion, it is.

 

[Rainer Weikusat]

[...]

sub somesub($$)

means that somesub() is expecting 2 arguments, both scalars

It doesn't. That's the exact pitfall Conway wrote about: It means that
somesub takes two arguments and that both will be evaulated in scalar
context.

 

[Charlton Wilbur]

N> Can somebody show me examples of prototypes used in Perl and why
N> they are bad.

They aren't bad. They are just not what programmers who are familiar
with C and C-like languages think. In C, prototypes are how the
compiler knows how many arguments a function takes and what types they
are. This is essential to C's design. So programmers new to Perl
coming from other languages start out by writing prototypes because they
are necessary in other languages. This is a mistake.

N> Please show me a bad example of protoypes and then
N> show me the correct way of writing. Please use simple examples so
N> that I can copy and paste your examples on my computer and run
N> them my self.

At your level of understanding, I think the best advice is to not use
protoptyes at all and not worry about them until you've got a couple
thousand lines of code underneath your belt.

For instance,

 

[Rainer Weikusat]

The problem with prototypes is that they change the context of the
arguments passed to the function, which is often unexpected. For
instance, if you have a function which expects four arguments, and you
write it

sub foo ($$$$) { ... }

then a call like

my @args = (1, 2, 3, 4);
foo @args;

will not work:

It can be made to work by using &foo(@args).

[...]

There are some circumstances where prototypes are useful. For instance,
Scalar::Util::reftype is prototyped ($); this is extremely useful, since
it means something like

reftype $x eq "HASH"

parses as

reftype($x) eq "HASH"

rather than

reftype($x eq "HASH")

That's the same 'I want to have my cake AND eat it' argumentation as
in the Conway text: Either signature-depdendent context or - even more
user intransparent - signature dependent precedence are a good thing,
then, they are a good thing and users just have to be aware of the
signatures of all subroutines/ operators they are using. Or they are a
bad thing and then, they are a bad thing, regardless of 'subroutine or
builtin' and certainly regardless of any conjectures someone might
have about other people's expections.

 

[Willem]

Rainer Weikusat wrote:
) That's the same 'I want to have my cake AND eat it' argumentation as
) in the Conway text: Either signature-depdendent context or - even more
) user intransparent - signature dependent precedence are a good thing,
) then, they are a good thing and users just have to be aware of the
) signatures of all subroutines/ operators they are using. Or they are a
) bad thing and then, they are a bad thing, regardless of 'subroutine or
) builtin' and certainly regardless of any conjectures someone might
) have about other people's expections.

That's the same black-and white reasoning that inflicted
'everything is an object' java upon the world.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Michael Vilain]

N> Can somebody show me examples of prototypes used in Perl and why
N> they are bad.

They aren't bad. They are just not what programmers who are familiar
with C and C-like languages think. In C, prototypes are how the
compiler knows how many arguments a function takes and what types they
are. This is essential to C's design. So programmers new to Perl
coming from other languages start out by writing prototypes because they
are necessary in other languages. This is a mistake.

N> Please show me a bad example of protoypes and then
N> show me the correct way of writing. Please use simple examples so
N> that I can copy and paste your examples on my computer and run
N> them my self.

At your level of understanding, I think the best advice is to not use
protoptyes at all and not worry about them until you've got a couple
thousand lines of code underneath your belt.

For instance,[/QUOTE]

I came from FORTRAN some 35 years ago where the compiler did multiple
passes to ensure that a subroutine declared with 3 arguments got 3
arguments when it was called. I've always felt that Pascal was upside
down in that the subroutines and functions had to be before the main
code block.

In the assembly languages I learned, it was the caller's responsibility
to call a subroutine with the proper arguments on the stack. Or badness
happened.

Maybe declaring a prototype was something that C did to keep from having
to parse the code more than once. That way compile-time errors in the
same file could be flagged. But I've never written a compiler, so what
do I know.

I'm used to a language where the person writing the code is responsible
for doing it right or wrong. I document the hell out of blocks and
subroutines describing each argument and type before any actual code.
phpDocument actually enforces this coding practice. So far, the perl
I've written has been without prototypes but documented up the ying-yang
so that I know what's being passed to what, now and 6 months from now.

 

[Rainer Weikusat]

[...]

In K&R C, prototypes were neither necessary nor permitted, because it
only ran on machines where all data types were the same length.

This is not true: Even the earliest versions of C had 'char' which was
a byte and int/ pointers which were a (16-bit) word. C also existed on
32-bit systems way before it became standardized.

They were added to ANSI C when C was ported to other machines, where
(say) int and long might be different lengths, and passing a 16bit
int in place of a 32bit long would make a horrible mess of the
stack.

The way this worked was that 'int' was considered to be 'the universal
type' and all integers smaller than that were promoted to int when
being passed as an argument (similarly, double was supposed to be 'the
universal floating-point type'). Arguments for which these rules were
not sufficient had to be casted to the type expected by the called
routines as part of the call.

 

[Charlton Wilbur]

W> That's the same black-and white reasoning that inflicted
W> 'everything is an object' java upon the world.

Except that one of the failures of Java is that everything *isn't* an
object. Look to Ruby or Python or Smalltalk for "everything is an
object" done correctly.

Charlton

 

[Randal L. Schwartz]

Charlton> Except that one of the failures of Java is that everything *isn't* an
Charlton> object. Look to Ruby or Python or Smalltalk for "everything is an
Charlton> object" done correctly.

Smalltalk, yes. Ruby or Python, no.

Unless you're asserting that the presence of sealed "system" classes
does not distract from the notion of object-ness. I believe it does.

If you can't subclass it, or extend it in place, it's not a user class.
And if it's not a user class, its instances are not user instances, but
rather system instances with a second-class (heh) status.

In particular, as I recall, you can't subclass "String" in Ruby,
although you can add methods to it. Python won't even let you add
methods to the String class.

But in Smalltalk, all such things are possible. Not necessarily smart,
but it's there.

print "Just another Perl hacker,"; # the original