Re: "static" declaration

[Daniel Weinreb <address@hidden>]

>
>
>
>Perl's philosophy is to have sensible defaults; consequently, if you
>try to fetch a hash item (Perl calls associative arrays hashes) that
>doesn't exist, it returns undef (Perl's equivalent to NULL.), and
>undef acts like an empty string or 0 in string and numeric contexts.
>(Although it gives you a warning.)
>
What's so reasonable about that?  If you misspell the name of a key, 
fetch the value associated
with that key, and print it, Perl doesn't give you any hint that 
something went wrong.  The end
user could easily walk away from looking at the program output, thinking 
that the computer
had computed that assertion X is true, whereas in fact the whole thing 
might be based on
a misspelling that was never caught.  That seems like a great formula 
for unreliable
code and surprising failures in the field.

>
>
>Python's philosophy is to refuse to guess in the face of ambiguity;
>
I would say that continuing to run the program after a hash lookup 
failed (and there wasn't
anything anywhere to say that such failure was really OK) constitutes 
guessing in the face
of ambiguity!

>It seems that knowing the complete set of instance variables is, by
>itself, rather uninteresting.  
>
>
>But if that's what you want, perl -lne 'print $2 while
>/\$(this|self)->\{(.*?)}/g' | sort -u does a pretty good job as long
>as the code you're looking at follows normal Perl conventions (and
>doesn't generate Perl modules).
>
Gee, I wonder which conventions, exactly, you mean when you say "normal 
Perl conventions".
Certainly the Perl expression above is depending very cruciallly on 
certain conventions.
In my experience, even in a fairly discimplied and experienced 
programming team, you
can't expect the conventions to always, rigorously be followed.  So if I 
am looking
at a Perl caller-callee cross-reference and see that there are only two 
callers of a certain
subroutime, and I refactor the subroutine based on what I learned from 
those two callers,
I might very easily screw it up.  I don't think there are universal Perl 
conventions and I'm
skeptical that the "yes, there's no design, so there" Perl culture are a 
good breeing
ground for well-documented languages suitable for writing enterprise 
code that will
live over ten years and have more than 30 people maintaining it over time;

>
>
>With regard to Dan's original problem, by the way, I usually determine
>whether a Perl function is intended to be a class method or an object
>method by whether its first parameter is called "$class" or "$this" or
>"$self"; it's slightly less visually clear than "static", and it's
>only a convention, but it works pretty well most of the time.
>
Yeah, well, guess what, the Perl programmers who wrote the code that I 
am now reading
did *not* happen to follow that set of conventions.  This is why 
"conventions" is a rather
poor reply to what I said a few days ago.

-- Dan

>