> Arg! You beat me to it. :-) This was the next RFC on my list.
Nate, if I had known that, I would gladly have let you take the arrows. =^)
> However, nobody should ever have to call something like $n->NUMBER or
> $n->asInt if they don't want to. And they definitely shouldn't have to
> know the
> Great. My point I was trying to drive at was that:
>
>my int $x = 5;
>
> Could turn around and do something different than asInt(). All stores
Got it. And sure, why not? Pay the overhead when you absolutely need to, and
no sooner. The core idea (for me) is to avoid wasting resources on a
me
I've read over 161 again and I'm starting to see areas where I can clarify
things greatly. I apologize for the confusion. I'll make mods to the RFC in
the near future, after I get more feedback from you all.
Here are my goals as they probably should have been stated in the RFC:
- Concentrate re
> I just want to hit this point a little more, to make sure we're actually
> in agreement.
Ok, ok... sorry about this. I've been hammering away at a stubborn gray area
and now I'm seeing that "duh!" it's all right there. Yes, of course 'int'
would be a subclass of Scalar. You know, it's silly...
> Here's hoping I don't have to prove that, and Larry will just reject
> this proposal outright. :)
I would hope that *no* proposal would be rejected "outright", otherwise we
might miss some real opportunities.
Here's hoping that you *do* have to prove what you're saying. That would
give everyon
> mainstream OO languages go). It looks like Dog could be a type of String
> subclass.
That was my first thought as well. Besides, I'd rather type:
my Dog $spot("Spot");
Which says everything that needs to be said without any repetition, and it's
fairly intuitive.
> As with the above, th
Perhaps there is some way to allow for both syntaxes? For example, in C++ I
can say:
string str();
or:
string* str = new string();
Depending on my needs.
So perhaps sometimes in Perl we could say:
my Dog $spot = undef;# Automagically knows to be a Dog ref instead
of a Dog obj
> Right now, the default behavior of perl is that un-initialized variables
> are automatically undef. It would be weird to have to do explicit
> assignment of an variable to say so.
You're right. And as another post mentioned, it's too much "magic". But It's
hard to come up with a comfortable sy
> Damian Conway wrote:
> >
> > * invoke some other hierarchy of automagic methods
> > (REFIT? RESHAPE? MORPH? TRANSMOGRIFY?), or
REINCARNATE
> goes? Your logic suggests that I'd never want to meddle in the base's
> implementation.
What happens when the base classes' author finally fixes the problem you
wrote around (and incidentally changes touchy implementation details in the
base)? What happens someday when you can't see the implem
Unless I hear compelling arguments to the contrary, I'll be withdrawing RFC
161 on Tuesday due to lack of interest.
Matt Youell
[EMAIL PROTECTED]
> > On Wed, Sep 27, 2000 at 05:25:28AM -, Perl6 RFC Librarian wrote:
> > > Not an awful lot was said once this RFC was condensed down to
"Everything
> > > becomes an object". I believe some implementation and conceptual
hurdles
> > > exist which have discouraged more serious discussion. At the
> On Wed, Sep 27, 2000 at 09:53:03AM -0700, Matt Youell wrote:
> > Ok, no fair sniping after a freeze. You were warned. It's called email,
> > people! Use it. Jeez...
>
> Never too late to withdraw, sir. [1] The less crap we make Larry wade
through,
> the better.
I
On Wed, Sep 27, 2000 at 03:17:01PM -0400, Bennett Todd wrote:
>> I'd cite ruby as an indication that it shouldn't have to inflict any
>> performance hit
>*boggle*. That's classic. Ruby *is* a performance hit.
Would something less esoteric like Javascript be a better comparison?
Matt
> On Wed, Sep 27, 2000 at 12:31:25PM -0700, Matt Youell wrote:
> > Would something less esoteric like Javascript be a better comparison?
>
> Not really. Perl and JavaScript have very little in common, despite what
> members of this list would like to do.
>
I w
> On Wed, Sep 27, 2000 at 12:16:36PM -0700, Matt Youell wrote:
> > I open to hearing your reasons. The biggest reason it wasn't withdrawn
is
> > because someone said "hey don't do that, here's why". So give me a "why"
> > already...
16 matches
Mail list logo
