Re: Properties and stricture
On Mon, Jun 04, 2001 at 06:49:28PM -0500, Me wrote: Afaict, even with use strict at its most strict, perl 6 can't (in practice) complain, at compile time, if $foo.Foun refers to an undeclared Foun. Right? Should there be a strict mode that warns if a method name matches a built in property name? Could have one that requires all inheritance and variable declarations occur at compile-time, but that will only effect your current scope. Won't help against classes you inherit from doing run-time things. And then there's autoloading... There's also the problem of knowing at compile time what class/type $foo is. Don't know what's going on with that just yet, do we? So I'd say no, Perl can't know at compile-time if your method is declared or not. Only in certain restricted cases, such as if you don't inherit from anything, or if *all* your parent classes are declared strictly. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Re: Python...
David Grove [EMAIL PROTECTED] writes: Perl is far more practical than experimental. Not at the moment. That's the problem. Pretty much everything proposed, even in the wildest RFCs during the brainstorming phase, was still stuff that's been done elsewhere by other languages. That's the practical vs. experimental distinction that I'm drawing. I realize that you don't like the direction that Perl 6 design is heading, but it's still not heading towards being an experimental language. I've seen some *real* experimental languages; they're a lot more unconventional. You can still trace nearly everything that was proposed back to C, Lisp, or Generic Object-Oriented Language, if not in inspiration than at least in fundamental similarities. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Properties and stricture
On Tue, 5 Jun 2001 [EMAIL PROTECTED] wrote: So I'd say no, Perl can't know at compile-time if your method is declared or not. Only in certain restricted cases, such as if you don't inherit from anything, or if *all* your parent classes are declared strictly. (By 'strictly', I think you mean 'all methods (etc) are declared explicitly in code, not generated by AUTOLOAD, etc'. If I'm not understanding you correctly, please correct me.) Couldn't we still have a 'be-super-strict' flag that would throw warnings upon encountering a construct that would interfere with compile-time checking? Make it be off by default, of course, but if people want Perl to help them check this kind of thing, it should be possible. Dave
Re: Properties and stricture
I would like to suggest that this is one of the major advantages that Java has over Perl. Getting things to work quickly in Perl is great. I like that very much about Perl. But in the end, I'm most concerned that my code is correct. Having the compiler check everything it can possibly check for me is really a requirement for that. You shouldn't find out at run time that you fell out of some part of a complicated data structure. This is one of the major problems with LISP (besides other things, like being hard to read.) With Java, if you build a huge complex data structure, at *compile* time you know that none of your complex manipulations of it fall out, you didn't get confused and ask for the foo member of a bar when only gronk's have a foo. Compile time type checking of method signatures is really helpful as well. 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 would like to be able to use Perl for serious large-scale industrial-strength object-oriented projects, but the lack of strong compile-time type checking really prevents it, unfortunately. Larry, if you're out there, I would say this is *the* major thing you could fix in Perl 6, if I may be so bold. Maybe you could allow people to progressively turn on more and more checking, so you could develop things in the Perl we have now, but after you were done turning on all the checking, it would be as strict as Java. In fact, make it better than Java, why not? Daniel P.S. I'm really not interested in any flames about Java, LISP, etc. Comparative criticisms across languages are a major way to get ideas for new improvements, which is the point of this list, as far as I can tell. [EMAIL PROTECTED] wrote: On Mon, Jun 04, 2001 at 06:49:28PM -0500, Me wrote: Afaict, even with use strict at its most strict, perl 6 can't (in practice) complain, at compile time, if $foo.Foun refers to an undeclared Foun. Right? Should there be a strict mode that warns if a method name matches a built in property name? Could have one that requires all inheritance and variable declarations occur at compile-time, but that will only effect your current scope. Won't help against classes you inherit from doing run-time things. And then there's autoloading... There's also the problem of knowing at compile time what class/type $foo is. Don't know what's going on with that just yet, do we? So I'd say no, Perl can't know at compile-time if your method is declared or not. Only in certain restricted cases, such as if you don't inherit from anything, or if *all* your parent classes are declared strictly.
Re: Properties and stricture
Perl has strong typing; it just has a different notion of
what a type is. The types in Perl are SCALAR, ARRAY,
HASH, CODE, and a few others. Watch:
% perl -e 'sub foo(\@){} foo %h'
Type of arg 1 to main::foo must be array (not hash deref) at -e line 1, at EOF
Execution of -e aborted due to compilation errors.
--
John Porter
Anything essential is invisible to the eyes.
Re: Properties and stricture
On Tue, Jun 05, 2001 at 11:51:53AM -0400, John Porter wrote:
Perl has strong typing; it just has a different notion of
what a type is. The types in Perl are SCALAR, ARRAY,
HASH, CODE, and a few others. Watch:
% perl -e 'sub foo(\@){} foo %h'
Type of arg 1 to main::foo must be array (not hash deref) at -e line 1, at EOF
Execution of -e aborted due to compilation errors.
Prototypes don't work on methods. And I wouldn't hold them up as
being anything but a mediocre hack. Its not really type checking.
Of course, there's Attribute::Types for things like that.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
sort God kill 9, @ARGV;
Re: Properties and stricture
On Tue, Jun 05, 2001 at 08:24:31AM -0700, Daniel S. Wilkerson wrote: But in the end, I'm most concerned that my code is correct. Having the compiler check everything it can possibly check for me is really a requirement for that. Compile time type checking of method signatures is really helpful as well. What you count as Java's greatest strength, I count as Java's greatest weakness. You have to remove *alot* of language features to get down to the point where its predictable at compile time. 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). 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. 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). 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. As an interesting side-note, there are functional languages out there which do strict type checking *without* you having to explicitly declare the types of everything. I'm fuzzy on the details... I believe its called Implicit Typing, ML and CAML do it. Anyhow, might be interesting to look into. A typing system that just works without you really having to do anything would be very Perlish. Of course, it probably only works with strict functional languages, which is very unPerlish. 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. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Death follows me like a wee followey thing. -- Quakeman
Re: Properties and stricture
Michael G Schwern wrote: Prototypes don't work on methods. And I wouldn't hold them up as being anything but a mediocre hack. Its not really type checking. It's not just prototypes. % perl -e '$r=\%h; print @$r' Not an ARRAY reference at -e line 1. Of course, that's a run-time check, but that's a consequence of perl's dynamic nature. -- John Porter
Re: Properties and stricture
On Tue, Jun 05, 2001 at 07:33:55AM -0700, Dave Storrs wrote:
(By 'strictly', I think you mean 'all methods (etc) are declared
explicitly in code, not generated by AUTOLOAD, etc'. If I'm not
understanding you correctly, please correct me.)
Yeah, pretty much. I put together a proof-of-concept thingy to scan
for constructs which make code unpredictable here:
http://www.pobox.com/~schwern/src/B-Scan-0.01.tar.gz
Couldn't we still have a 'be-super-strict' flag that would throw
warnings upon encountering a construct that would interfere with
compile-time checking? Make it be off by default, of course, but if
people want Perl to help them check this kind of thing, it should be
possible.
Yes, I'm just afraid this sort of thing would expand to engulf all of
Perl. I'm also worried its scope would become far too large.
Consider the following... Foo is a poster-child for a strict class.
Everything is predeclared and typed. Its entire hierarchy is rock
solid. Someone uses Foo in their script and calls Foo-bar. They
also use Bar, a module you installed a long time ago. Bar does this:
package Bar;
eval sub Foo::bar { 23 };
Oh crap! All the wonderful compile-time checking we did on Foo has
just been blown to pieces.
This is, of course, a drastic example, but these sort of tricks go on
all the time in Perl. Its probably not the cleanest OO style in the
universe, but its Perl's. Any Perl OO idiom which breaks *formal*
encapsulation (as opposed to the informal style we usually keep) won't
work with strict, compile-time typing. One or the other has to give.
I'm running into similar problems trying to put together some sort of
serviceable refactoring tools. Perl's extreme maliability also means
extreme unpredictability, which makes things like strict typing and
automated refactoring less than 100% reliable.
Before anyone gets the wrong idea, I don't think the solution is a
drastic scaling back in Perl's flexibility. I just don't know what
the solution is yet. Maybe it should be possible for a class to
completely seal off its namespace to the outside world on request.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Death follows me like a wee followey thing.
-- Quakeman
Re: Properties and stricture
On Tue, Jun 05, 2001 at 12:46:52PM -0400, John Porter wrote: Michael G Schwern wrote: Prototypes don't work on methods. And I wouldn't hold them up as being anything but a mediocre hack. Its not really type checking. It's not just prototypes. % perl -e '$r=\%h; print @$r' Not an ARRAY reference at -e line 1. This isn't type-checking (semantical arguments /dev/null), its more like basic syntax. You don't want to try holding up prototypes and dereference checks to Java's typing system and try to claim its in the same league, or even the same sport. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One It sure is fun masturbating. http://www.unamerican.com/
Re: Properties and stricture
At 07:29 PM 6/5/01 +0100, Michael G Schwern wrote:
Consider the following... Foo is a poster-child for a strict class.
Everything is predeclared and typed. Its entire hierarchy is rock
solid. Someone uses Foo in their script and calls Foo-bar. They
also use Bar, a module you installed a long time ago. Bar does this:
package Bar;
eval sub Foo::bar { 23 };
Oh crap! All the wonderful compile-time checking we did on Foo has
just been blown to pieces.
[snip]
Before anyone gets the wrong idea, I don't think the solution is a
drastic scaling back in Perl's flexibility. I just don't know what
the solution is yet. Maybe it should be possible for a class to
completely seal off its namespace to the outside world on request.
I would like to see some sort of use really_strict pragma which would
disable at compile time the kinds of things you mentioned:
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).
Of those, only subroutine refs and automatic method generation look like
must-haves for major projects, which are willing to surrender some of the
cute stuff in return for stability.
Quite how Foo prevents Bar from causing shenanigans if Bar was used first,
I don't know; might not be possible until runtime.
--
Peter Scott
Pacific Systems Design Technologies
http://www.perldebugged.com
Re: Properties and stricture
Michael G Schwern wrote: % perl -e '$r=\%h; print @$r' Not an ARRAY reference at -e line 1. This isn't type-checking (semantical arguments /dev/null), Heed your own redirection, eh? its more like basic syntax. No, it's not. If it were, then it would be caught at compile time. You don't want to try holding up prototypes and dereference checks to Java's typing system and try to claim its in the same league, or even the same sport. As I said before, it boils down to the fact that perl's notion of a type is different from other languages. It *does* check these types, and it casts very opportunistically. -- John Porter Anything essential is invisible to the eyes.
Re: Properties and stricture
On Tue, Jun 05, 2001 at 02:42:01PM -0400, John Porter wrote: You don't want to try holding up prototypes and dereference checks to Java's typing system and try to claim its in the same league, or even the same sport. As I said before, it boils down to the fact that perl's notion of a type is different from other languages. It *does* check these types, and it casts very opportunistically. Ok, let's call them types for a moment. A) You can't meaningfully define new types. This makes it pretty much useless as a typing system. B) The system's only awareness of OO is that objects must be references, otherwise anything goes. Even if prototypes worked on methods you still couldn't specify which objects you want. C) To call Perl's differenciation between scalar, array, etc... references a typing system is like calling C's differenciation between structs, arrays and scalars a typing system. You may be able to draw analogies, but they don't serve the same purpose. Yes, there is some actual type casting going on between strings and numbers and various internal scalar types, but its mostly behind the scenes. What Perl does with references is basic sanity. Using a scalar reference as an array ref doesn't really have meaning, for example. A real typing system is a layer of *additional and arbitrary* (from a purely syntactical PoV) enforcement on top of this. Typed data could mix and could have meaning (a variable of type Velocity could be used where a Price is wanted, they're both numbers) but you disallow it because it doesn't fit in with the reality you've defined in your program. Perl doesn't have a built-in typing system comparable to what most of other languages have, and its not healthy to delude ourselves into thinking we have one. The lack isn't much of a problem, Perl doesn't really need it and it causes all sorts of complications (as noted in the other threads). Wouldn't hurt to have one, though. I have a feeling we're arguing somewhat different things here. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One OH GOD!! It's LINUX! All you Linux fanboys go wild! It never crashes! It'll wash your underpants! It'll eat your dog for you, if you want your dog to be eaten! It'll make you attractive and smell good and... it'll... uh... uh. Man, I'm so sick of this shit. http://www.goats.com/archive/000602.html
RE: Properties and stricture
From: Michael G Schwern [mailto:[EMAIL PROTECTED]] Before anyone gets the wrong idea, I don't think the solution is a drastic scaling back in Perl's flexibility. I just don't know what the solution is yet. Maybe it should be possible for a class to completely seal off its namespace to the outside world on request. How do you determine the outside world? Out of the package's namespace or out of the file's? When you say seal off its namespace, do you mean that the symbol table would be thereafter static... or that only code within the predeclared scope could mess with the symbol table? What about lexicals? How about: package_name.finalize(); finalize package_name; finalize could/should? probably be context-aware as to which BEGIN, CHECK, INIT, or END phase it is in... Or would that be better as BEGIN.finalize(), CHECK.finalize(), ... with package.finalize() implying: $_.finalize() foreach(qw(BEGIN CHECK INIT END))
Re: Properties and stricture
I can't imagine any way in which one can consider Perl typing to be strong.
When you know the type of a variable, you are supposed to have confidence that
when you see a statement
a - lexically locally (without looking around elsewhere) and
b - at compile time
you know exactly what the statement means.
1 - A scalar that has been assigned a string value reacts differently than a
scalar that has been assigned a numerical value to operations like (bitwise
and) and ++ (autoincrement). Even worse, a scalar can be a reference to an array
or a hash or an object and this is only checked at runtime.
2 - You can't make a user defined type, like classes in Java, that are compile
time checked.
There are many other examples.
Daniel
John Porter wrote:
Perl has strong typing; it just has a different notion of
what a type is. The types in Perl are SCALAR, ARRAY,
HASH, CODE, and a few others. Watch:
% perl -e 'sub foo(\@){} foo %h'
Type of arg 1 to main::foo must be array (not hash deref) at -e line 1, at EOF
Execution of -e aborted due to compilation errors.
--
John Porter
Anything essential is invisible to the eyes.
Re: Properties and stricture
On Tue, Jun 05, 2001 at 02:37:11PM -0500, Garrett Goebel wrote:
Before anyone gets the wrong idea, I don't think the solution is a
drastic scaling back in Perl's flexibility. I just don't know what
the solution is yet. Maybe it should be possible for a class to
completely seal off its namespace to the outside world on request.
How do you determine the outside world? Out of the package's namespace or
out of the file's?
It would have to be both. Nothing outside the namespace could peek at
or modify package data in that namespace, and no outside lexical
context would be allowed to use that namespace.
So if Foo.pm defines class Foo as being armored, Bar.pm couldn't do this:
package Bar;
{
package Foo;
print $Secret_Foo_Variable;
}
Of course, there's problems of order of definition. What happens if
Bar.pm is loaded before Foo? Dunno.
When you say seal off its namespace, do you mean that the symbol table
would be thereafter static... or that only code within the predeclared scope
could mess with the symbol table?
Only code inside that namespace could mess with stuff in that
namespace. It can all still change, but the changes cannot come from
outside its package.
What about lexicals?
Lexicals already have their own privacy rules.
How about:
package_name.finalize();
finalize package_name;
This is a different concept.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
I knew right away that my pants and your inner child could be best friends.
Re: Properties and stricture
On Tue, Jun 05, 2001 at 01:05:45PM -0700, Daniel S. Wilkerson wrote: 2 - You can't make a user defined type, like classes in Java, that are compile time checked. Well, you can sort of: Attribute::Types. But that's not what John is talking about. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One gigaconway: a hypothetical unit of mind expansion, so disturbing it is likely to change the fundemental nature of the universe. Some contend that gigaconway events, while rare, are much cheaper to produce than antiprotons, nuclear weapons or even XML specifications, and start at US$60,000 each. If you believe gigaconway events are indeed possible, please send your tax deductable contributions to: The Conway Fund, c/o Yet Another Society http://www.yetanother.org/ -- Ziggy
Re: Properties and stricture
Michael G Schwern wrote:
On Tue, Jun 05, 2001 at 08:24:31AM -0700, Daniel S. Wilkerson wrote:
But in the end, I'm most concerned that my code is correct. Having
the compiler check everything it can possibly check for me is really
a requirement for that. Compile time type checking of method
signatures is really helpful as well.
What you count as Java's greatest strength, I count as Java's greatest
weakness. You have to remove *alot* of language features to get down
to the point where its predictable at compile time.
You only remove these features if you turn on the strict-type-checking
mode, as someone else and I suggested.
Having compile time checking is just asking that the sentences in your
program make sense at a certain basic level before you run it. I cannot
imagine running an enterprise critical application 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.
Here is a major point: Compile time checking is
a - syntactic, and
b - local.
You really can finish checking everything, if the type information is there.
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.
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.
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.
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.
Not sure what a dynamic method call is. Virtual method calls, perhaps? Java
has these.
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.
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.
Automatic method generation. Again, never found the need, and you only give
it up if you want to.
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.
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.
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.
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.
By relieving the brain of all unnecessary work, a good notation sets it free
to concentrate on more advanced problems, and, in
RE: Properties and stricture
Michael G Schwern [mailto:[EMAIL PROTECTED]] wrote: Of course, there's problems of order of definition. What happens if Bar.pm is loaded before Foo? Dunno. simple sematics can be defined. If we see a declaration: package Foo is encapulated; then we throw an error if the namespace, Foo, is not empty. At the end of the package (either EOF or a new package decl) then the namespace is sealed. Dave. -- Dave Whipp, Senior Verification Engineer, Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086 tel: 408 523 8071; http://www.fast-chip.com Opinions my own; statements of fact may be in error.
Re: Properties and stricture
Daniel S. Wilkerson wrote: I can't imagine any way in which one can consider Perl typing to be strong. When you know the type of a variable, you are supposed to have confidence that when you see a statement a - lexically locally (without looking around elsewhere) and b - at compile time you know exactly what the statement means. No, that is not strong typing. That is static typing. -- John Porter
Re: Properties and stricture
I would like to see some sort of use really_strict pragma which would disable at compile time the kinds of things you mentioned: Yes, the point is to make this possible, not required. I thought Perl was supposed to make hard things possible. This is easy in Java and its not even possible in Perl. 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). Of those, only subroutine refs and automatic method generation look like must-haves for major projects, which are willing to surrender some of the cute stuff in return for stability. Subroutine refs are fine. Again, Java does them with interfaces. Someone please tell me what automatic method generation is exactly. Daniel
Re: Properties and stricture
Daniel S. Wilkerson wrote: Michael G Schwern wrote: 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. I think you're missing what ought to be an obvious point: No amount of (sane) typing will allow your compiler to know that if ( x y ) is wrong when you meant to say if ( x y ) That is what is meant by logic error. -- John Porter Anything essential is invisible to the eyes.
Re: Properties and stricture
If you call a method in Java, you can see right there which method you are calling. You can then lexically follow the inheritance tree and find out exactly what code really is called, what its signature is, and what it returns. Nothing dynamic is involved. One might ask for other featues, but I consider looking at the code and 1 - knowing what other code it is going to call, or 2 - whether that class really has that member or not, etc. at compile time to be a minimum reqirement of any typing I would call strong. Daniel John Porter wrote: Daniel S. Wilkerson wrote: I can't imagine any way in which one can consider Perl typing to be strong. When you know the type of a variable, you are supposed to have confidence that when you see a statement a - lexically locally (without looking around elsewhere) and b - at compile time you know exactly what the statement means. No, that is not strong typing. That is static typing. -- John Porter
Re: Properties and stricture
On Tue, Jun 05, 2001 at 01:42:38PM -0700, Daniel S. Wilkerson wrote: Someone please tell me what automatic method generation is exactly. Its the generation of large numbers of similar methods which would otherwise be really tedious to write out by hand, such as accessor methods. Without this, object-oriented programming would be hand-cramping tedium (or an elaborate exercise in editor macros). Its also very useful for generating complete sub-classes on the fly. Class::Accessor and Class::MethodMaker are two modules which I can think of off the top of my head that do this in Perl. Class::DBI absolutely depends on it. Java trips rather badly on this technique. For some elaboration... http://www.pobox.com/~schwern/papers/Why_I_Am_Not_A_Java_Programmer/why.pod in particular the section entitled No dynamic method generation For a really elaborate elaboration... http://www.pobox.com/~schwern/papers/Closures_and_Accessors/Closures_and_Automated_Accessors.txt -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One I'm not actually Kevin Lenzo, but I play him on TV.
Re: Properties and stricture
On Tue, Jun 05, 2001 at 01:42:38PM -0700, Daniel S. Wilkerson wrote:
Someone please tell me what automatic method generation is exactly.
package Foo;
sub AUTOLOAD {
my $method = $AUTOLOAD;
eval sub $method { warn qq/Please do not call this method again.\n/ }
goto $method;
}
--
I washed a sock. Then I put it in the dryer. When I took it out, it was gone.
-- Steven Wright
Re: Properties and stricture
Thank you, that's what I thought it might be. This can be done at compile time with a two-stage compilation. The first one writes the code that the second compiles. Then the checking can be done during the second stage. Daniel Michael G Schwern wrote: On Tue, Jun 05, 2001 at 01:42:38PM -0700, Daniel S. Wilkerson wrote: Someone please tell me what automatic method generation is exactly. Its the generation of large numbers of similar methods which would otherwise be really tedious to write out by hand, such as accessor methods. Without this, object-oriented programming would be hand-cramping tedium (or an elaborate exercise in editor macros). Its also very useful for generating complete sub-classes on the fly. Class::Accessor and Class::MethodMaker are two modules which I can think of off the top of my head that do this in Perl. Class::DBI absolutely depends on it. Java trips rather badly on this technique. For some elaboration... http://www.pobox.com/~schwern/papers/Why_I_Am_Not_A_Java_Programmer/why.pod in particular the section entitled No dynamic method generation For a really elaborate elaboration... http://www.pobox.com/~schwern/papers/Closures_and_Accessors/Closures_and_Automated_Accessors.txt -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One I'm not actually Kevin Lenzo, but I play him on TV.
$foo.Foun (was Re: Properties and stricture)
I apologize. I royally screwed up my original post. I had meant to ask two minor specific yes/no answer type questions about properties and stricture, that were mutually unrelated. Instead I asked one major open ended one. In the hope that I haven't completely blown any chance of getting answers to what I meant to ask, here's another shot: Question 1: Afaict, even with use strict at its most strict, perl 6 can't (in practice) complain, at compile time, if $foo.Foun refers to an undeclared Foun. Right? -- Question 2: Should there be a strict mode that warns if a method name matches a built in property name? -- Q1 followed from me thinking about my/our concepts as they might apply to properties. The more I thought about it, the more I gravitated toward the proposed system (lowercase for builtins, Mixedcase for user defined, only declare properties as part of my/our, etc), but I wanted to confirm that one ends up with this one unavoidable consequence -- that, ignoring unreasonable changes to perl, accidental $foo.Foun, even with strong stricture, will not be detectable. Q2 followed from me thinking about the way properties and object method names will share namespace. I wholeheartedly support the introduction of this sort of idiosyncratic, oddly, er, shaped, polymorphism. Larry's 'natural language' basis for perl is absolutely fundamental and brilliant, and I'm not questioning it whatsoever. But, within this framework, whatever stricture is reasonably available is nice, and I thought the specific mode I suggested made sense, assuming I understand the current proposal for properties.
Re: Properties and stricture
At 02:39 PM 6/5/2001 -0700, Daniel S. Wilkerson wrote: Thank you, that's what I thought it might be. This can be done at compile time with a two-stage compilation. The first one writes the code that the second compiles. Then the checking can be done during the second stage. Not when the methods to be generated aren't determined until run time.
Re: Properties and stricture
Daniel S. Wilkerson wrote: It is doubtful we shall have compilers that can tell you for example, that you used the wrong algorithm. Right. I think that's what Schwern was getting at, when he said Type checking is nice, but its just one class of error-checking. By preventing lots of little gotchas, you free the mind to pay attention to what it is doing rather than the most minute details of how to do it. This is a quite powerful effect. Interesting you should mention this. It is, without a doubt, the main reason we like to program in Perl, instead of in low-level languages like Fortran and Java. And it may explain why programs written in Perl -- dynamic, weakly-typed though it be -- are at least no more buggy than programs written in low-level languages. But I think we've strayed into the topic of advocacy. -- John Porter Anything essential is invisible to the eyes.
Re: Properties and stricture
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
Re: Properties and stricture
On Tue, Jun 05, 2001 at 02:39:33PM -0700, Daniel S. Wilkerson wrote: Thank you, that's what I thought it might be. This can be done at compile time with a two-stage compilation. The first one writes the code that the second compiles. Then the checking can be done during the second stage. Yeah, but that's yicky and limiting and involves temp files and you have to know everything you want to generate before you run the program. Anyhow, I think we can save the technique even with strict-types. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One GOD made us funky!
Re: Properties and stricture
John Porter wrote: Daniel S. Wilkerson wrote: It is doubtful we shall have compilers that can tell you for example, that you used the wrong algorithm. Right. I think that's what Schwern was getting at, when he said Type checking is nice, but its just one class of error-checking. The Halting Problem demonstrates that you can never automatically check for all bugs, since you can't even check if a program will halt or not. But, so what? The more bugs you find automatically, the better. And it may explain why programs written in Perl -- dynamic, weakly-typed though it be -- are at least no more buggy than programs written in low-level languages. It would be interesting for someone to measure that, however I doubt that it is so. Its true that any language can be abused. But in certain languages, when you really try to tighten things down and bullet proof your code, you just can't. But I think we've strayed into the topic of advocacy. This is a language design form, and Perl explicitly draws features from other languages. All the books brag about that in the introduction. Therefore, I'm suggesting drawing a feature from one more language. So, I think we are right on the mark in this discussion. Daniel
DANGER! ADVOCACY! (was Re: Properties and stricture)
On Tue, Jun 05, 2001 at 05:49:30PM -0400, John Porter wrote: By preventing lots of little gotchas, you free the mind to pay attention to what it is doing rather than the most minute details of how to do it. This is a quite powerful effect. Interesting you should mention this. It is, without a doubt, the main reason we like to program in Perl, instead of in low-level languages like Fortran and Java. And it may explain why programs written in Perl -- dynamic, weakly-typed though it be -- are at least no more buggy than programs written in low-level languages. Yes, this is something I've been meaning to investigate somewhat in the Why I Am Not A Java Programmer thing, but didn't really feel confident enough about to get into. By reducing the amount of code you need to write, very high-level languages can drastically reduce bug counts. This is partially because programmers tend to have a constant bug-rate per Kloc (thousand lines of code), so less code means less bugs. Its also because smaller code means less to remember and easier to keep in your head. Of course, any low-level language can achieve similar wins with sufficient libraries/classes to raise its level of encapsulation to that of a high-level language, to a certain extent. Obviously, trying to drag assembler up to the level of Perl wouldn't quite work. Then again, you can view Perl as just a bit abstracted interface to C... Removing incidental work also helps. Explicit type-checking can be seen as just that. Its not strictly necessary, you can strip it all out and the code will run exactly the same (with a bit of hand-waving towards type-casting magic). Other things you can strip and/or automate are memory allocation, privacy rules, accessors, etc... None of these things directly effect your real goal, which is the encoding of a reality onto bits. Now, this same argument can be taken too far. Documentation, tests, comments, whitespace... these too are incidental. But strip them at your peril! You must draw a personal line and decide for yourself what is necessary and what is just paperwork. The problem with Java is they've drawn the line for you. You must use strong types, you must set up privacy rules, you must write all your code by hand, you can't allocate your own memory, etc... The problem with Perl is you can only draw the line at certain places. Privacy? Take it or leave it. Strong types? Ummm, sorry. But I think we've strayed into the topic of advocacy. Interesting advocacy, nevertheless. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One I am not one of those stupid moron who don't know what I am doing. I know about FDA. FDA raids hundreds of small businesses every year that deal with alternative medicine or therapy. They take away your computer, seize your $200,000 inventory, and drive your company totally out of business in no time if they ever approach you. --Alex Chiu, Immortality Guy
Re: Properties and stricture
On Tue, Jun 05, 2001 at 03:29:02PM -0700, Daniel S. Wilkerson wrote: It would be interesting for someone to measure that, however I doubt that it is so. Oh, and look at what just showed up in my mailbox! - Forwarded message from Tony Bowden [EMAIL PROTECTED] - I think we should start measuring our rate of change on the Maintainability Index over time: It's quite a simple process. For each 'module' of code, we just take: 171 - 5.2 * ln(aveV) - 0.23 * aveV(g') - 16.2 * ln (aveLOC) - 50 * sin (s= qrt(2.4 * perCM)) where perCM= the average percent of lines of comments per module, aveLOC = the average count of lines of code per module aveV(g') = the average extended cyclomatic complexity per module=20 aveV = the average Halstead Volume V per module. For anyone not familiar with the latter concepts, the cyclomatic complexity (CC) is simply calculated as: CC = E - N + p Where for a connected graph of the module that shows the topology of control flow within the program, E = the number of edges of the graph N = the number of nodes of the graph p = the number of connected components and the Halstead Volume is simply HV = N * (LOG2 n) where N = N1 + N2 n = n1 + n2 where n1 = the number of distinct operators n2 = the number of distinct operands N1 = the total number of operators N2 = the total number of operands=20 (This is spelt out in much more detail at http://www.sei.cmu.edu/activities/str/descriptions/mitmpm.html) This should be fairly simple to implement (I'll leave that as an exercise for the reader), and could probably be used as a starting point for CPANTS. --- End forwared message (That was a joke, BTW) -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Let me check my notes. http://www.sluggy.com
Re: $foo.Foun (was Re: Properties and stricture)
On Tue, Jun 05, 2001 at 04:38:24PM -0500, Me wrote: Question 1: Afaict, even with use strict at its most strict, perl 6 can't (in practice) complain, at compile time, if $foo.Foun refers to an undeclared Foun. Right? Can't you hear the low roar from the strong-typing argument coming from the thread next door? -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Stupid am I? Stupid like a fox!
Re: Properties and stricture
On Tue, Jun 05, 2001 at 11:14:29PM +0100, Michael G Schwern wrote: 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. You would do that in Java by using reflection. There's nothing about strong typing which prevents dynamic method calls like this, although you obviously can only verify the sanity of the call at runtime. - Damien
Re: $foo.Foun (was Re: Properties and stricture)
Question 1:
Afaict, even with use strict at its most strict, perl 6
can't (in practice) complain, at compile time, if
$foo.Foun
refers to an undeclared Foun.
It could certainly warn you, but it can't object fatally since there's
always the possibility of a subsequent call to: eval sub FooClass::foo {...}
Question 2:
Should there be a strict mode that warns if a
method name matches a built in property name?
Possibly.
Of course, the whole point of unifying the method and property access
syntaxes was to allow exactly those kinds of shenanigans. But it might
be a Good Thing if you had to explicitly turn off such a stricture to
shenan that way:
class FooClass;
no strict 'properties';
sub const (FooClass $self) {
return $self{const} || $self.prop{const}
}
Damian
Re: $foo.Foun (was Re: Properties and stricture)
Question 2:
Afaict, even with use strict at its most strict, perl 6
can't (in practice) complain, at compile time, if
$foo.Foun
refers to an undeclared Foun.
It could certainly warn you
Consider the code:
my $foo = 1 is Found;
bar($foo);
sub bar { my $baz = shift; if ($baz.Found) { ...} }
Does the value of $baz have the Found property?
If so, does the compiler know that?
Question 2:
Should there be a strict mode that warns if a
method name matches a built in property name?
Possibly.
Of course, the whole point of unifying the method and
property access syntaxes was to allow exactly those
kinds of shenanigans. But it might be a Good Thing
if you had to explicitly turn off such a stricture to shenan
that way:
class FooClass;
no strict 'properties';
sub const (FooClass $self) {
return $self{const} || $self.prop{const}
}
Yes. That was pretty much exactly what I was thinking.
One of several benefits would be to help deal with the
introduction of new properties in later Perl versions.
When an older class was used with the newer Perl,
conflicting names would immediately break or warn,
which it seems to me would be a Good Thing.
Re: $foo.Foun (was Re: Properties and stricture)
On Tue, Jun 05, 2001 at 04:38:24PM -0500, Me wrote: Question 1: Afaict, even with use strict at its most strict, perl 6 can't (in practice) complain, at compile time, if $foo.Foun refers to an undeclared Foun. Right? Can't you hear the low roar from the strong-typing argument coming from the thread next door? Yes. Indeed the volume quite startled me... I.Found your notion of a sealed off namespace intriguing. I have no idea what it meant just yet; I'm going to go read and think about it now.
Re: $foo.Foun (was Re: Properties and stricture)
Consider the code:
my $foo = 1 is Found;
bar($foo);
sub bar { my $baz = shift; if ($baz.Found) { ...} }
Does the value of $baz have the Found property?
Yes.
If so, does the compiler know that?
No. Because it only has the property at run-time.
Damian
Re: $foo.Foun (was Re: Properties and stricture)
Consider the code:
my $foo = 1 is Found;
bar($foo);
sub bar { my $baz = shift; if ($baz.Found) { ...} }
Does the value of $baz have the Found property?
Yes.
If so, does the compiler know that?
No. Because it only has the property at run-time.
So, is it right to say that one can't use stricture to avoid
use of mistyped user defined value attached properties?
(Perhaps with the exception of references to a value
property in the same lexical scope as assignments of
that value?)
And, if this is so, then isn't it impossible to have useful
stricture about variable properties, because any given
reference to a property might be instead a value property
unknown to the compiler?
