"Daniel S. Wilkerson" <[EMAIL PROTECTED]> writes:
> Michael G Schwern wrote:
> > No subroutine refs. No dynamic inheritance. No autoloading. No
> > dynamic method calls. No symbol table manipulation. No eval. No
> > automatic method generation. (That's off the top of my head).
>
> You don't loose all of these. Java has interfaces, and then any
> class, even loaded at compile time, that satisfies an interface is
> allowed to be used in its place. This is as good as subroutine refs
> (and in general object refs) that are checked at compile time, but
> where the implementation shows up at run time.
Um... how is this as good as a subroutine reference? I confess that I
fail to see it.
You do realise that not having subroutine references kills all sorts
of useful stuff. Apache::Registry springs to mind.
> Dynamic inheritance, is that messing with the inheritance tree at
> runtime? I've never found a need for that. 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.
Dynamic inheritance is definitely scary. Fun, but scary. Using it in
production code would definitely be scary. Then again, having a state
token which you rebless to change the state has some good stuff going
for it...
> Java allows you to load classes at runtime. The interface /
> implementation matching is checked then. No, you can't do many of
> the tricks that you can in Perl, like having autoload implement
> methods for you that don't really exist lexically, etc. Again, this
> would only not be allowed in "strict-type-checking". So, you give it
> up only if you want to.
Hopefully, with strict-type-checking on you'd be able to predeclare
subroutines that are implemented via AUTOLOAD:
sub foo (<signature>);
> Not sure what a dynamic method call is. Virtual method calls,
> perhaps? Java has these.
What's a 'virtual method call'?
A dynamic method call looks something like:
my $method = compute_methodname(@_);
$object->$method();
Remarkably useful sometimes.
> Symbol table manipulation is for me another "computed goto"
> something I don't think I'll ever want. Again, you only give it up
> in the special mode.
You never use a modules that use the Exporter? Wow. Or wrote an
AUTOLOAD that loaded deferred methods into the module symbol table?
> No eval of strings, you mean. eval of blocks is fine: eval {}; if
> ($@) { etc.}. 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.
No eval of strings kills things like the Template Toolkit (Assuming it
hasn't been killed big time by the 'no subroutine refs' thing...),
which definitely evals 'large chunks of code' within strings.
> Automatic method generation. Again, never found the need, and you
> only give it up if you want to.
Personally I reckon that having Automatic method generation is *way*
better than violating the DRY principle to build a maze of twisty
little accessor methods, all different.
> > Every class in the hierarchy has to be defined and loaded
> > completely at compile time (well, at least their method
> > signatures) and defined strictly. If there's a class which isn't
> > strictly defined anywhere in your hierarchy, no go.
>
> Yes, that's the point.
Hmm... I think you just killed mod_perl.
> > Also, since you're doing so much more work at compile time, any
> > strictly typed code will probably have to be pre-compiled or else
> > be sluggish to startup (this is just a guess).
>
> Again, for large applications, one expects them to be pre-compiled.
Does one? Are you using perl for large applications? I am and they're
definitely not precompiled.
> > An optional strict typing system would be nice, but I just want
> > you to be aware how difficult it will be to do right, and what you
> > give up by using it. This isn't just a "let's toss this in" sort
> > of feature.
>
> Yes, its not easy to do right, and it is very helpful. Certainly
> worth it in my opinion.
The system you proposed doesn't appear to be doing it right. Too many
babies get thrown out with the bath water. I love the compile time
optimization possibilities that come with static type checking, but
there has to be some way of allowing us keep Perl's flexibility whilst
still seeing some of those gains.
Personally, what I'd like to see is a system that does as much type
based optimization as it can at compile time. If dangerous ops happen
later that could affect all the optimizations, then the various
optimization caches (yeah, I'm being *very* fuzzy here, I'm not
enormously up on the technology so let me wave my hands a bit)
affected need to get flushed and perl has to go back to doing things
the old, slow way.
However, I would hope that some optimizations will be of the
'calculate once, use many' type, and optimization can be redone at
runtime.
Internals guys, feel free to shoot me down if this is complete pie in
the sky.
> > > It got to the point in Java that I would sometimes check in my
> > > code without even testing it I was so sure it was correct. I
> > > can't imagine ever saying that about Perl.
> >
> > 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.
>
> No, it does. Just as people have more accidents when talking on
> their cell phones while driving, even if the cell phone is mounted
> on the dashboard and their hands are free, the more you have
> distracting your attention, the more likely you are to make other
> mistakes. Human attention is the ultimate precious resource.
That's why we have automated testing. So that you don't have to waste
human attention looking for logic errors that may not be there. You
check stuff in and run the tests. If they pass, you didn't make any
basic logic errors so it's on to the next bit of coding.
--
Piers Cawley
www.iterative-software.com
