Dan Sugalski wrote:
At 11:01 AM 7/10/2001 -0400, Adam Turoff wrote:
And where's the guarantee that vtbls are per-object and not per-class?
VTABLES ARE PER OBJECT.
So mote it be. :)
Dan
What? Up until now it's been vtable-pointers are
At 11:24 AM 7/11/2001 -0500, David L. Nicol wrote:
Dan Sugalski wrote:
At 11:01 AM 7/10/2001 -0400, Adam Turoff wrote:
And where's the guarantee that vtbls are per-object and not per-class?
VTABLES ARE PER OBJECT.
So mote it be. :)
Dan
[EMAIL PROTECTED] wrote:
On Fri, Jun 29, 2001 at 09:50:55AM -0400, Dan Sugalski wrote:
Besides, there are languages that do this on a per-object basis all the
time anyway (aren't there? I think there are) in which case it makes sense
to yank it into the core interpreter, as it'll be
[EMAIL PROTECTED] wrote:
Anyhow, if you want Perl 6 objects to be able to act as if they're in
their own class (ie. have their own methods, inheritance, etc...) how
are you going to do this without having the moral equivalent of a
stash associated with it? And if you can do something that
On Tue, Jul 10, 2001 at 02:08:58AM -0500, David L. Nicol wrote:
Uh, C++ virtual methods can be overloaded on a per-object basis, not
just a per-class basis, since the object drags around its virtual jump
table with it wherever it goes, so the jump can get compiled into
jump to the address
At 11:01 AM 7/10/2001 -0400, Adam Turoff wrote:
And where's the guarantee that vtbls are per-object and not per-class?
VTABLES ARE PER OBJECT.
So mote it be. :)
Dan
--it's like this---
Dan Sugalski
Not quite authoritative, I'm afraid. :) I'm looking at the new edition
of the Stroustroup book, and the very existence of vtables is an
implementation detail not guaranteed by the language spec (now that
there actually is a language spec for C++). Further, in the example
which mentions
At 02:10 PM 7/10/2001 -0400, Mark J. Reed wrote:
Not quite authoritative, I'm afraid. :) I'm looking at the new edition
of the Stroustroup book, and the very existence of vtables is an
implementation detail not guaranteed by the language spec (now that
there actually is a language spec for C++).
Adam Turoff wrote:
And what's the linguistic hook that allows C++ object-based inheritance?
And where's the guarantee that vtbls are per-object and not per-class?
Z.
You're right, it might be a side effect of a particular implementation of
virtual methods. But AIUI that implementation is
Adam Turoff wrote:
On Tue, Jul 10, 2001 at 02:08:58AM -0500, David L. Nicol wrote:
Uh, C++ virtual methods can be overloaded on a per-object basis, not
just a per-class basis, since the object drags around its virtual jump
table with it wherever it goes, so the jump can get compiled into
On Fri, Jun 29, 2001 at 08:59:59AM -0400, John Porter wrote:
Michael G Schwern wrote:
Second, and perhaps more importantly, we can do this perfectly well
with a module. No hacks, no tricks, no filters.
Class::Object uses the mini-class technique (ie. auto-generated
classes
Sorry,
Before we get too far into details here, this is the real point I'm
trying to make.
The set of Perl 6 module authors will be much greater than the set of
Perl 6 core programmers (again, same in Perl 5). The more Perl 6
things we can shove out into modules, the less work we have to do on
the
On Sun, Jul 01, 2001 at 01:07:59AM -0400, Dan Sugalski wrote:
*bu* false logic. If you can do something via a core module, it
is supported by Perl. Or does Perl not do CGI, web stuff, databases,
etc...?
Wrong--you may have a terrifically hard time using perl modules to provide
s == schwern [EMAIL PROTECTED] writes:
Wrong--you may have a terrifically hard time using perl modules to
provide functions for non-perl languages that the interpreter
supports. It may not help Python, or Ruby, for example, that libnet
or its equivalent are provided as part of perl
On Sun, Jul 01, 2001 at 04:08:24PM -0400, Uri Guttman wrote:
my translation:
some features in other languages require core level support if perl6
will be able to emulate or interact with them.
Huh??
s There's two things in combination going on here. 1) The feature is
s obscure. 2)
Having it in the core, in C[++], would be that much more efficient,
and that much less of a hack. Maybe the tradeoff is that it
wouldn't work. :-)
Everyone's making these assumptions, WHY WON'T ANYONE LOOK AT
CLASS::OBJECT?!
It might not work, Schwern. And even if it did, it might be
On Sat, Jun 30, 2001 at 01:47:39AM -0600, Dan Brian wrote:
Having it in the core, in C[++], would be that much more efficient,
and that much less of a hack. Maybe the tradeoff is that it
wouldn't work. :-)
Everyone's making these assumptions, WHY WON'T ANYONE LOOK AT
At 04:20 AM 6/30/01 -0400, [EMAIL PROTECTED] wrote:
On Sat, Jun 30, 2001 at 01:47:39AM -0600, Dan Brian wrote:
Everyone's making these assumptions, WHY WON'T ANYONE LOOK AT
CLASS::OBJECT?!
It might not work, Schwern. And even if it did, it might be really slow.
Somebody should write
At 07:12 PM 6/29/2001 -0400, Michael G Schwern wrote:
Please look at Class::Object before responding. URL below.
On Fri, Jun 29, 2001 at 06:36:31PM -0400, John Porter wrote:
[EMAIL PROTECTED] wrote:
Any sufficiently encapsulated hack is no longer a hack.
Who said that? I think it's
At 04:54 PM 6/29/2001 -0400, [EMAIL PROTECTED] wrote:
On Fri, Jun 29, 2001 at 09:50:55AM -0400, Dan Sugalski wrote:
Besides, there are languages that do this on a per-object basis all the
time anyway (aren't there? I think there are) in which case it makes sense
to yank it into the core
Michael G Schwern wrote:
Second, and perhaps more importantly, we can do this perfectly well
with a module. No hacks, no tricks, no filters.
Class::Object uses the mini-class technique (ie. auto-generated
classes
Sorry, that sounds like a hack/trick if ever there was one.
I would sure hope
At 10:32 PM 6/28/2001 -0400, Michael G Schwern wrote:
The rule of thumb has always been if you can do it in a module, don't
put it in the core. Well, we can do it in a module. Work on the
module, don't complicate the core.
Doing it properly in a module is significantly more of a pain than
Dan Sugalski writes:
Doing it properly in a module is significantly more of a pain than doing it
in the core. Faking it with a module means a fair amount of (reasonably
slow) perl code, doing it in the core requires a few extra lines of C code
in the method dispatch opcode function.
At 07:53 AM 6/29/2001 -0600, Nathan Torkington wrote:
Dan Sugalski writes:
Doing it properly in a module is significantly more of a pain than
doing it
in the core. Faking it with a module means a fair amount of (reasonably
slow) perl code, doing it in the core requires a few extra lines
On Fri, Jun 29, 2001 at 08:59:59AM -0400, John Porter wrote:
Michael G Schwern wrote:
Second, and perhaps more importantly, we can do this perfectly well
with a module. No hacks, no tricks, no filters.
Class::Object uses the mini-class technique (ie. auto-generated
classes
Sorry,
On Fri, Jun 29, 2001 at 09:50:55AM -0400, Dan Sugalski wrote:
At 10:32 PM 6/28/2001 -0400, Michael G Schwern wrote:
The rule of thumb has always been if you can do it in a module, don't
put it in the core. Well, we can do it in a module. Work on the
module, don't complicate the core.
On Fri, Jun 29, 2001 at 04:42:57PM -0400, [EMAIL PROTECTED] wrote:
It's also not without its faults. Having every instance of a
class have different values of ref() could be obnoxious, for
example.
Why? You shouldn't be relying on an object's reference. ref $obj eq
'Some::Class'
On Fri, Jun 29, 2001 at 12:59:32PM -0800, Michael Fowler wrote:
If you're relying on an overload isa() method to determine if something
belongs to a given class you're going to run into problems.
There's no overloads, I never touched isa()! It all just works!
LOOK AT CLASS::OBJECT!
Please look at Class::Object before responding. URL below.
On Fri, Jun 29, 2001 at 06:36:31PM -0400, John Porter wrote:
[EMAIL PROTECTED] wrote:
Any sufficiently encapsulated hack is no longer a hack.
Who said that? I think it's wrong.
Me.
Any sufficiently encapsulated hack is no
29 matches
Mail list logo
