«

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

Nene wrote:
> 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

On Thursday, June 14, 2012 4:25:48 AM UTC-4, Frank Seitz wrote:
> Nene wrote:
> > 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

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;
}
}




>
> 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 wrote:

> On Thursday, June 14, 2012 4:25:48 AM UTC-4, Frank Seitz wrote:
>> Nene wrote:
>> > 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
>
> 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

--
Tim Watts

Frank Seitz <> writes:
> Nene wrote:
>> 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

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.

Tim Watts <tw+> writes:

[...]

> 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.

>>>>> "N" == Nene <> writes:

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,



--
Charlton Wilbur

Ben Morrow <> writes:
> Quoth 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.
>
> 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.

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

In article <>,
Charlton Wilbur <> wrote:

> >>>>> "N" == Nene <> writes:
>
> 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,

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.

--
DeeDee, don't press that button! DeeDee! NO! Dee...
[I filter all Goggle Groups posts, so any reply may be automatically ignored]