> I have a pretty primitive idea in my head: suppose a Taxi object has
> multiple inheritance, it inherits from both a Car and a Driver... So a
> Taxi is both a Car and a Driver. But shouldn't you also make this that a
> Taxi is a Car that also *contains* a Driver, instead of *being* o
On Mon, 18 Sep 2000 13:26:45 -0700, Glenn Linderman wrote:
>> Read RFC 241 for a brief overview of pseudo-hash problems.
>
>I've already read RFC 241. Re-reading in this context results in the following
>comments/quests for information. The remaining quotes here come from RFC 241...
>
>>
On Mon, 18 Sep 2000, Glenn Linderman wrote:
> This is an interesting comment to be made about an interesting side effect of
> this proposal.
[snip]
> (1) array elements can be accessed by name
> (2) member data can be looked up quicker (by array index, rather than by
> hashed name)
[snip]
> new
All-
As the sublist chair, I politely ask you to please table this
discussion. Time is running short and this is really a digression.
Glenn, if you have a proposal, please put one together in RFC format and
post it to -objects.
-Nate
Michael G Schwern wrote:
> I guess I'm trying to say something about micro-optmizations being
> more trouble than they're worth and usually hurt more than they help.
>
> > So let's posit you've cured the accessor overhead problem. Now
> > we're left with set_const being 40% slower for hash, and
On Mon, Sep 18, 2000 at 01:26:45PM -0700, Glenn Linderman wrote:
> Michael G Schwern wrote:
> > Similar mistaken logic leads to "globals are faster than lexicals".
>
> Maybe so, but I'd think lexicals would be faster, because more of
> the lookup is done at compile time rather than runtime... so
Michael G Schwern wrote:
> Similar mistaken logic leads to "globals are faster than lexicals".
Maybe so, but I'd think lexicals would be faster, because more of the lookup is
done at compile time rather than runtime... so I'm not sure what is similar
about the mistaken logic... for arrays, more
On Mon, Sep 18, 2000 at 01:02:31PM -0700, Glenn Linderman wrote:
> OK, thanks for the info. I'm not an internals guy, but I guess I
> should have written the benchmark. It just _seemed_ they should be
> slower, because there is more work to do the hashing. The actual
> lookup, I agree, should b
Michael G Schwern wrote:
> On Mon, Sep 18, 2000 at 11:01:12AM -0700, Glenn Linderman wrote:
> > One of the big complaints about today's perl objects is their slowness at
> > accessing member data, which is a direct result of hashes being used as the
> > base data type for the underlying member da
On Mon, Sep 18, 2000 at 11:01:12AM -0700, Glenn Linderman wrote:
> One of the big complaints about today's perl objects is their slowness at
> accessing member data, which is a direct result of hashes being used as the
> base data type for the underlying member data items.
The speed differences b
Perl6 RFC Librarian wrote:
> Which again, can be used in the appropriate contexts. Note this allows
> you to maintain arrayref objects automatically as well:
>
>package Johnson;
>sub new {
>my $class = shift;
>my $self = [];
>$self->[0]->[2]->[3] :raccess('size') =
On Sun, Sep 17, 2000 at 11:25:49PM -0700, Nathan Wiger wrote:
> > I also don't see that the optimization of one half of the accessor vs
> > the other is worth the trouble.
>
> Well, it depends on how much faster the autoaccessor is. If it is much
> faster, and you need to access a whole bunch of
> How about also just ":access" to do both? It would seem to be the
> most common case.
I was trying to conserve keywords, but I'm not opposed to this.
> > =head2 Mixing autoaccessors and real subs
> >
> I really don't see how this is necessary. If you have to write a
> custom accessor, you m
On Mon, Sep 18, 2000 at 04:58:45AM -, Perl6 RFC Librarian wrote:
> =head2 Combining attributes
>
> You can, of course, combined the C<:laccess> and C<:raccess> attributes
> on a given key to autogenerate accessors that work in both C and
> C contexts, if you simply want to hide your data.
Ho
Matthew, take a look at Class::Classless.
Damian
On Sun, 17 Sep 2000, Perl6 RFC Librarian wrote:
> This example shows how much easier it would have been to write the
> example on line 170 of perltoot.pod:
>
> package Person;
> use strict;
>
> ##
> ## the object constructor (simpli
16 matches
Mail list logo
