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
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
private $self-{data} = $derdata;
should be $derdatum here?
Yes. Thanks.
Damian
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
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 Cuse delegation RFC out today.
One thing nobody's brought up is this: What if you decide you
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
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
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
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
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
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 Cexists nodes
in the op
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
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;
Piers wrote:
The behaviour of the my Dog $spot 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
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.
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 Cuse base 'Interface' but with
'Interface' consisting of nothing but:
=head2 The CBUILD method
=head3 The CREBUILD 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
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
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
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
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 Cinterface
syntax instead ;-)
21 matches
Mail list logo
