On Tue, Jun 05, 2001 at 01:34:35PM -0700, Daniel S. Wilkerson wrote:
> I cannot imagine running an enterprise critical application
As a complete digression, can we please strike the term "enterprise"
from the English lexicon? Completely redundant and drives me up the
wall. Almost as bad as "ecommerce".
> where this has not been checked. You are just hopeing with your
> fingers crossed behind your back that every combination of things
> that will occur during runtime was found during testing.
Just as you're hoping that every problem can be caught by
type-checking. It can't, else there'd be no bugs in Java programs (or
ML programs for that matter). You're just making sure that the right
pegs go into the right holes. What happens after that, who knows?
Your logic could be completely bonkers.
> In runtime checking, there are non-local dynamic things that can happen. You
> can't possibly check them all. Some subtle bug in one part of your program
> messes up some datastructure, which only fails when some other completely
> unrelated thing is run a day later in some other part of your program. For a
> sufficently large program, you can never check all of these combinations.
Type-checking only stops one possible way to corrupt data. There's
lots and lots and lots more ways to screw things up. And
type-checking isn't the only way to defend against it. Assertions do
very well. Unit testing does well, too. All in combination will do
better.
But I don't want this to degrade into an argument over the merits of
type-checking in Perl. I'm for it (well, I'm all for YOU to use it).
Just don't make it out to be a silver-bullet.
> Dynamic inheritance, is that messing with the inheritance tree at runtime?
> I've never found a need for that.
I tend to generate sub-classes on the fly. Very handy when you're
trying to encapsulate sets of business rules or data dictionaries.
Suck in the business rules, spit out a customized subclass with the
rules encased in closures-as-methods. Sure, there's other ways to do
this, but I like this way.
I think we can preserve this sort of thing with strict-typing.
Its also a very simple way to alter the underlying behavior of a whole
class of objects at run-time. Say you've got an object of class Foo.
Foo just defines a public interface, its a virtual class. Foo
inherits from Foo::Implementation1 (yes, this may seem backwards). In
the middle of the program, it suddenly makes more sense to use a
different implementation system-wide. @Foo::ISA = qw(Foo::Implementation2);
There are many other ways to do this, of course, but that's a really
easy way to pull it off.
It will have to go for strict classes. @ISA will have to be locked.
> I think a lot of these features are just bad habits that people may
> use but they don't realize that they don't really need (like computd
> gotos). I've never used that, if I'm understanding you.
You probably didn't learn object-oriented programming from Perl as I
did. It WARPS THE MIND!
> Not sure what a dynamic method call is.
my $meth = "foo";
$obj->$meth(); # $obj->foo();
I'm probably using the wrong terms.
This definately can't work if $obj is of a class which is strongly
typed.
> Symbol table manipulation is for me another "computed goto" something I don't
> think I'll ever want.
Very handy when combined with closures for generating new methods
on-the-fly without resorting to an eval.
*Some::Class::method = sub {
...closure here...
};
This can still work with strong typing if:
1) The class only plays with its own symbol table
2) It does it at compile time.
Anyhow, Perl 6 should have much nicer ways of doing this sort of thing.
> No eval of strings, you mean.
Yes, of course.
> Eval of strings seems like a very local thing that I would rarely
> want to eval large chunks of code in. Perhaps it could throw a
> "type checking failed" exception that you could catch outside the
> eval.
Problem is, ANY eval ANYWHERE in ANY code run by your program or in
any library called blows type-checking out of the water. An eval
could do anything and you can't know what it will do until its run.
If we disallow eval STRING inside the class, and disallow code outside
the class from altering anything in your class, then I think they can
be handled.
> Automatic method generation. Again, never found the need, and you only give
> it up if you want to.
I find it absolutely essential to fighting off boredom and carpal
tunnel syndrome. Who wants to write accessor methods all day?
YMMV.
Of course, the automatic generation can be done as part of the
compile-step, so its still possible to have this and strong typing.
> > I can't imagine ever saying that about any language! Type checking is
> > nice, but its just one class of error-checking. Doesn't do squat for
> > basic logic errors, for example.
>
> "By relieving the brain of all unnecessary work, a good notation sets it free
> to concentrate on more advanced problems, and, in effect, increases the
> mental power of the race."
Funny, there are a few cases where I'd like to have type-checking, but
most of the time I see it as unnecessary work. Then again, my notion
of typing comes from C++, a language devoted to unnecessary work.
I suppose, this is exactly why it will be optional.
--
Michael G. Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
That which stirs me, stirs everything.
-- Squonk Opera, "Spoon"
