Re: Per-object inheritance in core a red herring?
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 > >What? Up until now it's been vtable-pointers are per-object. They are. Who says they need to share what's pointed to? That's a space and creation time optimization. :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Per-object inheritance in core a red herring?
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 per-object.
Re: Per-object inheritance in core a red herring?
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 > > "jump to the address that is bytes away from the start of > > the object that is doing the method" which is pretty light, unless > > you've got dozens of virtual methods. > > 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. Apparently I was basing my statements on an incorrect understanding. According to a recent C++ reference, http://www.icce.rug.nl/docs/cplusplus/cplusplus16.html#l269 > A common implementation is the following. An object containing virtual > functions holds as its first data member a hidden field, pointing > to an array of pointers holding the addresses of the virtual functions. > It must be noted that this implementation is compiler-dependent, > and is by no means dictated by the C++ ANSI definition. > > The table of addresses of virtual functions is shared by all objects of > the class. It even may be the case that two classes share the same > table. The overhead in terms of memory consumption is therefore: > > One extra pointer field per object, which points to: > > One table of pointers per (derived) class to address the virtual functions. At this time, I do not know if I actually worked with a compiler that implemented virtuals per-object, ot if I just thought that that was how it did it. Anyway, the scheme I described would be one way to do per-object method overloading. Letting the method that is supposed to be overridable on a per-object basis look up the object that is calling the method in a table keyed with object pointers might be lighter than keeping a field in every object -- it would depend what fraction of the objects of the type would get overloaded and how many would keep the default, and the memory vs. speed trade-off. I do not think the language needs additional cruft to support this; I think it would be better handled in the implementation of the accessor functions. Wait for better tieing and reimplement. -- David Nicol 816.235.1187
Re: Per-object inheritance in core a red herring?
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 universal. . g++ 2.95.2 apparently won't let me do it, &d.virtmeth = gives me a compiler error vdem.cpp:43: taking the address of a bound member function vdem.cpp:43: to form a pointer to member function, say `&demo::virtmeth' which seems to imply that g++ is using a per-class virt table, so I'm wrong. -- David Nicol 816.235.1187 "Perl was born in downtown Hell!" -- Matt Youell
Re: Per-object inheritance in core a red herring?
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++). Further, in the example >which mentions vetables, each object has a pointer to a vtable which is shared >by the entire class. > >Which is not to say that it couldn't be moted so for Perl . . . I was moting it for perl. Alas, reading comprehension doesn't seem to be a requirement for the internals design chair and I missed the rather important language distinction in the original message... :( >On Tue, Jul 10, 2001 at 01:44:35PM -0400, 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 --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Per-object inheritance in core a red herring?
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, each object has a pointer to a vtable which is shared by the entire class. Which is not to say that it couldn't be moted so for Perl . . . On Tue, Jul 10, 2001 at 01:44:35PM -0400, 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 > > --"it's like this"--- > Dan Sugalski even samurai > [EMAIL PROTECTED] have teddy bears and even > teddy bears get drunk -- Mark J. REED<[EMAIL PROTECTED]>
Re: Per-object inheritance in core a red herring?
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 even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Per-object inheritance in core a red herring?
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 that is bytes away from the start of > the object that is doing the method" which is pretty light, unless > you've got dozens of virtual methods. 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.
Re: Per-object inheritance in core a red herring?
[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 saves
> memory on object inheritance, why not apply it to class inheritance?
what if there was a core shortcut that hid the virtual methods -- the
selecte methods that are allowed to be overridden on a per-object basis
just like in C++
Without the core shortcut, you'd have:
package moderatable_fido;
sub new{
my $self = {};
$self->{sound} = \&dobark;
bless $self;
};
sub dobark { print "Woof!\n" }
sub bark { goto &{$_[0]->{sound}} }
incorporating such a declared virtual into Class::Object -- is it there
already?
--
David Nicol 816.235.1187
"Perl was born in downtown Hell!" -- Matt Youell
Re: Per-object inheritance in core a red herring?
[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 supporting more than just > > perl. > > *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...? > > Anyhow, Self is the only one I can think of. ALL THE FULL-TIME SELF > PROGRAMMERS HERE, PLEASE RAISE THEIR HANDS! ;) 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 that is bytes away from the start of the object that is doing the method" which is pretty light, unless you've got dozens of virtual methods. In practice, they get overloaded in aggregate, but the constructors have to fill those values in, and they have names, and they can be explicitly altered, if you want to have one widget that frobs differently from all the other widgets you can set that up without devising another class. C++ I'm talking about here. -- David Nicol 816.235.1187 "Perl was born in downtown Hell!" -- Matt Youell
Re: Per-object inheritance in core a red herring?
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, that sounds like a hack/trick if ever there was one. > I would sure hope there would be a cleaner way to do it in > perl6, if it's not part of the core language. Maybe, but I think it is the way to do it, even if it is behind the scenes. My reason for that is method lookup. Right now we use the package (class) stash as a cache so we don't have to search @ISA for every method call. But if there is a case where not all objects that inherit from a given class have the same superclasses, you cannot do this. This means that we will either burn a lot more memory for the caches or method lookup will take longer. > It's also not without its faults. Having every instance of a > class have different values of ref() could be obnoxious, for > example. That could be preserved by the object holding a pointer to it's blessed stash and its method stash, which for the most case will be the same. Graham.
Re: Per-object inheritance in core a red herring?
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) The feature is easy and fairly efficient to implement > s> outside of Perl 6. That's the rough criterion I'm using for > s> determining if something should or should not be in the core. > > i disagree. that is too arbitrary. there are advantages and > disadvantages to having things in the core vs. a module. the decision > should be made on a feature by feature basis. look at damian's switch > stuff. it works as a (source filtered) module now but it would obviously > be better as a builtin. Yes, Switch.pm is a perfect example. It should go into the core. Its neither #1 (obscure) nor #2 (easy and efficient to implement as a module). Anything that requires source filters ain't easy (or safe). Please, I don't want to start arguing about little nitty details and exceptions. I'm also not holding up these two simple rules and say "THIS SHALL BE THE WHOLE OF THE LAW!" These are just the heuristics I'm using. I'm just trying to ease the amount of core work we'll have to do else Perl 6 will never get done. This particular feature we can do later if we need it. -- Michael G Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Re: Per-object inheritance in core a red herring?
> "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 6. s> Huh?? my translation: some features in other languages require core level support if perl6 will be able to emulate or interact with them. s> There's two things in combination going on here. 1) The feature is s> obscure. 2) The feature is easy and fairly efficient to implement s> outside of Perl 6. That's the rough criterion I'm using for s> determining if something should or should not be in the core. s> Curried functions, AFAIK, only have the first trait. Then again, I s> really don't understand curried functions. If it turns out they have s> both traits, maybe we should relegate them to a core module instead. i disagree. that is too arbitrary. there are advantages and disadvantages to having things in the core vs. a module. the decision should be made on a feature by feature basis. look at damian's switch stuff. it works as a (source filtered) module now but it would obviously be better as a builtin. then you can have better parser support, tighter integration with the op code dispatcher (a switch op code may refer directly to other op codes. a perl module couldn't easily do that), etc. other features are on the fence. we have heard requests for all the socket stuff (getby*, socket, etc.) to be made into a module. it would be a core module, and maybe (invisibly) autoloaded. it may be mostly in (inline) c. but there are benefits to having it in the core as it will interact with the event loop and op code dispatching and signals, etc. so let's not get into a war on core or not for modules. it will depend on how each one wants to interact with the core and parser. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com Learn Advanced Object Oriented Perl from Damian Conway - Boston, July 10-11 Class and Registration info: http://www.sysarch.com/perl/OOP_class.html
Re: Per-object inheritance in core a red herring?
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 > 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 6. Huh?? > >Anyhow, Self is the only one I can think of. ALL THE FULL-TIME SELF > >PROGRAMMERS HERE, PLEASE RAISE THEIR HANDS! ;) > > So? Find all the folks that use languages that provide curried functions > full-time. There's two things in combination going on here. 1) The feature is obscure. 2) The feature is easy and fairly efficient to implement outside of Perl 6. That's the rough criterion I'm using for determining if something should or should not be in the core. Curried functions, AFAIK, only have the first trait. Then again, I really don't understand curried functions. If it turns out they have both traits, maybe we should relegate them to a core module instead. -- Michael G Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Re: Per-object inheritance in core a red herring?
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 6 core. (This is true of Perl 5 as well). Less work we need
in the core, the faster we will see a working Perl 6.
I'm trying to cut/defer features. If you've got something that can be
98% done as a module, that's good enough. Leave it out of the core,
or work on it if we happen to have time. And in this case, we can
always put it into perl 6.0.1 (since there's no issue of breaking
perl5 compatibility).
Its the surest way to shorten a project's schedule. Cut features.
On Sun, Jul 01, 2001 at 01:00:09AM -0400, Dan Sugalski wrote:
> > > > "Any sufficiently encapsulated hack is no longer a hack."
>
> Well, you're wrong--it's still a hack. The encapsulation just makes it
> possible to remove the hack and replace it with something less hackish at
> some point later. (Yeah, I know--like that ever happens with software...)
Thank you, that's my point exactly. Its all about the relatively of
hackmanship. To take a recent example...
sub new {
my($class) = @_;
@{$class.'::ISA'} = $class.'::__multi';
@{$class.'::__mutli::ISA'} = qw(Employee Person);
return bless {}, $class.'::__multi';
}
That's a hack. But if we do this...
sub new {
my($class) = @_;
return multibless {}, qw(Employee Person);
}
Wow! The hack is gone! Its not gone, we just smeared a layer of
abstraction over it. But from the user's perspective, the hack is
gone.
But I digress.
> >They're NO SLOWER than normal objects, it uses all the normal OO
> >channels, it was very simple and small to implement and it WORKS!
> >Now, right this second, with perl 5.
>
> There are space costs involved here that aren't obvious.
(Of course, you're going to make stashes really light-weight in Perl
6, RIGHT?! ;)
There's a way around that. If you make every single object into its
own class its gets nasty and fat.
# $foo is a daughter of $obj.
my $foo = $obj->new;
If instead you make them siblings of each other...
# $foo is a sibling (ie. the same class) as $obj.
my $foo = $obj->new;
Things stay nice and trim, almost no memory difference (since we're
not constantly creating new classes and stashes). Then you have a
special constructor to create daughter objects...
my $daughter = $obj->new_daughter;
The problem with this approach is now siblings can effect each other,
it no longer works as if each object is in its own class.
my $sibling = $obj->new;# assuming new() creates siblings
$sibling->sub('foo', sub { return 42 });
print $obj->foo;# 42
Instead of only parents effecting their children
my $daughter = $obj->new; # assuming new() creates daughters
$obj->sub('foo', sub { return 23 });
print $obj->foo;# 23
print $daughter->foo; # 23
$daughter->sub('foo', sub { return 42 });
print $obj->foo;# 23
print $daughter->foo; # 42
I don't know if this is good or bad, not really knowing how this
technique is typically applied. I suppose I could just make two
versions/subclasses of Class::Object to try it out. If anyone has
used object inheritance in the past, let me know the ins and outs.
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 saves
memory on object inheritance, why not apply it to class inheritance?
> Having separate classes for the threaded and unthreaded versions of
> an object seem silly, as does the case where an object changes class
> merely because some of the methods behave slightly
> differently. (Should a disk-backed object look like a different
> class than a non-disk-backed object if they behave identically to
> the program?)
This is OO 101. Yes, the disk vs non-disk should be different
classes, but they should share a common parent class/interface. But
that's just internal details. They're *different* but they *look the
same*.
my $obj = Foo->new;
Is $obj really of class Foo? Could it be Foo::Disk or Foo::NonDisk?
It could be anything, but at least we know its a subclass of Foo that
will act like any other Foo object. This is your basic factory
pattern.
When you get into object inheritance you're doing exactly the same
thing, terminology just changes. Instead of having Foo::NonDisk and
Foo::Disk classes, you might have parental $foo_disk and $foo_nondisk
objects from which you derive sub-objects which then inherit their
overridden me
Re: Per-object inheritance in core a red herring?
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 interpreter, as it'll be supporting more than > just > > perl. > >*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 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 6. Core functionality is universal and essentially atomic functionality. Things provided in modules won't necessarily be either. >Anyhow, Self is the only one I can think of. ALL THE FULL-TIME SELF >PROGRAMMERS HERE, PLEASE RAISE THEIR HANDS! ;) So? Find all the folks that use languages that provide curried functions full-time. That a particular behaviour's not often used doesn't make that behaviour bad or less than useful. It may just be an indication that either it's poorly understood, or not implemented in a language that many people use. (Of course it may be an indication that the feature's lame, but not one I'd use as a primary) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Per-object inheritance in core a red herring?
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 wrong. > >Me. Well, you're wrong--it's still a hack. The encapsulation just makes it possible to remove the hack and replace it with something less hackish at some point later. (Yeah, I know--like that ever happens with software...) >They're NO SLOWER than normal objects, it uses all the normal OO >channels, it was very simple and small to implement and it WORKS! >Now, right this second, with perl 5. There are space costs involved here that aren't obvious. Each package has its own stash, and every method call you make on an object in that package puts a cached entry to that method into the stash. In perl 5, that's a full GV per unique method. Plus the extra time overhead to populate the cache--not a huge hit, but not free. With perl 6, you'll also see a rather significant space cost, as every package that has objects blessed into it will end up with a full vtable. I'm not sure how big that'll be, but I expect it'll add another 2K per package. (Plus the time to build the vtable on first bless) Granted neither set of costs is exorbitant, but generating the packages on the fly isn't free. For some applications of objects, this doesn't strike me as the appropriate way to approach things. Being able to alter the inheritance tree for an object on the fly or, more to the point, to be able to have two objects of the same class have different methods strikes me as a useful thing. You may have two groups of methods that are identical in name and signature but behave mildly differently. Having separate classes for the threaded and unthreaded versions of an object seem silly, as does the case where an object changes class merely because some of the methods behave slightly differently. (Should a disk-backed object look like a different class than a non-disk-backed object if they behave identically to the program?) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Per-object inheritance in core a red herring?
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 an implementation first, and then tackle efficiency. > >This is a joke, right? I'm on Candid Camera. I think people are just surprised that you didn't call it Red::Herring. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com
Re: Per-object inheritance in core a red herring?
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 > > CLASS::OBJECT?! > > It might not work, Schwern. And even if it did, it might be really slow. > Somebody should write an implementation first, and then tackle efficiency. This is a joke, right? I'm on Candid Camera. -- Michael G Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Re: Per-object inheritance in core a red herring?
> > 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 really slow.
Somebody should write an implementation first, and then tackle efficiency.
Something like
sub sub {
my ($self, $method_name, $method ) = @_;
*{ref($self).'::'.$method_name} = $method;
}
for adding object methods would be a good start. I think I'll call it
Class::Object.
Dan
Re: Per-object inheritance in core a red herring?
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 longer a *naked* hack. So what. As long as the hack has no effect outside its little bubble of encapsulation, its no longer a hack as far as the outside world is concerned. Its a simple matter of interface perspective. > > You shouldn't be relying on an object's reference. ref $obj eq > > 'Some::Class' wrecks subclassing, > > ref($a) eq ref($b). That's generally bad. Consider the following real world scenario: # Shop::Video represents a VHS, DVD or Laserdisc. $video = Shop::Video->new($video_id); So is ref $video eq 'Shop::Video'? Nope. Shop::Video->new() is a factory method. It returns either a Shop::Video::VHS, Shop::Video::DVD or Shop::Video::LD object depending on if the $video_id refers to a VHS, DVD or Laserdisc. Those are all Shop::Video subclasses, so they all have the same interface. The caller never has to know any of this. Factory methods are a common design pattern. There are other times when you might have to rebless objects into subclasses unbeknownst to the caller. Adaptor and Proxy design patterns can be easily implemented this way. $a->isa($some_class) && $b->isa($some_class) is the correct way to see if two objects have the same interface. > > What's the trade-off here? It works, its efficient, the hacks are > > well encapsulated. > > 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?! They're NO SLOWER than normal objects, it uses all the normal OO channels, it was very simple and small to implement and it WORKS! Now, right this second, with perl 5. I'll post the URL yet again... http://www.pobox.com/~schwern/src/Class-Object-0.01.tar.gz -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One conway: unit of mind expansion. One Conway == ~20 lines of Perl code found in $CPAN/authors/id/D/DC/DCONWAY, which gives the sensation of your brain being wrapped around a brick, with kiwi juice squeezed on top. -- Ziggy
Re: Per-object inheritance in core a red herring?
[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 subclassing, ref($a) eq ref($b). > What's the trade-off here? It works, its efficient, the hacks are > well encapsulated. 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. :-) -- John Porter
Re: Per-object inheritance in core a red herring?
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://www.pobox.com/~schwern/src/Class-Object-0.01.tar.gz There's really not much going on. > > > No, that's a lousy rule of thumb. The tradeoffs must be considered. > > > Otherwise we'd have Forth. (Or Lisp, ca. 1960.) > > > > What's the trade-off here? It works, its efficient, the hacks are > > well encapsulated. > > The reason the feature (object-level ISA) was suggested in the first place > was to solve the problem of multiple, pointless, only-there-to-set-@ISA, > classes to serve MI. How often is MI really used? Very often, for me anyway. But object-as-class isn't really about MI. You can solve the same problem using the technique Damian outlined, using a special MI bless() that generates a little class on the fly. > Would this solution greatly speed up MI? In terms of performance, it will be just as fast. In terms of programming time, it might make a certain set of problems easier. Having a way to do easy and fast delegation would help more IMHO. > Would it greatly reduce the speed and memory > efficiency of the large body of OO code that doesn't use MI? I don't see how, in the core or out. In fact, in the object-inheritance scheme of things, every single object has to carry around a bunch of information with it (what it inherits from, what methods it has, etc...). In essense, each object has to have its own symbol table (or whatever the moral equivalent is in Perl 6) and thus will be fatter than normal objects. Though it sounds like Dan might be able to pull tricks that will eliminate the need for this, at best they will be the same weight/speed as any other object. I can't see how they could possibly be slimmer or faster. -- Michael G Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Re: Per-object inheritance in core a red herring?
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' wrecks subclassing, $obj->isa('Some::Class') is the
> right way.
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. Several times
I've used UNIVERSAL::isa($obj, "Some::Class") to determine if $obj is both
an object and belongs to the specified class.
I suppose you could modify UNIVERSAL::isa to forward the call on to the
class, but at that point the hack is no longer well-encapsulated.
> > No, that's a lousy rule of thumb. The tradeoffs must be considered.
> > Otherwise we'd have Forth. (Or Lisp, ca. 1960.)
>
> What's the trade-off here? It works, its efficient, the hacks are
> well encapsulated.
The reason the feature (object-level ISA) was suggested in the first place
was to solve the problem of multiple, pointless, only-there-to-set-@ISA,
classes to serve MI. How often is MI really used? Would this solution
greatly speed up MI? Would it greatly reduce the speed and memory
efficiency of the large body of OO code that doesn't use MI? These
questions really haven't been answered, nor do I think they really can be at
this point (at least, not the latter two).
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: Per-object inheritance in core a red herring?
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.
>
> Doing it properly in a module is significantly more of a pain than doing it
> in the core.
I've already done it, it was easy. Adding in an object-based
inheritance system should be just as easy, I just need an interface.
$obj->parents(@other_objs) is a little clunky.
> Faking it with a module means a fair amount of (reasonably slow)
> perl code
Nope, it just uses Perl's own object/class system. Look at
Class::Object! Its really, really thin. Benchmark it, its no slower
than regular objects.
http://www.pobox.com/~schwern/src/Class-Object-0.01.tar.gz
> 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 supporting more than just
> perl.
*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...?
Anyhow, Self is the only one I can think of. ALL THE FULL-TIME SELF
PROGRAMMERS HERE, PLEASE RAISE THEIR HANDS! ;)
Like I said, classless OO is interesting and sometimes useful, but not
terribly so. I'd find it much more useful to put something like
object delegation ($obj->foo translates to $obj->{other_obj}->foo) and
Self-style 'slots' ($obj->foo translates to $obj->{foo}) into the
core. Doing THOSE sorts of things outside of the core are a
performance drag.
--
Michael G Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Re: Per-object inheritance in core a red herring?
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, that sounds like a hack/trick if ever there was one.
> I would sure hope there would be a cleaner way to do it in
> perl6, if it's not part of the core language.
"Any sufficiently encapsulated hack is no longer a hack."
Besides, that's EXACTLY what you're conceptually doing! Each object
acts like its a member of its own class. So you just implement it
that way.
> 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' wrecks subclassing, $obj->isa('Some::Class') is the
right way.
> > The rule of thumb has always been if you can do it in a module, don't
> > put it in the core.
>
> No, that's a lousy rule of thumb. The tradeoffs must be considered.
> Otherwise we'd have Forth. (Or Lisp, ca. 1960.)
What's the trade-off here? It works, its efficient, the hacks are
well encapsulated.
--
Michael G Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Re: Per-object inheritance in core a red herring?
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 of C code > > in the method dispatch opcode function. > >Wouldn't you do it by swapping out the dispatch entry in the vtable? Hadn't planned on having a dispatch entry in the vtable--I wasn't thinking it was really something worth localizing on a per-variable basis. Generally I've been trying to keep control flow out of vtables. Vtables are for data fetching/storing/manipulation. Opcodes are for control flow. Or so has gone my thinking. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Per-object inheritance in core a red herring?
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. Wouldn't you do it by swapping out the dispatch entry in the vtable? Nat
Re: Per-object inheritance in core a red herring?
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 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. 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 supporting more than just perl. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Per-object inheritance in core a red herring?
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 there would be a cleaner way to do it in perl6, if it's not part of the core language. It's also not without its faults. Having every instance of a class have different values of ref() could be obnoxious, for example. > The rule of thumb has always been if you can do it in a module, don't > put it in the core. No, that's a lousy rule of thumb. The tradeoffs must be considered. Otherwise we'd have Forth. (Or Lisp, ca. 1960.) -- John Porter
Per-object inheritance in core a red herring?
"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 inheritance isn't
something most people even know about much less can think of a good
way to use. Before the Self crowd carves me up for dog food, it
doesn't mean its not an interesting and useful feature, it means its
unlikely to get used much. Compared to, say, threading.
Second, and perhaps more importantly, we can do this perfectly well
with a module. No hacks, no tricks, no filters. Class::Classless is
one implementation (complete, but a little convoluted), Class::Object
is another (cleaner, but not complete yet).
Class::Object uses the mini-class technique (ie. auto-generated
classes that aren't much more than an @ISA and a place to stick
methods) which is fine. In fact, its wonderfully elegant! Since they
work entirely within perl's OO system *without* an autoloader, they're
just as efficient as any other object. Object inheritance can be
gotten simply by manipulating @{ref $obj.'::ISA'} (encapsulated, of
course). One class, one object. It works, its efficient, it uses
existing syntax.
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.
PS It also means we don't have to wait two years for Perl 6 to be able
to use it!
PPS A Class::Object proof-of-concept is en route to CPAN.
http://www.pobox.com/~schwern/src/Class-Object-0.01.tar.gz if its not
there yet.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
List context isn't dangerous. Misquoting Gibson is dangerous.
-- Ziggy
