Re: RFC for $ME class variable (was Re: RFC 124 (v1) Sort order for any hash)

2000-08-21 Thread Piers Cawley
Damian Conway <[EMAIL PROTECTED]> writes: > Errr. I would imagine that $ME contains: > > * a reference to the object, within an object method > > * the name of the class, within a class method > > * a reference to the *subroutine* itself, within a non-method. Ooh, recursive a

Re: RFC 137 (v1) Overview: Perl OO should I be fundamentally changed.

2000-08-22 Thread Piers Cawley
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > =item * > > Changes to the semantics of C so that, after associating an > object with a class, the class's C methods are automatically > called on the object. An additional trailing C<@> parameter for > C, to allow arguments to be passed to C met

Re: $ME in a method called as a subroutine

2000-08-23 Thread Piers Cawley
Markus Peter <[EMAIL PROTECTED]> writes: > --On 22.08.2000 18:24 Uhr + David L. Nicol wrote: > > > > > Regardless of what its called, in a method called as a subroutine, > > the variable could refer to the last instance of this kind of object > > used by this thread. > > Hmm Does that m

Re: RFC 159 (v1) True Polymorphic Objects

2000-08-29 Thread Piers Cawley
Nathan Wigner in the guise of Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > You can use facilities such as C to help fix this issue, but > C is limited and slow. You can also overload operators, but > this is not flexible enough for many applications since it applies > to a package (and not in

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

2000-08-30 Thread Piers Cawley
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > my Dog $spot should call a constructor implicitly Eeeeww. Most of the time I use 'my Dog $spot' is along the lines of: package Dog;

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

2000-08-30 Thread Piers Cawley
Hildo Biersma <[EMAIL PROTECTED]> writes: > Many people see even this as a bad choice, saying that 'explicit' should > be the default, and that C++ constructors should be marked 'implicit' > for this behavior to be allowed. Hmmm... having 'explicit' be implicit and vice versa? I think my head may

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

2000-09-01 Thread Piers Cawley
Nathan Wiger <[EMAIL PROTECTED]> writes: > Piers Cawley wrote: > > > > Eeeeww. Most of the time I use 'my Dog $spot' is along the lines > > of: > > > > my Dog $spot = Dog::Dalmation->new(name => 'Spot'); > >

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

2000-09-01 Thread Piers Cawley
Hildo Biersma <[EMAIL PROTECTED]> writes: > Perl6 RFC Librarian wrote: > >> =head1 DESCRIPTION > > > > What is currently an optimization for pseudo-hashes: > > > > my Dog $spot = Dog->new(); > > > > should be replaced with: > > > > my Dog $spot; > > > > which calls an implicit constr

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

2000-09-01 Thread Piers Cawley
Michael Fowler <[EMAIL PROTECTED]> writes: > On Fri, Sep 01, 2000 at 09:34:12AM +0100, Piers Cawley wrote: > > Because, hopefully, there are efficiency gains to be had when perl > > *knows* that $self is a Dog. If it only makes the 'name' method > > cal

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

2000-09-01 Thread Piers Cawley
Nathan Wiger <[EMAIL PROTECTED]> writes: > 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. > I believe the idea would be that CREATE is a *fundamental* method, like > DESTROY, that would do

Re: perl6-language-objects Report 31 Aug 2000

2000-09-01 Thread Piers Cawley
Nathan Wiger <[EMAIL PROTECTED]> writes: > =head2 RFC 171 (v1): my Dog $spot should call a constructor implicitly > (Michael Fowler) > > This proposed a C++ like constructor mechanism whereby the declaration > of a variable implicitly creates an object. This mechanism would allow > for declaratio

Re: perl6-language-objects Report 31 Aug 2000

2000-09-01 Thread Piers Cawley
Nathan Wiger <[EMAIL PROTECTED]> writes: > =head2 RFC 137 (v1): Perl OO should I be fundamentally changed > (Damian Conway) > > This RFC explored several extensions to current Perl OO in order to make > it more powerful, without sacrificing its current simplicity or > flexibility. Unfortunately,

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 lo

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. > >

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 171 (v2) my Dog $spot should call a constructor implicitly

2000-09-05 Thread Piers Cawley
Michael Fowler <[EMAIL PROTECTED]> writes: > 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 a

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

2000-09-05 Thread Piers Cawley
Michael G Schwern <[EMAIL PROTECTED]> writes: > 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 del

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

2000-09-05 Thread Piers Cawley
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > Objects : Core support for method delegation I *want* this. Delegation is cool. Delegation that gets set up at compile time and is marked as such

Draft RFC: my Dog $spot is just an assertion

2000-09-12 Thread Piers Cawley
=head1 TITLE C is just an assertion =head1 VERSION Maintainer: Piers Cawley <[EMAIL PROTECTED]> Date: 12th September 2000 Last Modified: 12th September 2000 Mailing List: [EMAIL PROTECTED] Version: 0 Status: Draft =head1 ABSTRACT The behaviour of the syntax should simply

Draft RFC: new pragma: C

2000-09-12 Thread Piers Cawley
=head1 TITLE new pragma: C =head1 VERSION Maintainer: Piers Cawley <[EMAIL PROTECTED]> Date: 12th September 2000 Last Modified: 12th September 2000 Mailing List: [EMAIL PROTECTED] Version: 0 Status: Draft =head1 ABSTRACT Cnew> is a pain in the bum to type.

Re: Draft RFC: my Dog $spot is just an assertion

2000-09-13 Thread Piers Cawley
Damian Conway <[EMAIL PROTECTED]> writes: > Piers wrote: > >> The behaviour of the syntax should simply be an >> assertion of the invariant: >> >>(!defined($spot) || (ref($spot) $spot->isa('Dog))) > > (!defined($spot) || (ref($spot) && $spot->isa('Dog'))) > > >

Re: Draft RFC: new pragma: C

2000-09-13 Thread Piers Cawley
Hildo Biersma <[EMAIL PROTECTED]> writes: > Piers Cawley wrote: > > =head1 ABSTRACT > > > > Cnew> > > is a pain in the bum to type. We should replace this with > > > > use namespace 'Big::Long::Prefix'; > > my ::Class $o

Re: Draft RFC: new pragma: C

2000-09-14 Thread Piers Cawley
Graham Barr <[EMAIL PROTECTED]> writes: > I would suggest that anyone want to contribute to this discussion should > first read the thread about the addition of this pragma to perl5 in > the perl5-porters archives > > >http://www.xray.mpe.mpg.de/cgi-bin/w3glimpse/perl5-porters?query=use+namespa

Re: RFC 218 (v1) C is just an assertion

2000-09-14 Thread Piers Cawley
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > C is just an assertion > > =head1 VERSION > > Maintainer: Piers Cawley <[EMAIL PROTECTED]> >

Re: RFC 218 (v1) C is just an assertion

2000-09-14 Thread Piers Cawley
Nathan Torkington <[EMAIL PROTECTED]> writes: > Perl6 RFC Librarian writes: > > I therefore propose that C comes to mean that C<$spot> > > is restricted to being either undefined or a reference to a C > > object (or any subclasses of Dog). Simply having this implicit > > assertion can be useful t

Re: RFC 218 (v1) C is just an assertion

2000-09-14 Thread Piers Cawley
Nathan Wiger <[EMAIL PROTECTED]> writes: > Nathan Torkington wrote: > > > > Yes! I mentioned the hypothetical > > use strict 'types'; > > which would require all variables assigned to/from an object, and > > all variables upon which method calls are made, to be typed like > > this. Then the

Re: RFC 218 (v1) C is just an assertion

2000-09-14 Thread Piers Cawley
Michael G Schwern <[EMAIL PROTECTED]> writes: > On Wed, Sep 13, 2000 at 08:43:43PM -, Perl6 RFC Librarian wrote: > > The behaviour of the syntax should simply be an > > assertion of the invariant: > > > >(!defined($spot) || (ref($spot) && $spot->isa('Dog))) > > What about the current

Re: RFC 218 (v1) C is just an assertion

2000-09-18 Thread Piers Cawley
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); > > > > >

Re: RFC 218 (v1) C is just an assertion

2000-09-18 Thread Piers Cawley
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 C but with >> 'Interface' cons

Re: RFC 218 (v1) C is just an assertion

2000-09-18 Thread Piers Cawley
Buddha Buck <[EMAIL PROTECTED]> writes: > At 08:13 AM 9/15/00 +1100, Damian Conway wrote: > >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

Re: RFC 218 (v1) C is just an assertion

2000-09-19 Thread Piers Cawley
Michael G Schwern <[EMAIL PROTECTED]> writes: > 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 C > > [\%{"$class\::FIELDS"}], $class>

Re: RFC 265 (v1) Interface polymorphism considered lovely

2000-09-21 Thread Piers Cawley
Damian Conway <[EMAIL PROTECTED]> writes: > 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 Lar

Re: RFC 265 (v1) Interface polymorphism considered lovely

2000-09-21 Thread Piers Cawley
Nathan Wiger <[EMAIL PROTECTED]> writes: > > * The new C keyword would be unnecessary if *package > > specifications* could take attributes: > > > > interface Fetcher; > > > > would then become: > > > > package Fetcher : interface; >

Re: RFC 265 (v1) Interface polymorphism considered lovely

2000-09-21 Thread Piers Cawley
Nathan Wiger <[EMAIL PROTECTED]> writes: > By specifying "use interface" explicitly, you can make sure that your > class follows the interface spec. Otherwise, you rely on other classes > in the hierarchy above you doing so, and then you indirectly inheriting > from that interface. So "use interf

Re: RFC 265 (v1) Interface polymorphism considered lovely

2000-09-21 Thread Piers Cawley
Jonathan Scott Duff <[EMAIL PROTECTED]> writes: > On Thu, Sep 21, 2000 at 10:45:05AM +0100, Piers Cawley wrote: > > Whoa Nellie. When did we get prototyping for methods. > > We've had prototyping (context coercing) for methods as long as we've > had them fo

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

2000-09-21 Thread Piers Cawley
Damian Conway <[EMAIL PROTECTED]> writes: > 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 { >

Re: RFC 174 (v2) Improved parsing and flexibility of indirect object syntax

2000-09-21 Thread Piers Cawley
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > =head1 ABSTRACT > > Currently, Perl 5 makes a distinction between routines called in the > indirect object vs. function form: > >$r = new CGI; # CGI->new >$r = new CGI (@args); # CGI->new(@args) >$r = new(CGI @args); # mai

Re: RFC 265 (v1) Interface polymorphism considered lovely

2000-09-25 Thread Piers Cawley
Nathan Wiger <[EMAIL PROTECTED]> writes: > > >package Doggie; > > > > > >sub isborn { > > >bless { @_ }, self; # ;-) > > >} > > >sub scratches ($\@;@) { > > >... > > >} > > > > > > > > >package Doggie::Cute; > > > > > >use base 'Doggie'; > > >use

Re: RFC 307 (v1) PRAYER - what gets said when you C something

2000-09-26 Thread Piers Cawley
Simon Cozens <[EMAIL PROTECTED]> writes: > On Tue, Sep 26, 2000 at 07:20:08AM +1100, Damian Conway wrote: > > RFC 189 covers this. > > So it does! Cool, I can withdraw mine *and* get the warm fuzzy feeling that > comes from like-thinking-of-great-minds. > > RFC 307 is withdrawn! I do like the

Re: RFC 319 (v1) Transparently integrate C

2000-09-26 Thread Piers Cawley
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > Transparently integrate C On the whole I think I'm liking this. But it needs work. >my packed $a; # just an assertion, RFC 218 >$a

Re: RFC 319 (v1) Transparently integrate C

2000-09-27 Thread Piers Cawley
Nathan Wiger <[EMAIL PROTECTED]> writes: > > 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 Nu

Re: RFC 161 (v4) Everything in Perl becomes an object.

2000-09-27 Thread Piers Cawley
Simon Cozens <[EMAIL PROTECTED]> writes: > On Wed, Sep 27, 2000 at 05:25:28AM -, Perl6 RFC Librarian wrote: > > Not an awful lot was said once this RFC was condensed down to "Everything > > becomes an object". I believe some implementation and conceptual hurdles > > exist which have discourag

Re: RFC 335 (v1) Class Methods Introspection: what methods does this object support?

2000-09-29 Thread Piers Cawley
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > Class Methods Introspection: what methods does this object support? > > =head1 VERSION > > Maintainer: Mark Summerfield <[EMAIL PROTECTED]> >

Re: RFC 335 (v1) Class Methods Introspection: what methods does this object support?

2000-10-02 Thread Piers Cawley
[EMAIL PROTECTED] (Johan Vromans) writes: > Piers Cawley <[EMAIL PROTECTED]> writes: > > > Actually, I'd like to see something similar done to Universal::can > > my @methods = $class->can(pattern) > > where pattern is a perl pattern matchin

Re: RFC 265 (v3) Interface polymorphism considered lovely

2000-10-02 Thread Piers Cawley
David Grove <[EMAIL PROTECTED]> writes: > > Java is one language that springs to mind that uses interface > > polymorphism. Don't let this put you off -- if we must steal something > > from Java let's steal something good. > > Interface inheritance is probably the least dignified thing to steal

Re: RFC 254 (v2) Class Collections: Provide the ability to overload classes

2000-10-02 Thread Piers Cawley
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > Class Collections: Provide the ability to overload classes > > =head1 VERSION > > Maintainer: Greg Williams <[EMAIL PROTECTED]> > Date: 17 Se

Re: RFC 254 (v2) Class Collections: Provide the ability to overload classes

2000-10-03 Thread Piers Cawley
Greg Williams <[EMAIL PROTECTED]> writes: > At 11:01 +0100 2000/10/02, Piers Cawley wrote: > >Hmm... I'm really not keen on this idea. Not keen at all. And I can't > >for the life of me see what's wrong with just making a factory method > >(

Re: RFC 265 (v3) Interface polymorphism considered lovely

2000-10-06 Thread Piers Cawley
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > Interface polymorphism considered lovely > > [...] > > > =head1 IMPLEMENTATION > > I have some ideas about this, and I believe it may be possibl

Re: Stupid Newbie Question

2001-11-09 Thread Piers Cawley
Dan Sugalski <[EMAIL PROTECTED]> writes: > At 04:21 PM 11/8/2001 -0800, John Rudd wrote: >>So, does this mean my other heart's desire of operator overloading might >>be coming forth? (I know, I know, here I am, a smalltalker, asking for >>operator overloading ... but, what are the smalltalkers g