Re: RFC 200 (v1) Objects: Revamp tie to support extensibility (Massive tie changes)

2000-09-10 Thread Michael G Schwern
So I thought of a serious problem with part of this RFC. The bit about using indirect object syntax... Instead, this RFC proposes that Ctie's operation become much more fundamental, simply translating functions via the existing indirect object syntax: tie Transaction

Re: RFC 200 (v1) Objects: Revamp tie to support extensibility (Massive tie changes)

2000-09-10 Thread Nathan Wiger
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

Re: RFC 200 (v1) Objects: Revamp tie to support extensibility (Massive tie changes)

2000-09-10 Thread Michael G Schwern
On Sun, Sep 10, 2000 at 04:00:30PM -0700, Nathan Wiger wrote: Normally, the Foo::lock() subroutine in the current package will be called. However, if %trans is a tied hash to a class which defines a lock() method (let's call it Lock::Ness) the meaning of the program radically and

Re: RFC 200 (v1) Objects: Revamp tie to support extensibility (Massive tie changes)

2000-09-10 Thread Michael G Schwern
On Mon, Sep 11, 2000 at 01:31:39PM +1100, Damian Conway wrote: Or, better still, pass a reference to the actual variable being tied. Good idea. Also notice that I suggested the TIE be called as a method, so that it can be inherited if necessary (maybe you had that idea already???) The tie

Re: RFC 200 (v1) Objects: Revamp tie to support extensibility (Massive tie changes)

2000-09-10 Thread Nathan Wiger
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

Re: RFC 200 (v1) Objects: Revamp tie to support extensibility (Massive tie changes)

2000-09-10 Thread Damian Conway
Also notice that I suggested the TIE be called as a method, so that it can be inherited if necessary (maybe you had that idea already???) The tie *can* currently be inherited. Yes, I was aware. It's just that you wrote: tie Some::Class $foo, @args;

Re: RFC 200 (v1) Objects: Revamp tie to support extensibility (Massive tie changes)

2000-09-10 Thread Michael G Schwern
On Sun, Sep 10, 2000 at 09:22:39PM -0700, Nathan Wiger wrote: Regardless of my huge error above, this doesn't change the fact that this is exactly what tie() does currently in Perl 5. That is: tie @a, 'Matrix'; push @a, $stuff; Now changes the meaning of push() in the current

Re: RFC 200 (v1) Objects: Revamp tie to support extensibility (Massive tie changes)

2000-09-08 Thread Michael Fowler
On Fri, Sep 08, 2000 at 04:57:46AM -, Perl6 RFC Librarian wrote: =head3 Merge CTIESCALAR, CTIEHASH, and CTIEARRAY into CTIE In practice, people rarely make a class that Cties multiple data types through the same interface. The reason is that CSTORE, CFETCH, CDESTROY, and other methods

RFC 200 (v1) Objects: Revamp tie to support extensibility (Massive tie changes)

2000-09-07 Thread Perl6 RFC Librarian
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: 07 Sep 2000 Mailing List: [EMAIL PROTECTED] Version: 1

Re: RFC 200 (v1) Objects: Revamp tie to support extensibility (Massive tie changes)

2000-09-07 Thread Michael G Schwern
[I'll take off my black hat for a moment...] Okay, this is the FIRST TIME I've ever seen indirect object syntax used for anything useful. (That's praise, BTW) I was going to suggest that KEYS and VALUES methods be added to tied hashes, but this RFC makes it all moot. Well done. [Black hat