RE: Re (tilly) 1: passing and processing code references

Replies are listed 'Best First'.
RE (tilly) 3: passing and processing code references by tilly (Archbishop) on Oct 11, 2000 at 17:53 UTC
Several things are wrong wth a Perl block done that way. First of all read FMTEYWTK About Prototypes In Perl. Everything in there about prototypes applies. I don't like them, and don't like them for a reason. Secondly you now have order of declaration issues. If the prototype is not declared before the code that you use, then it works one way. If it is then it works another. Thirdly what happens later when you want to modularize, move code elsewhere and import with Exporter? If you move code from one package to another, then code that had worked through setting a global will break because the global is in the wrong ~~block~~package (minor fix, sorry). Do you have a guru on staff? Because most people are unlikely to look at that problem and know to check caller and mess with globals in your caller's namespace. (And games like that quickly leads to messes.) Oh, but you tested with $_ (which you didn't localize I note) which is always in package main. So your tests wouldn't pick that up. The moral? Don't use special variable names for testing scoping issues! Fourth Tom C mentioned bugs with the & prototype. What kind of bugs you ask? Well there is a deep problem with braces being overloaded. They can be interpreted as a block to be turned into an anon sub, a block to execute inline, or an attempt to produce an anonymous hash. Mix this with disambiguating core functions from user functions and you get quite a mess of potential ambiguities to parse! Yes, I know that some core functions do this already. But the list of ones that do is small, and there is no ambiguity between them being core and user. Like globals, special behaviour is OK in controlled amounts but should not be used throughout your design at risk of insanity. Now all of this is what you lose, what do you gain? Being able to omit 4 characters. Just type "`sub` " in front of your block and it works without prototypes. Without parsing ambiguity. Without declaration issues. OK, so if you use globals then you are still in trouble, but an ever-expanding web of globals to keep track of is a sign of a poorly thought through design.	[reply]

Replies are listed 'Best First'.

RE (tilly) 3: passing and processing code references
by tilly (Archbishop) on Oct 11, 2000 at 17:53 UTC

First of all read FMTEYWTK About Prototypes In Perl. Everything in there about prototypes applies. I don't like them, and don't like them for a reason.

Secondly you now have order of declaration issues. If the prototype is not declared before the code that you use, then it works one way. If it is then it works another.

Thirdly what happens later when you want to modularize, move code elsewhere and import with Exporter? If you move code from one package to another, then code that had worked through setting a global will break because the global is in the wrong ~~block~~package (minor fix, sorry). Do you have a guru on staff? Because most people are unlikely to look at that problem and know to check caller and mess with globals in your caller's namespace. (And games like that quickly leads to messes.) Oh, but you tested with $_ (which you didn't localize I note) which is always in package main. So your tests wouldn't pick that up. The moral? Don't use special variable names for testing scoping issues!

Fourth Tom C mentioned bugs with the & prototype. What kind of bugs you ask? Well there is a deep problem with braces being overloaded. They can be interpreted as a block to be turned into an anon sub, a block to execute inline, or an attempt to produce an anonymous hash. Mix this with disambiguating core functions from user functions and you get quite a mess of potential ambiguities to parse! Yes, I know that some core functions do this already. But the list of ones that do is small, and there is no ambiguity between them being core and user. Like globals, special behaviour is OK in controlled amounts but should not be used throughout your design at risk of insanity.

Now all of this is what you lose, what do you gain?

Being able to omit 4 characters. Just type "sub " in front of your block and it works without prototypes. Without parsing ambiguity. Without declaration issues. OK, so if you use globals then you are still in trouble, but an ever-expanding web of globals to keep track of is a sign of a poorly thought through design.

[reply]