Matt Youell wrote:
>
> > 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
> fai
On Tue, Aug 29, 2000 at 11:04:26PM -0400, Michael Maraist wrote:
> First greatly stylistic compatibilty. An inexperienced programmer would
> see:
> my Dog $spot = "Spot";
>
> And become confused. It's totally unintuitive (at least so far as other
> mainstream OO languages go). It looks like Do
> 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
- Original Message -
From: "Perl6 RFC Librarian" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, August 29, 2000 10:19 PM
Subject: RFC 171 (v1) my Dog $spot should call a constructor implicitly
> my Dog $spot should call a constructor implicitly
>
>
> T
> my Dog $spot = Dog->new();
>
> Provided this RFC is adopted, this call can be changed to:
>
> my Dog $spot = "Spot";
I like it, lots. This melds very well with RFC 159 and 161. Very cool.
> my Dog $spot = "Spot";
>
> would be transformed to, or be the equivalent of:
>
> $spo
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
my Dog $spot should call a constructor implicitly
=head1 VERSION
Maintainer: Michael Fowler <[EMAIL PROTECTED]>
Date: 29 August 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 1
> 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
"Randal L. Schwartz" wrote:
>
> That's my first gut reaction to this proposal. "If you like Python,
> you know where to find it, but let us have some primitive data types
> in Perl that act primitive so we can optimize things."
Well, we're on a border here. What this RFC is really referring to
> "Nathan" == Nathan Wiger <[EMAIL PROTECTED]> writes:
Nathan> Then we can write really flexible code that looks just like my
Nathan> "religion" wants it to!
Nathan>checktosee [ $NEED eq 'HASH' ] /*
Nathan> var )name assign )DEFAULT ORNEXT
Nathan> $IAMALIVE-member-getName
> "Nathan" == Nathan Torkington <[EMAIL PROTECTED]> writes:
Nathan> Are you proposing making even "normal" scalar, hash, and array access
Nathan> go through these methods? Wouldn't that slow everything way down?
That's my first gut reaction to this proposal. "If you like Python,
you know w
Piers Cawley wrote:
>
> And the RFC then proceeds to ignore this point and proposes something
> that looks remarkably similar to the current overloading scenario. Or
> am I missing something? I really can't see where the win is with this
> proposition.
The win is that this allows us to embed obj
Nathan Wigner in the guise of Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> You can use facilities such as C to help fix this issue, but
> C is limited and slow. You can also overload operators, but
> this is not flexible enough for many applications since it applies
> to a package (and not in
12 matches
Mail list logo
