I'm kind of curious to know what you think would happen with the
following. I've commented where I'm confident...
interface Number;
sub TIESCALAR;
sub STORE;
sub FETCH;
package integer implements Number; # I really like this notation
Tangentially, yes, it is nice
package Doggie;
sub isborn {
bless { @_ }, self; # ;-)
}
sub scratches ($\@;@) {
...
}
package Doggie::Cute;
use base 'Doggie';
use interface 'Pet';
# Our base class is 'Doggie', which does not use the 'Pet'
#
Damian Conway wrote:
I didn't see any mention of my plea that Ctie should pass the
original variable being tied as one of its arguments. :-(
That's because it's a dumb idea!!
**Kidding!**
I forgot about this, sorry. I'll add it to the next version ;-)
my $x = 10;
tie
What sets Ruby apart is a clean and consistent
language design where everything is an object.
I like this part. Assuming I ever finish my last RFC I'd like Perl to
have embedded objects as well. The difference being Perl's wouldn't get
in the way, unlike Python's.
Of particular interest seems
This RFC proposes two new keywords -- Cprivate and Cpublic -- that limit
the accessibility of keys in a hash, and of methods.
I still think these should be attributes across the board:
my $hash{$key} : private = $val;
my @hash{qw(_name _rank _snum)} : public;
sub dostuff : private {
Damian Conway wrote:
The problem with specifying them as attributes is that I do not believe
there is any way (or even any proposed way) of applying attributes to
a hash entrie or a hash slice, nor is there any way of *retrospectively*
applying an attribute to a hash that has already been
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
[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';
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
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
Tom Christiansen wrote:
print "Today's weather will be $weather-temp degrees and sunny.";
So, the - operator is supposed to get expanded in dq strings, eh?
It already does, or at least appears to to users:
print "Today's weather will be $weather-{temp} degrees and sunny.";
This topic is actually covered, albeit far less in-depth and lumped with an
unrelated change, by Nathan Wiger's RFC 103, just in case you weren't aware.
Yeah, I've got to split those up. I was trying cut down on the flood of
RFC's that poor Larry has to sift through :-(, but they are both
Nathan Wiger wrote:
use namespace 'Big::Long::Prefix';
my ::Class $object = ::Class-new;
Assuming repairing :: precedence is a reality I don't think this
proposal buys us anything.
backtracking...That being said, I'm not necessarily against it. I'm
just against bloat. I hadn't
=head2 The CBUILD method
=head3 The CREBUILD method
Hey! You left out the alternative names NEW / RENEW and BLESS / REBLESS
that we all like! :-(
-Nate
use namespace 'Big::Long::Prefix';
my ::Class $object = ::Class-new;
Anyone mentioned that this:
$SHORT = 'Some::Huge::Obnoxious::Ridiculous::Term';
$SHORT-member;
$stuff = new $SHORT;
Already works? The only problem is that this:
$SHORT::stuff(@args);
Doesn't, but this
[added -io cross-post]
John Porter wrote:
Just MHO, but I don't think this is the kind of thing that should
go in the core. Just MHO.
I think I agree. Just to clarify, the only reason it's an RFC and not
just a Perl 5 module is because RFC 14 (the one on a new open()) relies
on a handler
Michael Fowler wrote:
=head3 Merge CTIESCALAR, CTIEHASH, and CTIEARRAY into CTIE
I'm not so sure about this.
I'm not either anymore. This will probably be removed from the next
version.
Instead, this RFC proposes that Ctie's operation become much more
fundamental, simply translating
Michael G Schwern wrote:
sub lock { print "Hello!" }
$trans = new Lock::Ness;
lock $trans; # $trans-lock
That's not right.
You're correct. Sorry for not double-checking my examples.
the same reasons I've already pointed out. You don't want adding a
method to a class to
Damian Conway wrote:
attr3 = [ALL]
It was (and is) a good suggestion. I suspect however that it should be
attr3 = [__ALL__]
Any consideration given to the :all export-like tag?
attr3 = [:all]# could be uppercase too
-Nate
All-
I've been toying with this for a while, and I'm looking for others'
input. I'm not RFC'ing it yet because (a) I already have 25 others to
maintain and (b) I'm not sure if this might be covered by "my sub" or
one of Damian's future RFC's.
Currently, there are two big problems in defining
private $hash{key};
private $hash{$key};
private $hashref-{key};
or to a hash slice:
private @hash{qw(_name _rank _snum)};
or to a complete hash (either directly, or via a reference):
private %hash;
private { _name = "demo", _rank =
Michael G Schwern wrote:
Derived classes will never have to override a base's implementation,
and all member variables should be private, and everyone will always
use an accessor, and the UN will bring about world peace, and as long
as I'm wishing for a perfect world, I'd like a pony. ;)
I haven't commented on RFC 171 because I assumed it would be shot down
quickly by the Major Contibutors(tm), but let me just say now that I'm
firmly in this camp:
Funny, I don't see much difference between RFC 171 and this RFC:
171: constructor called on object creation
189:
What, then, happens to the following code:
my Dog $spot;
if ($age 12) {
$spot = new Doberman();
} else {
$spot = new Corgi();
}
This is a tricky case that deserves a lot of attention, but not exactly
as written. Imagine this code block:
my int ($x, $y, $z) = (4, 5, 6);
"Randal L. Schwartz" wrote:
That's my first gut reaction to this proposal. "If you like Python,
you know where to find it, but let us have some primitive data types
in Perl that act primitive so we can optimize things."
Well, we're on a border here. What this RFC is really referring to is
Nathan Torkington wrote:
Are you proposing making even "normal" scalar, hash, and array access
go through these methods? Wouldn't that slow everything way down?
Glad you brought this up, Nat!
I would say "yes and no". The reason I'd say this is because Dan S. and
the internals guys are
/
=head1 TITLE
True Polymorphic Objects
=head1 VERSION
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 25 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 159
Status: Developing
=head1 ABSTRACT
Currently, using objects in numeric and string contexts
Please discuss this RFC on the -objects sublist. Thanks.
Matt, you should probably update the Mailist List to
perl6-language-objects for v2.
-Nate
Perl6 RFC Librarian wrote:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
OO
You can have your cake, but not force us to eat it too...
Like $AUTOLOAD, $ME would be dynamically scoped:
The first time I saw the bareword "self" keyword I almost wet myself in
horror, but I would say that $AUTOLOAD is a disaster that should not be
repeated. And that's the way that this
29 matches
Mail list logo
