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 Clvalue and
Crvalue contexts, if you simply want to hide your data.
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 might as
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 data
I doubt anyone's arguing that they're not function calls. What I find
"surprising" is that Perl doesn't DWIM here. It doesn't encourage data
encapsulation or try to make it easy:
my $weather = new Schwern::Example;
print "Today's weather will be $weather-{temp} degrees and sunny.";
On Mon, Sep 18, 2000 at 05:49:28AM -, Perl6 RFC Librarian wrote:
Here's where the problem lies. Even though we now have a subclass
of Frog, the Forest class is still referencing the original Frog
class and not Frog::Japanese.
The DBI has this very problem! DBI-connect() returns DBI::db
my $weather = new Schwern::Example;
print "Today's weather will be $weather-{temp} degrees and sunny.";
print "And tomorrow we'll be expecting ", $weather-forecast;
You are wicked and wrong to have broken inside and peeked at the
implementation and then relied
[From DBI-connect()]
# XXX this is inelegant but practical in the short term, sigh.
if ($installed_rootclass{$class}) {
$dbh-{RootClass} = $class;
bless $dbh = $class.'::db';
my ($outer, $inner) = DBI::_handles($dbh);
bless $inner = $class.'::db';
Michael G Schwern [EMAIL PROTECTED] writes:
On Thu, Sep 14, 2000 at 02:19:38PM +0100, Piers Cawley wrote:
Michael G Schwern [EMAIL PROTECTED] writes:
package Dog;
use fields qw(this night up);
my Dog $ph = [];
$ph-{this} = "that";
That works? I thought you
Damian Conway [EMAIL PROTECTED] writes:
Piers wrote:
I'm kind of tempted to look at adding another pragma to go with 'use
base' along the lines of:
use implements 'Interface';
Which is almost entirely like Cuse base 'Interface' but with
'Interface'
On Mon, Sep 18, 2000 at 09:48:27AM +0100, Piers Cawley wrote:
Michael G Schwern [EMAIL PROTECTED] writes:
Nope. fields::new() basically just does Cbless
[\%{"$class\::FIELDS"}], $class, but the current pseudohash
implementation doesn't care if something is an object or not. It just
On 9/18/00 3:44 AM, Damian Conway wrote:
my $weather = new Schwern::Example;
print "Today's weather will be $weather-{temp} degrees and sunny.";
print "And tomorrow we'll be expecting ", $weather-forecast;
You are wicked and wrong to have broken inside and peeked at the
On Mon, Sep 18, 2000 at 07:23:41AM -0600, Tom Christiansen wrote:
Oh joy: now Perl has nested quotes. I *hate* nested quotes.
Those are single-quotes inside double-quotes.
Yep: nested, with varying semantic effects. Completely nasty.
As Nate pointed out: print "$hash-{'f'.'oo'}" already
As Nate pointed out: print "$hash-{'f'.'oo'}" already works fine and
the world spins on.
That is no argument for promoting illegibility.
--tom
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') = undef;
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 data
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 be
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: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 I'm
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
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Overview: Perl OO should Inot be fundamentally changed.
=head1 VERSION
Maintainer: Damian Conway [EMAIL PROTECTED]
Date: 21 Aug 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects : NEXT pseudoclass for method redispatch
=head1 VERSION
Maintainer: Damian Conway [EMAIL PROTECTED]
Date: 1 Sep 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 190
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects : Rationalizing Cref, Cattribute::reftype, and Cbuiltin:blessed
=head1 VERSION
Maintainer: Damian Conway [EMAIL PROTECTED]
Date: 14 Sep 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects : Native support for multimethods
=head1 VERSION
Maintainer: Damian Conway [EMAIL PROTECTED]
Date: 18 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 256
Version: 1
Status:
All-
In an attempt to nudge things in the right direction (wrap-up), I've
gone through and made some specific comments on RFC's. These are my
opinions from monitoring the discussions on this list since its
inception. I do not claim to be infallible, but feel I have a pretty
good idea of what's
24 matches
Mail list logo
