Everyone I've ever talked to about it agrees that defining things to be a
negative is just a bad idea. Consider:
if (gronk) do_this();
else do_that();
versus
if (not_gronk) do_that();
else do_this();
It is one of the standard refactoring tricks to replace the second one
with the first. The
Larry,
Please don't use 'but' to associate runtime properties to things.
Please call it 'has'.
First, but is just strange. I have a thing and I want to tell you it is
red, so I say 'but'. Huh?
Using 'has' makes a nice parallel with 'is' for compile time properties:
What you are is
Excuse me, my mistake.
David Grove wrote:
If you have not been following this thread, then maybe that is
the reason for
the confused-sounding nature of your email.
I would say Simon was the one ignoring an issue and attacking a
person, not
Vijay. I think Vijay was the one
Sam Tregar wrote:
Perl 6 will allow you to mutate your syntax at runtime any way you want.
At *runtime*? You won't need computed gotos or eval anymore. You just have
one block of generic-looking code and you change what the syntax means before
it executes. Three routines in one!
Daniel
Me wrote:
I don't think it's reasonable to say I propose you change
something that hasn't yet been defined. Rather, it is
precisely because you haven't yet defined the MD array
syntax that I thought it worth at least considering how it
parallels db data BEFORE you define it.
Considering
Simon Cozens wrote:
scream
This is the kind of thing that can be dealt with perfectly satisfactorily
with external modules; ergo, it does NOT need to be in the core. Ergo,
it probably *does* *not* *need* *discussing* *here*.
Much of the discussion on this list seems to concern what will be
Dave Storrs wrote:
2) This feature would be very prone to abuse (makes it easier to
obfuscate code),
Whoa! Never thought I'd hear that! And computed function calls/adding things
to the namespace at runtime/rearranging the inheritance tree at runtime aren't
very prone to abuse !?
Dan Sugalski wrote:
At 04:20 PM 6/11/2001 +0100, Simon Cozens wrote:
On Mon, Jun 11, 2001 at 08:16:12AM -0700, Daniel S. Wilkerson wrote:
At *runtime*? You won't need computed gotos or eval anymore. You just
have
one block of generic-looking code and you change what the syntax means
If you have not been following this thread, then maybe that is the reason for
the confused-sounding nature of your email.
I would say Simon was the one ignoring an issue and attacking a person, not
Vijay. I think Vijay was the one pointing out that this person (Me) was
contributing to the
So, you want method overloading, I take it? It is a very nice feature and
I've used it often in another language. Well, you basically can't have it
unless you have type checking of the arguments. And the more strong the type
checking, the less dangerous and the more effective the method
I think you could only delay function calls automatically like this if you
could ensure that they are truely functional. That is, their output must
depend only on the arugments given and must have no mutation
side-effects. It seems to me that this is hard to guarantee in Perl, even
for the
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:
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
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
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
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
, 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
-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
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
Please forgive the naiveté of this question.
1 - If Perl6 is going to have multiple back-ends, rather like the
cross-compilation feature of gcc, Perl6 won't be a specific virtual
machine or back-end. (As Perl5 is now, and, say, Java has as a fundamental
part of its design.)
2 - If Perl6 is
Damian Conway wrote:
You may also be wondering what happens if a variable and the value it
contains both have a property of the same name. The answer is that we
always get back the variable's property in preference to the value's:
my $var is Purpose(var demo) = 1 is Purpose(val
21 matches
Mail list logo
