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 w
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 determinted
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
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 compi
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 overloa
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 di
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 generi
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" !?
Simon Cozens wrote:
>
> 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 the
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.
Considerin
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
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
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
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
: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, o
com/lives/franklin/chapt11/
The relevance to software engineering hardly needs pointing out. Each
bug that can be automatically prevented instead of requring a human to
find it is one of those "little advantages that occur every day".
Daniel
John Porter wrote:
> Daniel S. Wilkerson
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 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
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.
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
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
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("v
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 goi
One of the great strengths of Perl is that, more than any other
language I know, it helps you cross between the "data" space and the
"program" space: eval(), built in regex notation, etc. Even with the
considerable expressive power already at our disposal, I would like to
suggest that there might
24 matches
Mail list logo
