On Thu, 7 Jun 2001, Michael G Schwern wrote:
> On Wed, Jun 06, 2001 at 01:37:23AM -0500, Me wrote:
> > > B&D languages
> >
> > What's B&D?
>
> Bondage and Discipline, scum! You're not a good enough programmer to
> be trusted not to make mistakes! Now drop and give me fifty!
Hmmm...
From: <[EMAIL PROTECTED]>
To: "David L. Nicol" <[EMAIL PROTECTED]>
Sent: Friday, June 08, 2001 8:01 PM
Subject: Re: Properties and stricture and capabilities
> On Thu, Jun 07, 2001 at 08:24:33PM -0500, David L. Nicol wrote:
> > That would prevent further shoving of
On Thu, Jun 07, 2001 at 08:24:33PM -0500, David L. Nicol wrote:
> > Symbol table manipulation will work as long as your mucking about
> > doesn't alter the strict class's signature. ie. you can shove a code
> > ref onto the symbol table as long as a stub for that method was
> > defined at compile
Michael G Schwern wrote:
> Symbol table manipulation will work as long as your mucking about
> doesn't alter the strict class's signature. ie. you can shove a code
> ref onto the symbol table as long as a stub for that method was
> defined at compile time.
a read-only hash of any kind makes it
On Wed, Jun 06, 2001 at 01:37:23AM -0500, Me wrote:
>
> > Larry's MMV on that ;-)
>
> Man I really need to get up to speed with these
> acronyms. I know YMMV, is MMV a distant
> cousin perhaps?
Same idea, except it's Larry's Milage in question, rather than Yours.
dha
--
David H. Adler - <[EM
This is similar to the solution they use in Java. You have an interface,
which is compile time checked. Then, when you load a class at runtime, you
check at load time that it satisfies the interface. You either get an
exception right then, or you're fine.
Daniel
Michael G Schwern wrote:
> O
Michael G Schwern wrote:
> you can even do it now through ad hockery.
Or odd hackery.
:-)
--
John Porter
Michael G Schwern wrote:
> Basically, any class which wants to be type-checked at compile time.
I think the meaning of that is still not clear,
given what "strong typing" usually means.
--
John Porter
On Wed, Jun 06, 2001 at 01:37:23AM -0500, Me wrote:
> > B&D languages
>
> What's B&D?
Bondage and Discipline, scum! You're not a good enough programmer to
be trusted not to make mistakes! Now drop and give me fifty!
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwe
On Wed, Jun 06, 2001 at 07:06:49PM -0700, Dave Storrs wrote:
> But if we did, how could we hope to get a good new Star Trek
> series? :>
You're still hoping for a new, good Star Trek series??? You must be a
Cubs fan.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~s
On Wed, Jun 06, 2001 at 10:28:41AM -0400, John Porter wrote:
> Michael G Schwern wrote:
> > It will have to go for strict classes. @ISA will have to be locked.
>
> "strict classes"?
> "strongly typed class"?
Can a man make up gibberish in peace? ;)
Basically, any class which wants to be type-c
Ok, I've realized a few things.
1) There's two sorts of type-checking going on here. Compile-time and
run-time.
2) Run-time type checking is fairly easy and imposes few limitations. In
fact, you can even do it now through ad hockery.
3) Compile-time type checking is a bit harder. Any modul
Damian Conway wrote:
> I very much doubt Perl is going to become significantly more statically
> analyzable in general. Though static determinacy is obviously a
> desirable thing, there are plenty of other B&D
Bondage and Discipline?
> languages that offer it
> in abundance. And the dynamic pow
On Tue, 5 Jun 2001, Michael G Schwern wrote:
> 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 r
> > 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 is already detectable. from perldoc perlref:
Perhaps for perl 5, but, aiui, Damian confirmed
that my thi
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?
it is already detectable. from perldoc perlref:
Perl will raise an except
Me wrote:
> 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.
I'll pitch some syntax:
# prevent modification to %reflexive:: like so:
package reflexive is closed;
# allow i
Me wrote:
>
> > [strict typing]
> >
> > Not a negative, but realize that many people find it
> > of less value than the annoyances it brings with it
> > (myself included)
>
> Michael, I don't know which is more impressive; the
> fact that use of a strictly typed language implies that
> a copy of
> [strict typing]
>
> Not a negative, but realize that many people find it
> of less value than the annoyances it brings with it
> (myself included)
Michael, I don't know which is more impressive; the
fact that use of a strictly typed language implies that
a copy of you would land on the poor un
Michael G Schwern wrote:
> It will have to go for strict classes. @ISA will have to be locked.
"strict classes"?
> my $meth = "foo";
> $obj->$meth(); # $obj->foo();
>
> This definately can't work if $obj is of a class which is strongly
> typed.
"strongly typed class"?
> This can
Michael G Schwern <[EMAIL PROTECTED]> writes:
> 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 lon
"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'
>> 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?
>
> Yes.
So:
You can't have (variable or value) property strictur
> 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 i
>> 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 i
> 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
> 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
>> 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
> 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 p
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.
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-
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 st
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.
> I
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-ch
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
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 "eco
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
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
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 ge
Daniel S. Wilkerson wrote:
> 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.
Pre
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
I flatter myself that I understand your point. It is doubtful we shall
have compilers that can tell you for example, that you used the wrong
algorithm.
However, perhaps I did not express my point as well as I could have. I
include the quote from Whitehead again, along with some others.
"By rel
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;
}
--
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,
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
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 y
> 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 possibl
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 tim
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,
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
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]
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 of
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
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
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
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.
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 lo
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'
> N
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
On Tue, Jun 05, 2001 at 12:49:41PM -0400, John Porter wrote:
> Michael G Schwern wrote:
> > If there's a class which isn't strictly defined anywhere in
> > your hierarchy, no go.
>
> For robust, mission-critical software, that can hardly
> be called a negative.
Not a negative, but realize that m
Michael G Schwern wrote:
> If there's a class which isn't strictly defined anywhere in
> your hierarchy, no go.
For robust, mission-critical software, that can hardly
be called a negative.
> Of course, it probably only works with strict functional languages,
> which is very unPerlish.
It could
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
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 h
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 ar
> 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.
Industrial-strength, as Chip says, is great, but also dangerous for pets
and small children.
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
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
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
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 na
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?
70 matches
Mail list logo
