>I wonder if this problem couldn't be solved with a proper combination of
>@ISA, SUPER::, NEXT::, and use delegation? (calling Damian... :-)
The problem I see is a bit of trickery would be necessary to get
static calls to the class to resolve to the appropriate method.
Using Schwern's DBI examp
>The DBI has this very problem! DBI->connect() returns DBI::db
>objects, DBI->prepare() returns DBI::st. If you want to override the
>behavior for statement handles and connections, its not enough to just
>subclass DBI::st and DBI::db, you must also subclass DBI and override
>connect() and prepa
I haven't (and won't) have time to go into this in detail :-(
I feel that this proposal is solving the wrong problem. The issue is
that the original Forest and Frog (or DBI and DBI::st) classes are not
*designed* for user-definable Frogs (DBI::st's). If that functionality
is widely needed, the Fo
Damian Conway wrote:
>
> I didn't see any mention of my plea that C 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;
> ti
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...
>
>>
Thanks for getting this RFC together, Piers.
A few comments:
* I suggest you remove my alternative C<:must(Foo)> suggestion.
It's too ugly to live, inless you just want to use it as a
scare tactic to encourage Larry to chose the C
syntax instead ;-)
> 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
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Improved parsing and flexibility of indirect object syntax
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 29 Aug 2000
Last Modified: 20 Sep 2000
Mailing List: [EMAIL PROTECTED
>I haven't (and won't) have time to go into this in detail :-(
>
>I feel that this proposal is solving the wrong problem. The issue is
>that the original Forest and Frog (or DBI and DBI::st) classes are not
>*designed* for user-definable Frogs (DBI::st's). If that functionality
>is widely needed,
> In all sincerity, your Lingua::Romana::Perligata module is a good
> example. Although not many people may desire to code perl in Latin,
> it is certainly conceivable that modules similar to Perligata may
> allow programming perl in a variety of languages native to the
> progr
> * The new C keyword would be unnecessary if *package
> specifications* could take attributes:
>
> interface Fetcher;
>
> would then become:
>
> package Fetcher : interface;
I'm not sure about this - seems like we're squeezing a whol
> > * There's also no need to distinguish C and C,
>
> Again, I'm not sure. As the RFC shows, it's quite easy to imagine a
> situation where you have a tangential interface specification that does
> *not* serve as the inheritance point for your class:
I don't think the RFC show
Damian Conway wrote:
>
> I don't think the RFC shows that at all.
Well, I think the RFC is a little rough on some things, but that doesn't
necessarily invalidate some of the points.
> Or are you implying that packages and interfaces would dwell in separate
> namespaces? If so: YUCK!
No, c'
I didn't see any mention of my plea that C should pass the
original variable being tied as one of its arguments. :-(
E.g.:
sub ReadOnly::TIESCALAR {
my ($class, $original, @otherargs) = @_;
bless {
internals => \@otherargs,
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects: Revamp tie to support extensibility (Massive tie changes)
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 7 Sep 2000
Last Modified: 20 Sep 2000
Mailing List: [EMAIL PROTEC
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Interface polymorphism considered lovely
=head1 VERSION
Maintainer: Piers Cawley <[EMAIL PROTECTED]>
Date: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 265
Version: 1
Status: Developing
16 matches
Mail list logo
