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... I
"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 is
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 everyone
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
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
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 package. So,
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 taken as
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 simply
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
[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 list.
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
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
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! violent vomiting
I'd rather than any "variables are represented by objects" magic
be done
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
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 you mean
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
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) is to avoid
Dan Sugalski writes:
If the vtable stuff goes into the core perl engine (and it probably will,
barring performance issues), then what could happen in the
I have a lot of questions. Please point me to the appropriate place
if they are answered elsewhere.
vtables are tables of C functions?
On Sun, 27 Aug 2000, Nathan Torkington wrote:
Dan Sugalski writes:
If the vtable stuff goes into the core perl engine (and it probably will,
barring performance issues), then what could happen in the
I have a lot of questions. Please point me to the appropriate place
if they are
19 matches
Mail list logo
