Re: Dynamic Typing, Defencive Programming and Prototypes (Was: Interfaces and Type Safety)

Tassilo v. Parseval wrote:

defencive programming:
> So PHP is offensive. ;-)
Yup, at least V4 is <smile>. But as to defencive programming in Perl, I've
found these two lines invaluable:

use strict;
use warnings FATAL => qw|all|;

Writing code with speech it is far too easy to accidentally mistype an
identifier and try introducing a new variable in the middle of a
print-statement or something. And as to making warnings die, it prevents you
from fixing things lazily and catches subtle initialization bugs, very nice.
Another benefit is knowing as soon as something goes wrong. As the screen
reader's focus can be in one GUI widget at a time and the console app I'm
doing runs in the background, dying quickly, forces me to actually notice
the warnings. It would be even better if I could be warned audibly by
emiting the bell char \a to the console when-ever this does happen. However,
I reckon that's a no-can-do in Win32 as signals aren't implemented and END
blocks not run when you die. Perhaps using eval, then.

benefits of dynamic typing:
> Consider a module that is used to write XML tags as generically as
> possible. <snip> <snip> all you need is one special
> method to handle it all. <snip> generate and compile
> the requested method on the fly:
I see, your auto load example is pretty impressive. Still, as they say
there's more than one way to do it, wouldn't it be easier foor the caller if
there was one createTag method whose first argument was the name of the tag.
No auto-load or pollution of the callers namespace needed. But then again
the other benefits you mentioned will be lost and you don't necessarily have
to export the methods.

ah, I think I now know another example of auto loading. The Win32::OLE
module that I'm using a lot enables you to load in an OLE type library and
after that the constructed object will magically have method and property
names corresponding to those of the type library. And calling non-existant
methods dies cleanly, too. I was really awed when I saw this. I cannot think
of a way to achieve the same thing in Java, for instance, even if you could
use reflection and polymorphism. Sure you might be able to have some
dispatcher method whose first argument is the property or method being
operated on, as in the previous example, but that doesn't look as smooth as
in Perl. Finally, I'm greatful that Perl programmers generally don't do as
much operator over-loading as C++-programmers, because it can be very
confusing if overused.

Prototypes:
> Perl does have forward-declarations as well. The case above works if the
> function definitions comes before the code that calls this function.
I just tried your example and noticed the same thing on my own yesterday.
Argh as in C again, I like the Java method where the compiler doesn't force
you to type in the same thing twice for no obvious reasons: I mean obvious
from the programmer convenience point of view.

Anyway, what's the canonical way of including these protos? If I stick all
of them at the beginning of the file, it is confusing for people reading it
the first time. But then again I haven't seen people using C-like include
files for definitions, either, and am unsure as to what extension such files
should have. ph comes to mind standing for perl header.

If I want to be truely lazy, is there a way of automatically copying the
prototype from the implementation and placing it before the function is
being used? I hope someone else has already done something like this and
will search using PPM. Source filtering comes to mind as the first choice.

--
With kind regards Veli-Pekka Tätilä (vtatila@xxxxxxxxxxxxxxxxxxxx)
Accessibility, game music, synthesizers and programming:
http://www.student.oulu.fi/~vtatila/


.

Relevant Pages