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. :)
> >
> >
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++
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 vetables,
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
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
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
>
>
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> obscu
> "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
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
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 Perl
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 co
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?
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 sh
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
>
> > 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
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 i
[EMAIL PROTECTED] wrote:
> "Any sufficiently encapsulated hack is no longer a hack."
Who said that? I think it's wrong.
Any sufficiently encapsulated hack is no longer a *naked* hack. So what.
> You shouldn't be relying on an object's reference. ref $obj eq
> 'Some::Class' wrecks subclassin
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!
http://w
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::Cla
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 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
>
>
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
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.
Wo
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 do
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 h
"You are to chop down the largest tree in the forest with... A HERRING!"
I've been following this whole per-object inheritance thing, .ISA,
etc... and one thing keeps coming to mind.
Why does this have to be in the core language?
First, its a relatively obscure feature. Per-object inherita
26 matches
Mail list logo
