Re^2: coderefs and (&) prototypes

LanX suggested moving the CB discussion to a more persistent medium, so here we are. My objection to the above answer (at which the @-response was directed) was that writing \&$a no more guarantees that $a is a coderef than just writing $a does. (It maybe indicates more strongly that we think that $a is a coderef, but, if our thoughts about programs were always correct, then we wouldn't need compile-, or even run-, time checking.) We still get a run-time error if $a is not a coderef.

Defining one's own prototype is a great solution, I agree, but doesn't help if (somewhat ironically) I'm trying to use Scalar::Util::set_prototype to set the prototype of a named coderef. :-)

Comment on Re^2: coderefs and (&) prototypes Select or Download Code

Replies are listed 'Best First'.
Re^3: coderefs and (&) prototypes by LanX (Saint) on Jul 27, 2009 at 22:50 UTC
My objection to the above answer (to which the @-response above is directed) is that writing \&$a no more guarantees that $a is a coderef than just writing $a does. Well you're right but from the perspective of the prototyped function it's clearly the goal to get a coderef at that point and nothing else. It delegates the problem to the code-dereferencing in `&$a`. so it's not anymore a problem of the implementation of prototypes but of the implementation of &-dereferencing. And you will agree that it doesn't make sense in a loosely typed language like perl to guarantee that the scalar following & is a coderef! Otherwise it would become in consequence necessarily a typed language! Cheers Rolf UPDATE: To make it clearer "prototyping" is an option to make perl-functions more "strongly typed", and the function assures this "typing" within it's possibilities, it can't look ahead and alter the behaviour of &. And & can't be strongly typed! Hence you see problems only at run-time...	[reply] [d/l]

Replies are listed 'Best First'.

Re^3: coderefs and (&) prototypes
by LanX (Saint) on Jul 27, 2009 at 22:50 UTC

My objection to the above answer (to which the @-response above is directed) is that writing \&$a no more guarantees that $a is a coderef than just writing $a does.

Well you're right but from the perspective of the prototyped function it's clearly the goal to get a coderef at that point and nothing else.

It delegates the problem to the code-dereferencing in &$a.

so it's not anymore a problem of the implementation of prototypes but of the implementation of &-dereferencing.

And you will agree that it doesn't make sense in a loosely typed language like perl to guarantee that the scalar following & is a coderef!

Otherwise it would become in consequence necessarily a typed language!

Cheers Rolf

UPDATE: To make it clearer "prototyping" is an option to make perl-functions more "strongly typed", and the function assures this "typing" within it's possibilities, it can't look ahead and alter the behaviour of &. And & can't be strongly typed!

Hence you see problems only at run-time...

[reply]
[d/l]