> 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 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
> 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...
Steve Fink wrote:
>
> But then what does my $x = BlueFoo->new(); print
> "$x" do, assuming there is a BlueFoo::STRINGIFY? Print
> "BlueFoo=HASH(0x0b38134)"?
The current thinking it to preserve the default behavior, which would be
to print out the ref info, UNLESS there is a STRING function. That
Matt Youell wrote:
>
> Originally I was trying to avoid explicit typing through new keywords, like
> 'int'. So the latter option would have been the case. But after Nathan
> Wiger's reply to my RFC, I realized that either syntax would work. Under one
> scenario, 'int', as in your example, would si
At 11:28 AM 8/28/00 -0700, Steve Fink wrote:
>Dan Sugalski wrote:
> >
> > If the vtable stuff goes into the core perl engine (and it probably will,
> > barring performance issues), then what could happen in the
> >
> > my Foo $bar;
> >
> > case would be that all the vtable functions for Foo are
Dan Sugalski wrote:
>
> If the vtable stuff goes into the core perl engine (and it probably will,
> barring performance issues), then what could happen in the
>
> my Foo $bar;
>
> case would be that all the vtable functions for Foo are taken as specially
> named subs/methods in the Foo packag
On Sun, 27 Aug 2000 06:14:00 -0700, Matt Youell wrote:
>So an int gets stored as two bytes and not
>four or eight.
Gee, I thought it was more like 30. The savings in bytes don't look too
impressive in this case. 4 byte addition is as fast as 2 byte addition
on most pmodern platforms -- and you
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
Matt Youell wrote:
>
> > 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)
> 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
Nathan Torkington wrote:
>
> Do you mean that when we write:
>
> my int $intVal = 0;
>
> it gets turned into OO stuff?
Yeah, that's the thinking.
> my int $intVal = 0;
>
> any more?
No, egads!
> I'd rather than any "variables are represented by objects" magic
> be done behind the
Nathan Torkington wrote:
>
> Are you proposing making even "normal" scalar, hash, and array access
> go through these methods? Wouldn't that slow everything way down?
Glad you brought this up, Nat!
I would say "yes and no". The reason I'd say this is because Dan S. and
the internals guys are d
On Sun, 27 Aug 2000, Nathan Torkington wrote:
> Perl6 RFC Librarian writes:
> > For example, rather than:
> >
> > my int $intVal = 0;
> >
> > you would say:
> > my $intVal = 0;
> > $intVal->asInt;
> > Or possibly even:
> > my $invVal->asInt = 0;
> > for simplicity.
>
> Do you mean that whe
Nathan Wiger writes:
> 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
> are done throught STORE(), and context checking is done on access. So I
> was picking at details.
Are you proposing making
Matt Youell writes:
> As I think about this, however, I can imagine that some might want to force
> it's use. Perhaps that requirement could be built into a strict pragma, like
> 'use StrictTypes' ?? I seem to recall an RFC along those lines.
My idea for
use strict 'types';
is that Perl requi
Perl6 RFC Librarian writes:
> For example, rather than:
>
> my int $intVal = 0;
>
> you would say:
> my $intVal = 0;
> $intVal->asInt;
> Or possibly even:
> my $invVal->asInt = 0;
> for simplicity.
Do you mean that when we write:
my int $intVal = 0;
it gets turned into OO stuff? Or do
> > 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. =^)
:-)
> To clarify: Methods such as 'asInt()' could be ignored at will. If they were
> never called, Perl would still Do The Right Thing. So, totally
> 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
[this might have been missed for those following threads, so reposting]
> Everything in Perl becomes an object, using existing object-syntax. Out of
> plain sight, there would be essentially three base classes: Scalar, List,
> and Hash.
Arg! You beat me to it. :-) This was the next RFC on my lis
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
OO Integration/Migration Path
=head1 VERSION
Maintainer: Matt Youell <[EMAIL PROTECTED]>
Date: 25 Aug 2000
Last Updated: 27 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number: 161
=hea
22 matches
Mail list logo
