Re: RFC 171 (v1) my Dog $spot should call a constructor implicitly

2000-09-04 Thread Piers Cawley
Damian Conway <[EMAIL PROTECTED]> writes: >> =head1 TITLE >> >> C should simply assert that >> C<(!defined($spot) || $spot-Eisa('Dog'))> >> >> And let them duke it out. > > You'd have my support for that...I was intending to release an RFC > in the next day or two that

Re: RFC 171 (v2) my Dog $spot should call a constructor implicitly

2000-09-04 Thread Piers Cawley
Michael Fowler <[EMAIL PROTECTED]> writes: > On Fri, Sep 01, 2000 at 10:22:49AM +0100, Piers Cawley wrote: > > And then there's: > > > > - Makes factory methods impossible. > > my Dog $spot; > my $pub = $spot->procreate; > > Sure looks like a factory method to me. Just because you d

Re: RFC 171 (v2) my Dog $spot should call a constructor implicitly

2000-09-04 Thread Piers Cawley
Michael Fowler <[EMAIL PROTECTED]> writes: > On Sun, Sep 03, 2000 at 12:42:52PM +0200, Bart Lateur wrote: > > But now you're throwing away the kid with the bathwater. > > > > my Dog $spot; > > > > initially was syntax invented so that $spot was marked as only been ably > > to reference a Do

Re: RFC 171 (v2) my Dog $spot should call a constructor implicitly

2000-09-04 Thread Piers Cawley
Nathan Wiger <[EMAIL PROTECTED]> writes: > Piers Cawley wrote: > > > > > First off, I think everyone is reading this RFC with the wrong mindset, > > > forgetting the concept of embedded objects in Perl 6. > > > > Ah, that dumb idea again. > > Well, if you disagree with this idea, you probably

Re: RFC 171 (v2) my Dog $spot should call a constructor implicitly

2000-09-04 Thread Piers Cawley
Damian Conway <[EMAIL PROTECTED]> writes: >> > But I agree that anything beyond that is simply horrible. >> > You'll only drive more people *away* from OO, because it >> > generates so horribly inefficient code. If you want a >> > constructor called, than FGS *call* a constructor.

Re: RFC 171 (v2) my Dog $spot should call a constructor implicitly

2000-09-04 Thread Piers Cawley
Michael Fowler <[EMAIL PROTECTED]> writes: > On Fri, Sep 01, 2000 at 05:23:27PM +0200, Slaven Rezic wrote: > > Often, there is the case that "my" is used before actually assigning a > > value to it. For example: > > > > my Foo $foo; > > if ($cond1) { > > $foo = new Foo 1, 2, 3; > >

Re: RFC 188 (v1) Objects : Private keys and methods

2000-09-04 Thread Piers Cawley
"David E. Wheeler" <[EMAIL PROTECTED]> writes: > On 1 Sep 2000, Perl6 RFC Librarian wrote: > > > This and other RFCs are available on the web at > > http://dev.perl.org/rfc/ > > > > =head1 TITLE > > > > Objects : Private keys and methods > > Here, here & amen, Damian! This one gets my insta

Re: RFC 188 (v1) Objects : Private keys and methods

2000-09-04 Thread Piers Cawley
John Siracusa <[EMAIL PROTECTED]> writes: > On 9/1/00 4:59 PM, Perl6 RFC Librarian wrote: > > Once a hash has been C-ized, the only way to extend its set of > > entries is via another call to C: > > > > sub new { > > my ($class, %self) = @_; > > bless private \%self, $class; > >

Re: RFC 189 (v1) Objects : Hierarchical calls to initializersanddestructors

2000-09-04 Thread Piers Cawley
Damian Conway <[EMAIL PROTECTED]> writes: >> But I've gotta nitpick the name. I wonder if BLESS wouldn't be better? >> print calls PRINT, printf calls PRINTF, even if the subs don't do any >> printing. Sure makes it easier to see what's going on, to me at least. > > But BLESS doesn't

Re: RFC 189 (v1) Objects : Hierarchical calls to initializersanddestructors

2000-09-04 Thread Graham Barr
On Mon, Sep 04, 2000 at 11:09:18AM +0100, Piers Cawley wrote: > Damian Conway <[EMAIL PROTECTED]> writes: > > >> But I've gotta nitpick the name. I wonder if BLESS wouldn't be better? > >> print calls PRINT, printf calls PRINTF, even if the subs don't do any > >> printing. Sure makes

Re: RFC 171 (v2) my Dog $spot should call a constructor implicitly

2000-09-04 Thread Michael Fowler
On Mon, Sep 04, 2000 at 10:34:37AM +0100, Piers Cawley wrote: > >> Well then, that's one nay vote. :) > > > > Make that two. > > Three. But I think Michael already knew about mine and forgot to count > it. Heh, I am not counting votes. That was simply me acknowledging his dislike for the

Re: RFC 171 (v2) my Dog $spot should call a constructor implicitly

2000-09-04 Thread Michael Fowler
Well, unless there are any wildly different points someone hasn't mentioned until now, I'm going to freeze this RFC as it is (with a few minor tweaks). Various alternate syntaxes have been suggested, but I still rather like mine. Let Larry do with it what he will. Hopefully he can take somethin

Re: RFC 171 (v2) my Dog $spot should call a constructor implicitly

2000-09-04 Thread Michael Fowler
On Mon, Sep 04, 2000 at 10:25:37AM +0100, Piers Cawley wrote: > Maybe a compromise along the lines of: > >my Dog $spot = LIST; # $spot = Dog->new(LIST) >my Dog $patches; # $patches is undefined but we assert that > # it'll be a Dog. (Whether you can do >

Re: RFC 189 (v1) Objects : Hierarchical calls to initializersanddestructors

2000-09-04 Thread Nathan Wiger
Graham Barr wrote: > > Given that is happens when bless is called and that all other builtin > methods are anmed after what is being called, not what it is being used > for, then I would say that it should be called BLESS for consistancy reason. > > this may seem confusing because you are thinki

RFC 193 (v1) Objects : Core support for method delegation

2000-09-04 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Objects : Core support for method delegation =head1 VERSION Maintainer: Damian Conway <[EMAIL PROTECTED]> Date: 4 September 2000 Mailing List: [EMAIL PROTECTED] Version: 1 Number: 193 Status: De

Re: RFC 193 (v1) Objects : Core support for method delegation

2000-09-04 Thread Uri Guttman
> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: PRL> One powerful application of delegation is as a replacement for PRL> inheritance where the internals of a prospective base class are PRL> inaccessible or inconvenient, or the base class was not designed PRL> to be inherit

Re: RFC 189 (v1) Objects : Hierarchical calls to initializersanddestructors

2000-09-04 Thread Damian Conway
> Given that is happens when bless is called and that all other builtin > methods are anmed after what is being called, not what it is being used > for, then I would say that it should be called BLESS for consistancy reason. > > this may seem confusing because you are thinking of o

Re: RFC 189 (v1) Objects : Hierarchical calls to initializersanddestructors

2000-09-04 Thread Damian Conway
> Damian, I think it would be worth at least mentioning BLESS and REBLESS > in an "Alternative Names" section in the RFC. Enough people have voiced > concerns over this that I think these two are worth putting in there. As I mentioned in another message, I'll be doing that. > The

Re: RFC 193 (v1) Objects : Core support for method delegation

2000-09-04 Thread Damian Conway
> PRL> One powerful application of delegation is as a replacement for > PRL> inheritance where the internals of a prospective base class are > PRL> inaccessible or inconvenient, or the base class was not designed > PRL> to be inherited and yet it must be. > > isn't this

Non-inheritable and cascading methods

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

Re: RFC 188 (v1) Objects : Private keys and methods

2000-09-04 Thread Nathan Wiger
> 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 => "de

Re: RFC 193 (v1) Objects : Core support for method delegation

2000-09-04 Thread Michael G Schwern
On Mon, Sep 04, 2000 at 09:53:39PM -, Perl6 RFC Librarian wrote: > Objects : Core support for method delegation I like it! One gripe (of course)... > The proposed delegation mechanism would work via a pragma: > > use delegation > attr1 => [qw( method1 method2 method3 )

Re: RFC 188 (v1) Objects : Private keys and methods

2000-09-04 Thread Damian Conway
> Will "private" be a true scoping keyword? Or under strict would you have > to do this: > >private my %hash; It's not a replacement for C, though C *might* choose to overlook it. :-) Damian

Re: RFC 188 (v1) Objects : Private keys and methods

2000-09-04 Thread Dave Rolsky
On 1 Sep 2000, Perl6 RFC Librarian wrote: > Private entries of hashes could be I accessed in packages > that inherit from the entry's package, by qualifying (i.e. prefixing) the > key with the entry's package name. For example: > > package Base; > > sub new { >

Re: RFC 193 (v1) Objects : Core support for method delegation

2000-09-04 Thread Uri Guttman
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes: PRL> use Class::Delegation >> >> shouldn't that be use delegation? i think you have a cut and paste >> error. DC> You're correct. Many thanks. DC> (That's what I get for pre-testing all the code in my RFCs! ;-) heh, you should