Re: RFC 124 (v1) Sort order for any hash

[Damian Conway]

   > How about
   >
   >%students : ( sort = $$students{^1}{GPA} <=> $$students{^0}{GPA} });

Weeird! :-)

Since you've strayed so close, why not go all the way and make it an attribute:

my %students : sorted( $ME{^1}{GPA} <=> $ME{^0}{GPA} );

Where the C attribute takes a block/sub ref/h.o.f. that expects
to compare two keys, which would be passed as arguments. Note too the
(now generalized) use of the proposed $ME variable.

Voila! A syntax entirely consistent with other existing and proposed
Perl usages.


Damian

Re: RFC 124 (v1) Sort order for any hash

[Damian Conway]

   > > my %students : sorted( $ME{^1}{GPA} <=> $ME{^0}{GPA} );
   > >
   > Yes, I was thinking the same thing. Except the '$ME' thing--what's that? (I
   > must have missed that discussion...)

It's an idea that within a method call, the object reference would
not be passed as the first argument (or maybe, not *just* as the
first argument), but in a variable named $ME. I was pushing that
envelope a little.
   
   > What's wrong with @_?

We're trying to sort like this:

sort  $student{^1}{GPA} <=> $student{^0}{GPA} ),  keys %student;

Within the %student's internals, %student is %ME :-)

Damian

Re: explicit boolean accessor

[Damian Conway]

   > So what you want is for overloading to become easier, probably via
   > predefined methods?  Excellent topic for an RFC.

I'm already writing it (and exactly that way, too).

Damian

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

[Damian Conway]

   > > It's an idea that within a method call, the object reference would
   > > not be passed as the first argument (or maybe, not *just* as the
   > > first argument), but in a variable named $ME. I was pushing that
   > > envelope a little.
   > 
   > Is this RFC'ed yet? 
   
It may have been mentioned in Andy Wardley's treatise, but I think
it warrants it's own RFC.

   > If not, I'll do it

Fine by me.

   > I think that $ME should NOT be passed in @_ at all. It's a PITA right
   > now to deal with (function vs. object forms, trying to support both).
   > $ME should simply be the name of the class it's called as a member of,
   > falling back to the name of the package if one isn't defined (as in a
   > function-oriented style).

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.

   
   > P.S. Alternatives to $ME are welcomed, but please email these JUST to
   > me. Naming always seems to generate tons of messages. I'll just list the
   > alternatives under "alternative names" at the bottom of the RFC. Thanks.

Don't give alternatives. Give a "these alternatives were considered and
*rejected*" list. $ME is capitalized (like all "magic" vars), and short.

And don't forget to include my idea that $ME be scoped locally like
$AUTOLOAD, so that the "self" and "this" and "I" and "myself" camps can
have their respective cakes but the rest of us don't have to eat them:

package MyClass_Std;

sub name($newval) {
$ME->{name} = $newval if @_;
return $ME->{name};
}


package MyClass_Selfish;

sub self() {$ME};

sub name($newval) {
self->{name} = $newval if @_;
return self->{name};
}


package MyClass_Thisly;

sub this() {$ME};

sub name($newval) {
this->{name} = $newval if @_;
return this->{name};
}


package MyClass_ValleySpeak;

sub me_myself_personally() {$ME};

sub name($newval) {
me_myself_personally->{name} = $newval if @_;
return me_myself_personally->{name};
}


:-)

Damian

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

[Damian Conway]

>From his padded room, Randal suggested:

   > > "John" == John Siracusa <[EMAIL PROTECTED]> writes:
   > 
   > John> I don't like $ME either, but my alternative is probably even more
   > John> blasphemous: use $self.  
   > 
   > John> But wait, it gets worse:  I'd even be happy with the bareword "self"
   > 
   > I'll have an adjacent cell.  I actually like that *better* than $self.


You can have your cake, but not force us to eat it too...

Like $AUTOLOAD, $ME would be dynamically scoped:

package LoonyBin;

sub self {$ME};

sub get_polite_age : method {
return (self->age >= 40) ? 39 : self->age;
}


One might even imagine a standard pragma that automatically creates
such things in any package with methods.

We seem to cope with $AUTOLOAD okay, without the need to:

sub autoload : lvalue {$AUTOLOAD}

all the time.

Damian

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

[Damian Conway]

Uri wrote:

   >   PRL> A C keyword that lexically scopes hash keys to the
   >   PRL> current package, and allows hashes to contain two or more
   >   PRL> identically named (but differently scoped) entries. This
   >   PRL> would solve the problem of encapsulation in OO Perl for the
   >   PRL> vast majority of (predominantly hash-based) class
   >   PRL> structures.
   > 
   > does that apply to a set of keys? or a particular hash ref used as the
   > object? 

It applies to the nominated keys of the nominated hash.


private $hash{secret};  # Just this key is private

private @hash{qw(name rank snum)};  # All these keys are private

private %hash;  # All the current keys are private



   > INIT currently has a useful meaning in perl5.
   
Arrgh. That had slipped my mind. I'll find another name. Thanks.


   > would a parent INIT get called even if there is no INIT in this class?

Yes.

   > how would you travel up the @ISA tree and call INIT?

Actually, you travel *down* the @ISA tree: the most ancestral INITs are
called first.


   >   PRL> Pre- and post-condition specifiers, which associate code
   >   PRL> blocks with particular subroutine/method names. These blocks
   >   PRL> would be automatically called before and after the
   >   PRL> subroutine/method of the same name, and trigger an exception
   >   PRL> on failure. For methods, pre- and post-conditions would be
   >   PRL> inherited and called hierarchically (with disjunctive
   >   PRL> short-circuiting, in the case of post-conditions).
   > 
   > can't this just be done with calls from the method sub?

No, you want to separate conditions from implementation for several reasons:

1. You can inherit conditions whilst replacing implementation

2. You can impose new conditions whilst inheriting implementation

3. You can disable conditions in production code

4. One condition can be applied to several variants of a multimethod

5. You don't clutter your method implementation with testing code

   
   > does [a postcondition] have access to the return values?

Yes, as well as the original arg list.
   

   > same for the pre-, does it see @_?

Yes. 


   > also how would they affect 'want'?

They wouldn't. What had you conjectured?

   
   >   PRL> Class invariant specifiers, 
   > 
   > how is this different from the post-condition above? 

An invariant is called after *every* method, not just a specific method.
Think of it as a generic post-condition.


   >   PRL> An optional constraint (C?), making it a fatal
   >   PRL> error to store a object reference in a non-typed lexical.
   > 
   > would that be defaulted in use strict; like the others are? i think it
   > should be.

I agree.


   >   PRL> A new pragma -- C -- that would modify the
   >   PRL> dispatch mechanism to automatically delegate specific method
   >   PRL> calls to specified attributes of an object.
   > 
   > no more need for AUTOLOAD of accessors?

No, AUTOLOAD will still be useful. This is more for when you want to
inherit from a class that you don't have control over, or that wasn't
designed to be inherited. You can aggregate instead and then delegate
method calls to the corresponding attribute. For example:

package MyClass;
use TheirWeirdClass;
use TheirOtherWeirdClass;
use TheirLastWeirdClass;

use delegation
theirbit  => ['theirweirdmethod1', 'theirweirdmethod2'],
theirotherbit => 'TheirOtherWeirdClass::',
theirlastbit  => 'UNKNOWN';

sub new {
my %self = (
theirbit  => TheirWeirdClass->new(),
theirotherbit => TheirOtherWeirdClass->new(),
theirlastbit  => TheirLastWeirdClass->new(),
mybit1=> "mine",
mybit2=> "all",
mybit3=> "mine!",
);
bless \%self, $_[0];
}

If $obj is an object of class MyClass, then the C shown above 
would cause the calls:

$obj->theirweirdmethod1();
$obj->theirweirdmethod2();

to be treated as:

$obj->{theirbit}->theirweirdmethod1();
$obj->{theirbit}->theirweirdmethod2();

It would also cause any method for which there is an identically named method
in class TheirOtherClass to be similarly delegated to $obj->{theirotherbit}.

And it would cause any method that can't be otherwise dispatched, to be
delegated to $obj->{theirlastbit}.

All these delegations are performed in the autoloading phase, but before
AUTOLOAD is considered. In fact, since the C delegates
all unknowns to $obj->{theirlastbit}, in this particular case AUTOLOAD
would never be considered.
   
   
   >   PRL> That in Perl 6, only hashes (and perhaps pseudohashes) may
   >   PRL> be blessed.
   > 
   > you just blew chapters 4 & 5 

Re: PROTOPROPOSAL FOR NEW BACKSLASH is still Re: implied pascal-like"with" or "express"

[Damian Conway]

   > And that's just too much punctuation for too little value.
   > 
   > How special purpose is "with"?  Do people envision using it *only* on
   > hashes?  (I did until this email)  If so, I like Damian's version best:
   > 
   > http://www.mail-archive.com/perl6-language@perl.org/msg02649.html

Unfortunately, as has been subsequently pointed out, that cunning plan is
fatally flawed, if you rely on higher order functions to keep the syntax
clean.

So I'm back to proposing that

with (%hash) {
...
print $_{name};
print @_{qw(name rank snum};
print keys %_;
...
}

simply be sugar for:

{ local %_=%hash;
  do {
...
print $_{name};
print @_{qw(name rank snum};
print keys %_;
...
 }
}

Oh, and %_ could become the default argument to the various hash-related
builtins, allowing for:

with (%hash) {
...
print keys;
...
}

This is no more typing than:

with (%hash) {
...
print ->{name};
print ->{qw(name rank snum};
print keys ??;
...

And it's entirely consistent with existing Perl
(it doesn't even add a new punctuation variable).

I'd also suggest that C also be allowed to take 
a reference to a hash and alias %_ to the hash.
That would simplify handling nested data structures:

with ($loholoh->[1]{to}[4]{see}) {
...
$_{field1} = $data1;
$_{field2} = $data2;
$_{field3} = $data3;
...
}

Damian

PS: Just *love* Larry's "yadda yadda yadda" operator!

Re: RFC 159 (v1) True Polymorphic Objects

[Damian Conway]

   >Data Conversion and Access
   >-
   >STRING   Called in a string context
   >NUMBER   Called in a numeric context
   >BOOLEAN  Called in a boolean context
   > 
   > 
   >Operator Overloading
   >-
   >PLUS Called in + context
   >MINUSCalled in - context
   >TIMESCalled in * context
   >DIVIDED  Called in / context
   >MODULUS  Called in % context

DIV and MOD would suffice I think


   >NUMCMP   Called in <=> context 
   >NUMEQCalled in == context
   >NUMNECalled in != context
   >NUMLTCalled in <  context
   >NUMGTCalled in >  context
   >NUMLECalled in <= context
   >NUMGECalled in >= context
   > 
   >STRCMP   Called in cmp context
   >STREQCalled in eq context
   >STRNECalled in ne context
   >STRLTCalled in lt context
   >STRGTCalled in gt context
   >STRLECalled in le context
   >STRGECalled in ge context

CONCAT  Called in . context


   >BITAND   Called in & context
   >BITORCalled in | context
   >BITXOR   Called in ^ context
   >BITNOT   Called in ~ context

LOGHIGHAND  Called in && context
LOGHIGHOR   Called in || context
LOGLOWAND   Called in and context
LOGLOWORCalled in or context

LOGIFELSE   Called in ?: context
   
   
   >Assignment and Existence
   >-
   >CREATE   Called in object creation

I'll address this more fully in a forthcoming RFC


Damian

Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)

[Damian Conway]

   > >Currently, the current object context is passed into a sub as the first
   > >element of @_, leading to the familiar construct:
   > 
   > >   my $self = shift;
   > 
   > >However, this is a big PITA. In particular, if you support lots of
   > >different calling forms (like CGI.pm), you have to check whether $_[0]
   > >is a ref, etc, etc, etc.
   > 
   > It is?  I don't see that this is a pain at all.  It seems like
   > a beautiful point of homogenization.  You don't force the user
   > to say $self; they could use $this if they wanted.  Heck, they 
   > don't need it at all.
   > 
   > my(undef, @args) = @_;
   > 
   > Or as in 
   > 
   > shift->fn(@_)
   > 
   > This is one of the things that Larry, in borrowing much of Perl's
   > OO from Python, carefully preserved from the parent tongue.  Don't
   > see why you would break it.


My forthcoming proposal will be that invocants still be passed as $_[0]
by default, but that there be a pragma allowing $_[0] to be automagically
shifted somewhere else during dispatch. For example:


sub method { print "I was called through: $_[0]";
 print "My args were: @_[1..$#_]";  }   #default


use invocant '$ME';
sub method { print "I was called through: $ME";
 print "My args were: @_";  }


use invocant '$MYSELF';
sub method { print "I was called through: $MYSELF";
 print "My args were: @_";  }


use invocant 'self';
sub method { print "I was called through: ", self;
 print "My args were: @_";  }


use invocant 'this';
sub method { print "I was called through: ", this;
 print "My args were: @_";  }


use invocant 'the_great_and_powerful_OZ';
sub method { print "I was called through: ", the_great_and_powerful_OZ;
 print "My args were: @_";  }


Backwrds compatibility is preserved, everyone's religion is covered, and
the choice is made explicit.

Damian

RE: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME )

[Damian Conway]

   > (Or, was it already intended that the implementation of 'use
   > invocant' might be some sort of compile-time macro?)

No. I think a macro facility for Perl should be more general than just 
whacking some code in at the start of every subroutine.

The use invocant was proposed as a way to maintain backwards compatibility 
and yet give everyone the invocant access syntax he or she personally favours.

Damian

RE: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME )

[Damian Conway]

   > What I meant to say was more along the lines of "if this could be done as a
   > macro, does it need to be a pragma, or could it be part of a standard macro
   > package?"
   > 
   > And, secondly, "if this *is* part of a standard macro package, wouldn't it
   > be cool to let it shove arbitrary code around rather than just doing
   > invocant access syntax?"

Sure. *If* the hypothetical macro package comes to be, this and many other
proposals could be subsumed by it. But that's a mighty big "if" :-)

Damian

Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME )

[Damian Conway]

   > > The use invocant was proposed as a way to maintain backwards
   > > compatibility and yet give everyone the invocant access syntax he
   > > or she personally favours.
   >
   > ...while also giving the compiler enough information to allow such
   > invocant access to execute in an optimized manner...right? C'mon,
   > I'm dying here thinking that all this (admittedly cool) stuff is
   > gonna end up giving Perl 6 even more OO overhead than Perl 5!
   
Use invocant won't add any runtime overhead. In fact it might save a smidgeon.


   > (What was it in the current edition..."up to 20x slower"? *sigh*)

Out by a factor of 10! I said "20 to 50 percent slower".


   > I'm also a bit concerned about readability and interoperability of
   > "Your Objects" vs. "My Objects." I guess invocant directives are
   > self-documenting and should not cause any problems, functionally.

I think they would *improve* readability. Certainly over $_[0], and
even over:

sub method {
my ($self, @args) = @_;
...
}

I'm *forever* writing that and just it clutters up the code.

Damian

Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME )

[Damian Conway]

   > I was talking about the hypothetical situation where you're (re)using or
   > modifying a bunch of code or classes written by different people and you
   > constantly have to be aware of which self-thingie to use in which file or
   > package or whatever.  Yeah, you can just glance up to the use ...
   > declaration, but it still seems a little like trying to make everyone
   > happy by avoiding the naming decision entirely.
   > 
   > Too much B&D for a Monday?

No. I *do* have sympathy with the desire for One True Way, but *only* if the 
access function is called C (my own religion ;-).

And *that's* the problem.

I wouldn't be averse to C as the default and C as a sop to
the Cerites and C<$ME>ophiles. But *they* might be!

:-)

Damian

Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME )

[Damian Conway]

   > What about
   > 
   > sub somename : method (@args) {...}
   > 
   > And leaving your$self some other way at the object?

That's the idea. By default you get the invocant in $_[0],
but you can have the compiler extract it for you via C.
Then you get to choose your access mechanism (lexical scalar or subroutine)
and what that access mechanism is called.

And yes, it *would* be great if methods honoured their parameter lists!

:-)

Damian

Re: RFC 159 (v1) True Polymorphic Objects

[Damian Conway]

   > Summary: I think these should all simply break down into a single
   > Boolification test of some sort, as occurs already with operator
   > overload.

Counter-summary: Although the high and low precedence binary ops could be
 rolled together, the current version of operator overloading
 is inadequate. An overloaded conjunction or disjunction
 is *not* an instance of boolification unless I *define*
 it to be so.


   > >LOGHIGHANDCalled in && context
   > >LOGHIGHOR Called in || context
   > >LOGLOWAND Called in and context
   > >LOGLOWOR  Called in or context
   > >LOGIFELSE Called in ?: context
   > 
   > I don't see that those should be any different from one another.
   > The essential feature in all of them is simply a Boolean test.  

Not necessarily. What if I am setting up a class that represents expressions
and want to be able to say:

$x = ExprNode->new();
$y = ExprNode->new();
$z = ExprNode->new();
$exprtree = $x + $y < $z && $z > $x * $y;

I can currently overload + < > * to do this, but not &&. That's broken.


   > if ($whatever) { A }
   > else   { B }
   > 
   > Why should that any of those be different than
   > 
   > $whatever ? A : B;

Because one is a control and one is an operator (i.e. yields a value).
What if I want that value to be another ExprTree?
   

   > Please also consider this:
   > 
   > % perl -MO=Deparse -e 'B() if A()'
   > B  if A ;
   > -e syntax OK
   > 
   > % perl -MO=Deparse -e 'A() && B()'
   > B  if A ;
   > -e syntax OK
   > 
   > The reverse if/unless tests are really just flow-control logicals
   > written funny (or vice versa, if you prefer).  Since "A && B" really
   > becomes "B if A", you'll have to tackle that there, too.  And even
   > if it didn't, it would seem something to be addressed.

Agreed. This is an internal optimization that that would need to be addressed
if boolean connectives were made overloadable.


   > And what about the negations?  Will !A trigger something special?

Yes. NOT must be overloadable too.


BTW, this is not just theoretical yearnings. I have written three modules
in the past year that do not work as well as they could, simply because it
is not possible to overload && and ||.

Damian

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

[Damian Conway]

   > =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 is exactly along those lines.

Damian

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

[Damian Conway]

   > > 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. Maybe you can reduce the syntax necessary to do that, but
   > > please don't do it behind our backs.
   > 
   > Well then, that's one nay vote.  :)

Make that two.

Damian

Re: RFC 189 (v1) Objects : Hierarchical calls to initializers and destructors

[Damian Conway]

   > > Furthermore, it proposes that both C and C methods
   > > should be invoked hierarchically in all base classes.
   > 
   > This bothers me.  It leaves no way to override the behavior of a
   > parent's SETUP and DESTROY, you can only overlay.  You mentioned that
   > this is normal for most other OO languages, so I presume there's a way
   > to deal with this?

The issue never arises. It's always assumed that as a client of the base
class a derived class has no business medding in the base's implementation.


   > Also, having never really desired hierarchical DESTROYs, its not
   > obvious to me why this is useful.  Could you explain why? (and for the
   > benefit of those who don't own OO Perl or made the mistake of loaning
   > it out.)

Suppose you inherit from a class with a non-trivial destructor.
Say, File::Lock, whose destructor releases a lock on a file when
the object goes out of scope. Now you create a File::LockAndKey,
which requires a special File::Key object to acquire the lock.
When the File::LockAndKey object goes out of scope, the File::Key object
has to be informed, so you need File::LockAndKey::DESTROY to do that.
As soon as you provide that method, File::Lock::DESTROY ceases to be
called and your files never unlock. :-(

   > PS  Proposing SETUP, UNIVERSAL::new() and the hierarchical calls are
   > three unrelated issues and should probably be three different RFCs.

I felt they were all inextricably linked. See below.


   > > package UNIVERSAL;
   > > 
   > > sub new { bless {}, @_ }
   > 
   > Shouldn't that be:
   > 
   > sub new {
   > my($proto) = shift;
   > my($class) = ref $proto || $proto;
   > 
   > bless {}, $class;
   > }
   > 
   > I prefer new() to be both an object and a class method 

You must have missed RFC 187, which covers that. I've proposed that
the second argument to bless *automatically* apply C :-)


   > Also, do we want to do anything with the rest of the arguments?

Err, I already was.

bless {}, @_;

is:

bless {}, $_[0], @_[1..$#_];

which passes the remaining ctor arguments directly to your C method.
Neat, huh? :-)

(That's why the C and default C are in the same RFC. Obviously 
I didn't make the connection clear enough in the RFC. I'll remedy that.)


Damian

Re: RFC 189 (v1) Objects : Hierarchical calls to initializers anddestructors

[Damian Conway]

   > What if you want to bless something but not call all its cascading
   > SETUPs?

Then don't *define* cascading SETUPS in the first place. :-)

C still would have the existing Perl 5 behaviour. Things 
only change if you add these new-mangled SETUP methods.

The point of welding SETUP calls to C is that it gives the class
designer a way of guaranteeing that you can't create an object (i.e. bless
it) without invoking the initialization. In fact, you don't even have to
be *aware* that a base class has setup behaviour - it just happens 
automagically when you bless your derived object.

That's a Good Thing, IMO.

Damian

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

[Damian Conway]

   > 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 do blessing. It does set-up. So it's called SETUP. :-)

I'm certainly not averse to a better name -- INIT would be ideal, if it
weren't already spoken for -- but I think BLESS would be misleading.

Damian

Re: RFC 189 (v1) Objects : Hierarchical calls to initializers anddestructors

[Damian Conway]

   > What happens on reblessing?

An excellent question, and one that has been exercising my mind for
some time now.

I have come to the conclusion that a reblessing must either:

* invoke the old class's DESTROY(s) and then invoke the
  new class's SETUP(s), or

* invoke some other hierarchy of automagic methods
  (REFIT? RESHAPE? MORPH? TRANSMOGRIFY?), or

* do nothing.

The first behaviour is by far the safest, but would seem to defeat the entire
purpose of reblessing.

The last behaviour is the most flexible but forfeits guaranteed clean-up.

The middle option is annoying because it adds yet another magic method.
But suspect it is the correct response.

Damian

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

[Damian Conway]

   > > private $self->{data} = $derdata;
   >    
   >   should be $derdatum here?

Yes. Thanks.

Damian

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

[Damian Conway]

   > BLESS is still my top choice by far, because while it doesn't do any
   > blessing, it's obvious what it's attached to.

I think it's misleading.
   

   > Remember, PRINT and PRINTF don't have to do any printing, nor do
   > POP, PUSH, etc, have to do any popping or pushing.

But SETUP *never* blesses. Never.

   
   > But they're all named for the function they're invoked by, so
   > there's considerable precedent in this area.

And I think it's *all* misleading. They *ought* to be called ON_PRINT,
ON_POP, etc.
   

Personally, I now favour BUILD/REBUILD, though I would be perfectly happy
with ON_BLESS/ON_REBLESS if all the others were fixed too.

Damian

Re: RFC 189 (v1) Objects : Hierarchical calls to initializers and destructors

[Damian Conway]

   > I'm still not totally convinced that its so horrid to make the
   > File::LockAndKey DESTROY call $self->SUPER::DESTROY manually...
   
Believe me, it is in a large, deep, and/or MI hierarchy!


   > but it does break encapsulation.

Exactly.


   > If you can figure a way out of the dilema I proposed above, I suppose
   > this makes sense.

Easy. Don't let File::Lock::Mac inherit from File::Lock. Have it *delegate*
to File::Lock instead. See my forthcoming C RFC.

Damian

Re: RFC 189 (v1) Objects : Hierarchical calls to initializers anddestructors

[Damian Conway]

   > The "multiple inheritance paths" one is good. I like that part a lot.
   > But the rest makes me really nervous if there's no way to override or
   > change it.

There is. I'll try and get the C RFC out today.


   > One thing nobody's brought up is this: What if you decide you want the
   > standard Perl 5 bless behavior, and you want to tweak the order of
   > calls. So, you don't define a SETUP. BUT, the author of a module you're
   > inheriting from defined a SETUP, not to your knowledge? This gets called
   > automatically by bless(), with no way to override it, either making you
   > manually undo it all or decide not to subclass it anymore. This is bad.

Delegation support will make "not subclassing" it trivial.

Damian

Re: RFC 189 (v1) Objects : Hierarchical calls to initializers and destructors

[Damian Conway]

   > Yes, welcome to the dirty, icky real world.  Life sucks, people will
   > write bad code, you will have to inherit from it.  Sometimes you have
   > to break a little encapsulation to make an omlet.  I'd rather it was
   > not so, but its better to accept it and deal than deny.
   > 
   > Of course, I'm sure Damian's hat isn't out of rabbits yet.

Delegation RFC coming later today..."This time, fer sure!!!"

Damian

Re: RFC 189 (v1) Objects : Hierarchical calls to initializers and destructors

[Damian Conway]

   > Also, its not entirely clear why method chaining is desired only for
   > constructor and destructors.  What about every other method?

Constructors and destructors are special. They're not about *doing*
something; they're about *being* (or not being) something.

A "doing" method *may* wish to make the object do everything its hierarchy
allows it to do: that's why I proposed C.

A "being" method *must* make the object be everything its hierarchy requires
it to be: that's why I proposed hierarchical constructors and destructors.


Damian

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

[Damian Conway]

   > From [EMAIL PROTECTED]  
Sat Sep  2 08:16:14 2000
   > Received: from ALPHA1.CC.MONASH.EDU.AU (alpha1.cc.monash.edu.au [130.194.1.1])
   >by indy05.csse.monash.edu.au (8.8.8/8.8.8) with ESMTP id IAA21970
   >for <[EMAIL PROTECTED]>; Sat, 2 Sep 2000 08:16:14 +1100 (EST)
   > Received: from tmtowtdi.perl.org ([209.85.3.25])
   >  by vaxc.cc.monash.edu.au (PMDF V6.0-24 #43886)
   >  with SMTP id <[EMAIL PROTECTED]> for
   >  [EMAIL PROTECTED]; Sat, 02 Sep 2000 08:15:57 +1100
   > Received: (qmail 28934 invoked by uid 508); Fri, 01 Sep 2000 21:15:31 +
   > Received: (qmail 28917 invoked from network); Fri, 01 Sep 2000 21:15:30 +
   > Date: Fri, 01 Sep 2000 15:15:26 -0600
   > From: Tom Christiansen <[EMAIL PROTECTED]>
   > Subject: Re: RFC 188 (v1) Objects : Private keys and methods
   > In-reply-to: Message from Perl6 RFC Librarian <[EMAIL PROTECTED]>
   >  "of 01 Sep 2000 20:59:10 -." <[EMAIL PROTECTED]>
   > To: [EMAIL PROTECTED]
   > Cc: [EMAIL PROTECTED]
   > Message-id: <19984.967842926@chthon>
   > Content-transfer-encoding: 7BIT
   > Precedence: bulk
   > Delivered-to: mailing list [EMAIL PROTECTED]
   > Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
   > List-Post: 
   > List-Subscribe: 
   > List-Unsubscribe: 
   > List-Help: 
   > Status: O
   > 
   > >=head2 Private methods
   > 
   > >The C keyword could also be applied to subroutines, to restrict
   > >where they may be called. Access rules similar to those for private hash
   > >entries would apply:
   > 
   > >package Base;
   > >sub new { ... }
   > >private sub check { ... }
   > 
   > How is this different/better/worse from "my sub"?

It complements it.

Private methods aren't lexically scoped.

They can be called (through a qualified name) anywhere in the
inheritance tree of the "owner" class.

Damian

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

[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 one particular use
   > that you have in mind for this, but in a generic sense it is a method
   > that is called when bless is called.

To me this points out the flaw in the entire naming scheme, not in my 
dissent :-)

I would much prefer to see:

PRINT   become  PRINTINGor  ONPRINT
PRINTF  become  PRINTFING   or  ONPRINTF
DESTROY become  DESTROYING  or  ONDESTROY
BLESS   be  BLESSINGor  ONBLESS

I realize this won't happen, but one can dream.

As it is, I intend to propose BUILD and REBUILD as the initializer
names, and mention BLESS/REBLESS as popular alternatives.

Ah, well, if worst comes to worst I can always (under RFC 128) write:

sub on (""subname, &subbody) {
*{caller()."::$name"} = $subbody
};


on BLESS {
...
}

on PRINT {
...
}

on DESTROY {
...
}


:-)


Damian

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

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

   > Then Larry can make the call.

As always.

Damian

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

[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 a HAS_A type of relationship?
   
Yep.


   > i have plenty of these in my new project and it is a pain.

Yep. Hence this RFC.


   >   PRL> use Class::Delegation
   > 
   > shouldn't that be use delegation? i think you have a cut and paste
   > error.

You're correct. Many thanks.
(That's what I get for pre-testing all the code in my RFCs! ;-)

   
  
   >   PRL> in  => [qw( getline getlines getc ungetc eof read sysread
   >   PRL>input_record_separator input_line_number )],
   > 
   > what about a way of delegating ALL the methods of an object? any way to
   > signify that?
   > 
   >in => 'ALL',
   >
   > will look up all current methods (maybe tagged?) from the class 'in' and
   > handle that. then you don't have to update all the delegation calls each
   > time the 'in' object changes.

Specifying C []> does that. See the description of "catch-alls"
below the bit you've quoted.


Damian

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

[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 193 (v1) Objects : Core support for method delegation

[Damian Conway]

   > Is this not just a module which creates the necessary subs in the calling
   > package ? The catchall can be done with an AUTOLOAD sub.

That's certainly how Class::Delegation is implemented.

It isn't quite adequate however, because if you trigger the AUTOLOAD and
it *fails* to delegate, you can only invoke $self->SUPER::AUTOLOAD(),
which locks out any potential AUTOLOADS on *other* branches of the
inheritance tree. Of course, the NEXT:: pseudoclass would fix that
limitation too.

The reason I proposed it for the core is simple: speed.

No-one will use delegation unless it's fast, and it won't be fast
unless it's integrated with the dispatch mechanism.

Damian

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

[Damian Conway]

   > When I see those empty arrayrefs, I think "delegate to *no* methods in
   > those classes stored in attr3 and att4," rather than "delegate all
   > method calls to those attributes." Just in the name of greater clarity,
   > I might like to see something like URI suggested:
   > 
   >   attr3 => [ALL]

It was (and is) a good suggestion. I suspect however that it should be

 attr3 => [__ALL__]

so that classes can still have an C method delegated.
(Yes, now they can't have an C<__ALL__> method,
 but maybe that's a Good Thing ;-)

   
   > Or perhaps (to borrow from SQL and to ignore the question of typeglobs
   > for the moment):
   > 
   >   attr3 => [*]

Read my lips: No New Syntax!

;-)

   
   > This way, I know that an empty arrayref means "all methods" rather than
   > "none."

Kinda redundant since that's the default behaviour, but perhaps useful as
a documentation mechanism.

Damian

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

[Damian Conway]

Too early in the morning, I wrote:

   >> I might like to see something like URI suggested:
   >> 
   >>   attr3 => [ALL]
   > 
   > It was (and is) a good suggestion. I suspect however that it should be
   > 
   >  attr3 => [__ALL__]
   > 
   > so that classes can still have an C method delegated.
   > (Yes, now they can't have an C<__ALL__> method,
   >  but maybe that's a Good Thing ;-)

Stupid, stupid, stupid! Of course, that should be:

attr3 => __ALL__

and then delegated methods can be named any(crazy)thing.

Damian

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

[Damian Conway]

   > >> This way, I know that an empty arrayref means "all methods"
   > >> rather than "none."
   > > 
   > > Kinda redundant since that's the default behaviour, but perhaps
   > > useful as a documentation mechanism.
   > 
   > Unless you change the default behavio[u]r to "don't delegate any method
   > calls to this object!".

Err, that *is* the default behaviour. Delegation doesn't occur unless
you specify it. Or am I missing your meaning here?

Damian

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

[Damian Conway]

   > use delegation
   > attr1 => [qw( method1 method2 method3 )],
   > attr2 => [qw( method4 method5 )],
   > attr3 => __ALL__, # Use all of them.
   > attr4 => [];  # Use none of them.
   > 
   > Yes, I realize that not putting attr4 in there at all is the same
   > (default) thing. It's just kind of a semantic thing in my mind.

Yes, that's what I meant by "documentation". :-)

Damian

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

[Damian Conway]

   > > When you want to turn off an inherited delegation in an ISA situation?
   > 
   > Um, I don't think I understand the question.
   
I'm confused by the question, too.


   > Delegation is not inherited. Any module you inherit from you won't
   > use for delegation, AFAIK. They're two different beasts.

But from outside the class, you can't tell whether a method was
inherited or delegated. Derived classes inherit whatever behaviour the
base class provides (method dispatch to ancestors or method delegation
to attributes). If your base class delegates calls to C, you
can prevent that delegation by defining a C method in the
derived class.

Is that what you meant?

Damian

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

[Damian Conway]

   > >  exists  (sometimes causes autovivification, which affects C)
   > 
   > That's not technically accurate--exists never causes autovivification.  


print keys %hash, "\n";
exists $hash{key}{subkey};
print keys %hash, "\n";

Or did that get fixed when I wasn't looking?

(And yes, of course I know the distinction that makes you techically
correct, but I don't think it is germane to this argument :-)

Damian

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

[Damian Conway]

   > > mark the entire hash as non-autovivifying (except via future calls to
   > > C -- see below)
   > 
   > This bothers me.  Name an operation in perl that, when applied to a single
   > element of an aggregate, affects all other elements of the aggregate
   > (especially future, as-yet-unborn elements).

There are remarkably few mutating operations that are specifically
applied to container elements. Of those few, it might be argued that
all of the following affect other elements in the way you ask about:

exists  (sometimes causes autovivification, which affects C)
delete  (affects C)
splice  (affects other element's indices)


   > Random idea: Only apply C to hashes, not elements.  This causes
   > the package name to automatically be added to the keys in the hash and
   > only allows access to the hash in the current package.  You can still
   > autovivify elements in the hash, but they're autovivifically private.

But that undoes one of the prime motivations for C. Namely, 
preventing autovivification-induced errors (due to misspelling for example).

   
   > > The C keyword could also be applied to subroutines, to restrict
   > > where they may be called. Access rules similar to those for private hash
   > > entries would apply:
   > 
   > I'd think this too would fall out of delegation.

Yes, delegation could be used to handle this -- albeit much less Lazily
than a simple prefix -- but only if it's possible to make some
attributes private and other's not.

Damian

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

[Damian Conway]

   > >  print keys %hash, "\n";
   > >  exists $hash{key}{subkey};
   > >  print keys %hash, "\n";
   > 
   > >Or did that get fixed when I wasn't looking?
   > 
   > No, the -> operator has not been changed to do lazy evaluation.

That's not required. All that is necessary is for C nodes
in the op tree to propagate a special non-autovivifying context to 
subordinate nodes.

E.g. exists $hash{key}{subkey}

exists
   \
  entry
  /   \
  entry   "subkey"
  /   \
  %hash   "key"


Is preprocessed to:

exists
   \
  entry(na)
  /   \
  entry(na)   "subkey"
  /  \
  %hash(na)  "key"

which prevents %hash from autovivifying, which causes the left-most
branch to fail (without autovivifying) when asked for "key", which in
turn causes the entire  to fail without autovivifying.


   > I just don't like reading "exists causes autovivification" when it
   > doesn't.

Sorry, I was being philosophically sloppy. A call to C can
*result* in autovivification (of something), though it does not itself
*cause* autovivification.

;-)


Damian

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

[Damian Conway]

   > Why can't we just apply the same warnings on hashes as we do on
   > variables in Perl?  Maybe a new lexical pragma:
   > 
   > no autoviv; # any autovivification carps (not just
   > # hashes)
   > 
   > no autoviv 'HASH';  # no new keys may spring into existence on
   > # any hash from this point forward

I don't appose these, but I don't think they solve the problem.
For a start they're compile-time, not run-time.


   > no autoviv '%hash'; # same but for a specific hash
   > no autoviv '@array';# same but for a specific array

These won't work, since most of the hashes were interested in
controlling autovivification on are anonymous (blessed) ones.


   > Regardless, I feel that "no autovivification" and "private-ization"
   > are orthogonal and should be treated as such in the languge.
   > 
   > private @person{'fname','lname'};  # make these private
   >freeze %person; # no new keys
   > 
   > But that's two keywords rather than one (and the second keyword isn't
   > that great for those people who already use FreezeThaw ;-)

I think that would prove annoying. Though I certainly don't oppose some
separate method to shut off autovivification (which C would
then be considered to call automatically).


   > P.S. BTW, I used Text::Autoformat for the first time on this very email.
   > Thanks Damian!

You're most welcome. I note that you didn't use it on the P.S. itself,
as Autoformat would have given you:

   > P.S. BTW, I used Text::Autoformat for the first time on this very
   >  email. Thanks Damian!

As, indeed, it just did! ;-)


Damian

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

[Damian Conway]

   > >That seems reasonable--except that I don't believe exists() merits
   > >any special treatment.  
   > 
   > More specifically, I think all non-lvalue context use of -> should be 
   > non-autoviv, whether exists or anything else.

I agree entirely.

In fact, I shall extend RFC 128 to allow subroutine parameter to specify
that they are non-autovivifying.

Damian

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

[Damian Conway]

   
   > >In fact, I shall extend RFC 128 to allow subroutine parameter to specify
   > >that they are non-autovivifying.
   > 
   > I'm not sure why it matters to the subroutine. We've already got
   > the hack so that
   > 
   > fn( $a[$i] )
   > or 
   > fn( $h{$k} )
   > 
   > will only autoviv those puppies if you muddle up $_[0]. This seems
   > sufficient.

But this:

fn( $h{key}{subkey} )

always autovivifies $h{key}, whether or no you muddle that puppy.

Hence the need to be able to specify that C's single argument be
evaluated in a non-autovivifying (an auto-mortifying???) context.



   > As for the rest, the behaviour has to be addressed where it's happening:
   > with the internals dereferencing operator itself.  How would you attach
   > a "nonautoviv" attribute to some pieces here:
   > 
   > $z[$i][$j] = $x[$i][$j] + $y[$i][$j];

CORE::OP_ADD ( $leftop : nonav,  $rightop : nonav ) { ... }

CORE::OP_ASSIGN ( $lval, $rightop : nonav ) { ... }


Damian

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

[Damian Conway]

   > > It may make sense to pass a leading argument to TIE which is the type
   > > of variable being tied.
   > > 
   > > tie Some::Class $foo, @args;
   > > 
   > > would produce:
   > > 
   > > TIE('SCALAR', 'Some::Class', @args);

Or, better still, pass a reference to the actual variable being tied.
That is:

tie Some::Class $foo, @args;

would produce the effect of:

Some::Class->TIE(\$foo, @args);

whilst:

tie Some::Class @foo, @args;

would produce the effect of:

Some::Class->TIE(\@foo, @args);


That way you can still get the underlying type if you need it --
via C -- but more importantly, you can get the previous
*value* of the variable, or a reference to it, so that your tied
variable can remember it.

That ability is very important when using tied variables as proxies
and is one of the major pains of the existing mechanism.

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???)

Damian

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

[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;
>
> would produce:
>
>TIE('SCALAR', 'Some::Class', @args);


and I was concerned that we were planning to remove the polymorphic dispatch.

(You may have to cut me some slack over the next few days if I say
stupid things or jump to unwarranted conclusions -- I am very ill and my
brain is not functioning properly %-)


Damian

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

[Damian Conway]

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')))


Otherwise, AMEN!

Damian

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

[Damian Conway]

   > I was hoping Damian would be able to suggest a Perlish way of handling
   > typechecking and polymorphism. 

If you mean static typechecking, then it is the natural enemy of polymorphism.
Either you give up interface polymorphism (a grievous loss) or you give
up static type-checking.
   
   > Interface polymorphism leads to a proliferation of pointless classes.

Actually, it's inheritance polymorphism that proliferates pretend classes
like Pet.

   > Perhaps instead of using inheritance for this, just have "implements"
   > and formal interfaces.  Then associate a variable with an interface
   > instead of an object type.
   > 
   >   package Cat implements Pet;
   >   package Dog implements Pet;
   > 
   >   my Pet $foo;
   >   $foo->feed();


Not bad. Though I'd suggest a pragma:

package Cat;
use interface 'Pet';

my Pet $foo;
$foo->feed();


Alternatively, one might imagine an attribute C<:must> that tells a variable
that anything assigned to it must provide certain methods:

my $foo : must(feed water play poop);

$foo = Manager->new();  # die "Manager object can't play".

An interface then becomes an alias for a particular C:

use attr_alias Pet => qw(feed water play poop);

my $foo : must(Pet)


Not sure which I like better. :-)

Damian

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

[Damian Conway]

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' consisting of nothing but:
   > 
   > 
   >  package Interface;
   > 
   >  sub virtual_method;
   >  sub virtual_method2 (#prototype);
   >   
   >  ...
   > 
   >  1;

You and I must have been separated at birth, Piers.

Here's what I wrote to Nat just yesterday:


There would be an C pragma or keyword (let's go
with keyword) that creates pseudo-packages with which lexicals
can be typed.

interface Fetcher;

sub fetch;

Interface specifications can only contain subroutine (method)
declarations, which describe what behaviours the interface requires.

Lexicals typed into interfaces (as opposed to packages) only require
that the objects assigned to them can satisfy the interface. I.e.
they don't care about the class of the object, only what is C
do.

my Fetcher $x;
my Dog $spot;
my NetSnarfer $z;

$x = $z;# ok because $z can fetch
$x = $spot; # ok because $spot can fetch
$x->fetch();# ok because Fetcher->can('fetch')
$x->bark(); # not ok because ! Fetcher->can('bark')


Interfaces might also act like pure abstract base classes when
inherited, so that:

package Dog;
use base 'Fetcher';

would cause a compile-time error if Dog failed to actually provide
a C method.


If you'd like to run with it, be my guest (but check with Nat first, in 
case he wants it).

Damian

Re: RFC 189 (v2) Objects : Hierarchical calls to initializers and destructors

[Damian Conway]

   > > =head2 The C method
   > > =head3 The C method
   > 
   > Hey! You left out the alternative names NEW / RENEW and BLESS / REBLESS
   > that we all like! :-(

Oops. You're correct. I will rectify that.

Damian

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

[Damian Conway]

   > This is an interesting proposal, but it seems to be missing
   > something, or maybe I am. It seems like once a single hash entry is
   > marked private, that it is then impossible to mark future entries
   > non-private...i.e. there is no corresponding unary "public"
   > function.

That's right. Perhaps it's too fascist. I'll think about it.

   > However, it seems that one side effect of achieving this is that
   > the hash of interest can no longer be used to present public data
   > of classes inheriting from it--they have no mechanism to add new
   > public data to the hash inherited from the superclass. While some
   > might argue that this is good, others might argue that it is bad,
   > and in the presence of such differing opinions, it certainly seems
   > like that choice should be left to the class author.

That can easily be achieved with a "public" keyword to parallel private.
   
   > The proposal also seems to leave somewhat unspecified what happens
   > to other existing non-private keys that were already in the hash at
   > the time the first private key was added. Do they continue to be
   > directly accessible via their names?

Yes. That's required to allow "private" to be used to extend pre-existing
classes cleanly.
   
   > Do they also get qualified with the package name?

No.
   
   > Is it an error
   > to insert a private key into a hash already containing
   > non-private keys?

...of the same name...yes.

I will make these clearer in the next version,

Thanks,

Damian

Re: RFC 163 (v2) Objects: Autoaccessors for object data structures

[Damian Conway]

Matthew, take a look at Class::Classless.

Damian

Re: RFC 251 (v1) Interpolation of class method calls

[Damian Conway]

   > > I suggest that the requirement be:
   > > 
   > >  print "There are Dogs::->num_dogs() species of dogs.";
   > > 
   > > I.e. use the unambiguous form of class method call.
   > 
   > Uhhh... I never even knew that worked.  With the exception of OO book
   > authors, everyone's going to trip over that.

Not if they read Camel III, which points out that Class::->method() is
the *only* syntax that's guaranteed to work.


   > I think the case of /\b[A-Z][\w:]*->[A-Z][\w:]*(/ in a string is
   > infrequent enough that its not going to be a problem.

Your probably right. But then again, /\b[A-Z][\w:]*::->[A-Z][\w:]*(/ is
a string so infrequent that it's *never* going to be a problem ;-)

Damian

Re: RFC - Interpolation of method calls

[Damian Conway]

   > >   my $weather = new Schwern::Example;
   > >   print "Today's weather will be $weather->{temp} degrees and sunny.";
   > >   print "And tomorrow we'll be expecting ", $weather->forecast;
   >
   > You are wicked and wrong to have broken inside and peeked at the
   > implementation and then relied upon it.

I think the issue is: *what* tempted them to be so wicked and wrong.
It is the fact that iniquitous direct access interpolated easily, whereas
virtuous accessor access didn't.

Perhaps this RFC should be subtitled: "Ne nos inducas in tentationem..."

:-)

Damian

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

[Damian Conway]

   > I'm not going to have time to produce an RFC on this in time for the
   > cutoff point. (Which seems painfully soon tbh).

I will be struggling to find the time too. I'll do my best.

Damian

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

[Damian Conway]

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

Damian

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

[Damian Conway]

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 Forest should be redesigned with *configurable*
Frogs.

But even if you can't redesign the forest, Perl still makes it easy to
impose a Japanese accent on Frogs wherever you need to:

my $forest = Forest->new();

if (can_see_Mt_Fuji()) {
local *Frog::speak = sub { "kerokero" };
# or:
# local *Frog::speak = \&Frog::Japanese::speak;

print $forest->make_noise();# "kerokero"
}

print $forest->make_noise();# "ribbit-ribbit"

Damian

Re: RFC 265 (v1) Interface polymorphism considered lovely

[Damian Conway]

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 ;-)


* The new C keyword would be unnecessary if *package
  specifications* could take attributes:

interface Fetcher;

  would then become:

package Fetcher : interface;


* There's also no need to distinguish C and C,
  since you've previously distinguished them by keyword. I would
  suggest that either C be used for both types of
  inheritance, or else the definition of an interface specification
  just be a regular C.


* Interfaces will also need to honour C
  (RFC 193), which provides yet another way of *not* actually
  specifying a method, yet still having it callable.


* The C pragma seems unnecessary, as it is sufficient
  to *declare* the autoloaded method, rather than *define* it.
  That is:

use deferred 'rollover';

  is really just:

sub rollover;

  BTW, this trick already works in Perl 5 (for making C
  acknowledge autoloaded methods).


Damian

Re: RFC 163 (v2) Objects: Autoaccessors for object data structures

[Damian Conway]

   > 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* one?
   > 
   > You can even take this further: that a Taxi is an object that contains
   > both a Car and a Driver. Poof, out the door go the conflicts...
   > 
   > In order to make this work behind the scenes in OO Perl, multiple
   > inheritance should automatically call SUPER classes with the *contained*
   > object of that superclass, not with the object itself. If there's both a
   > Driver and a Car in a Taxi, Car methods have no need to be messing with
   > the Driver's properties, anyway...
   > 
   > In my childish enthousiasm, I have the feeling that I've just hit a
   > jackpot...

Have you looked at RFC 193 (Objects : Core support for method delegation).
The mechanism described there is designed to solve exactly this problem.

Damian

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

[Damian Conway]

   > 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 
   > programmer.  That should not present a problem for others wishing to 
   > extend such code provided they understand the documentation and API.

That is precisely the point: the Perligata code is *not designed* such that
the language it translates is configurable. If you want configurability
you can either ask me to redesign the class, or just redesign the class
yourself on-the-fly by dynamically replacing the non-configurable bits
that you now want to configure.


   > It may not be desirable or possible to edit the code as you suggest 
   > with classes implemented in other languages, encrypted, or otherwise 
   > created in a format which is not familiar to the programmer.  It may 
   > also not be desirable to avoid published class APIs as that will 
   > break your code (as it should) when class implementations change.

In which case, you C (as described in RFC 193)
to wrap a new interface around the uncooperative Forest.

I have to leave this now, or I'll never get my remaining RFCs in
by the deadline. 

Bottom-line: I think there are other ways to solve the problem
you're proposing to solve. But don't let that stop you trying to
convince Larry that your way is better! :-)

Damian

Re: RFC 265 (v1) Interface polymorphism considered lovely

[Damian Conway]

   > >   * 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 shows that at all. Clearly, we *do* need to
differentiate between specifications of classes and specifications
of interfaces because:

my Classname $var;

applies a different constraint depending on whether 'Classname" is a
package or an interface.

But *because* we're differentiating declarations of classes and
interfaces I'm not clear on why we need to differentiate between
specifying that a class makes use of another class via inheritance and
specifying that a class makes use of another class via an interface.
Why wouldn't:

use base 'Classname";

do for both? The compiler can certainly tell whether 'Classname' is
the name of an interface or a package, and Do The Right Thing accordingly.
Or are you implying that packages and interfaces would dwell in separate
namespaces? If so: YUCK!

About the only reason I can see for having distinct declarators *and*
distinct inheritors, is to provide a syntactic belt-and-braces
(much as having the C declarator and the C<&> prefix).

But such redundancies have never seemed very Perlish to me.

On the other hand, if you can show me an example where there's a critical
difference between C and C, I'll
happily retract my suggestion.

Damian

Re: RFC 251 (v1) Interpolation of class method calls

[Damian Conway]

   > print "There are Dogs->num_dogs() species of dogs.";
   > 
   > would interpolate as:
   > 
   > print 'There are '.Dogs->num_dogs().' species of dogs.';

I suggest that the requirement be:

 print "There are Dogs::->num_dogs() species of dogs.";

I.e. use the unambiguous form of class method call.

Damian

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

[Damian Conway]

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,
value => $original,
  }, $class
}

sub ReadOnly::FETCH { return $_[0]->{value} }

# and later:

my $x = 10;
tie $x, 'ReadOnly';
print $x;   # still prints 10


I feel that additional functionality is *very* important.

Damian

Re: RFC 265 (v1) Interface polymorphism considered lovely

[Damian Conway]

   > >  * There's also no need to distinguish C and C,
   > >since you've previously distinguished them by keyword. I would
   > >suggest that either C be used for both types of
   > >inheritance, or else the definition of an interface specification
   > >just be a regular C.
   > 
   > I dunno. I like the Javaesque distinction between a class *being* a
   > Dog and *implementing* Fetcher. Sure it's syntactic sugar, but I think
   > it's good sugar.

Okay. I don't have a problem with a small amount of "belt-and-braces".


   > >* The C pragma seems unnecessary, as it is sufficient
   > >  to *declare* the autoloaded method, rather than *define* it.
   > >  That is:
   > > 
   > > use deferred 'rollover';
   > > 
   > >  is really just:
   > > 
   > > sub rollover;
   > > 
   > >  BTW, this trick already works in Perl 5 (for making C
   > >  acknowledge autoloaded methods).
   > 
   > Hmm... point taken. Though I do think C could be looked
   > upon as a vaguely nice bit of syntactic sugar...

Too much sugar rots your teeth. ;-)

I think C falls into that category, given that there's
already an easier way to do it in the existing language.

Damian

Re: RFC 319 (v1) Transparently integrate C

[Damian Conway]

Somewhat to my own surprise, I really like this RFC.

My only disagreement is that I think it's a mistake to defer the call 
to TIEWHATEVER until the first access. It ought to be done when
the typed variable is declared, so that it's easy to determine where
a variable is tied.

There is also the issue of how one passes multiple
arguments to set up the tied variable in the first place.
Something like this perhaps:

my Tieable $var : tie(@args) = $init_val;

Also, I didn't see any reference to the fact that RFC 218 will 
have to change to "...just an assertion, unless the package autoties,
in which case it's no longer an assertion".

Damian

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

[Damian Conway]

RFC 189 covers this.

Damian

Re: Stupid Newbie Question

[Damian Conway]

Schwern explained:
 
   > Going away?  No way, it's SPREADING!  We might wind up with AUTOGLOB, too.
   > 
   > http://dev.perl.org/rfc/324.pod

Though it won't be called AUTOGLOB (globs *are* going away),
and its semantics might be closer to those portrayed in:

http://www.yetanother.org/damian/Perl5+i/autovivify.html

Damian