On 8/17/00 5:36 PM, Perl6 RFC Librarian wrote:
> NOTE: these and other examples assume Highlander Variables (RFC 9)
> where '$mage', '@mage' and '%mage' all refer to different "views" of
> the same variable, rather than different variables as in Perl 5.
> Otherwise read '@mage' as '@$mage' and '%m
On 8/19/00 11:50 AM, Randal L. Schwartz wrote:
> I actually don't like the literal $ME. It usurps a variable name that
> has been legal for customer use in prior Perls. Why not use something
> more "system-belonging" like %_ or even $_? In fact, "self" in $_ and
> "args" in @_ has a nice symmet
On 8/19/00 4:04 PM, Damian Conway wrote:
> You can have your cake, but not force us to eat it too...
Come, partake of the Loony Cake... :)
> Like $AUTOLOAD, $ME would be dynamically scoped:
>
> package LoonyBin;
>
> sub self {$ME};
>
> sub get_polite_age : method {
> return (self->age >= 40)
On 8/22/00 12:45 AM, Uri Guttman wrote:
> perl could be the uber OO language, capable of emulating ANY object
> style.
Is this more important than improving performance vs. Perl 5 OO?
Not IMO; I want speed. Hey, if I can have both, I'm all for it.
But if forced to choose...
-John
On 8/28/00 3:09 PM, Damian Conway wrote:
>> (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.
>
On 8/28/00 3:35 PM, Damian Conway wrote:
>> ...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 overhea
On 8/28/00 3:53 PM, Damian Conway wrote:
>> 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.
Yeah, there'll never be consensus on this list or in the comm
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;
> private $self{seed} = rand; # okay
> $s
On 9/1/00 5:44 PM, Nathan Wiger wrote:
>> sub SETUP {
>> my ($self, @ctor_data) = @_;
>> # initialization of object referred to by $self occurs here
>> }
>
> Hmmm. I'm not sure if I like this. I like the *idea* a lot, but I must
> say that I think I quite like RFC 171's approach better.
I haven'
On 9/1/00 8:02 PM, Nathan Wiger wrote:
>> I haven't commented on RFC 171 because I assumed it would be shot down
>> quickly by the Major Contibutors(tm), but let me just say now that I'm
>> firmly in this camp:
>
> Funny, I don't see much difference between RFC 171 and this RFC:
>
> 171: constr
On 9/1/00 8:32 PM, Damian Conway wrote:
> 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.
Off the top of my head, all I've got are BUILD and MAKE. I don't mind SETUP
though, but BUILD might be a little
On 9/1/00 8:39 PM, Tom Christiansen wrote:
> What happens on reblessing?
Go back to the old behavior in that case? (Re-blessing has always
smelled like "Perl casting" to me...ick.) Maybe we'd need an "unbless" to
round out the desired (evil ;) functionality.
-John
On 9/2/00 12:16 AM, John Tobey wrote:
> Every base's SETUP gets the same argument list? That seems highly
> undesirable from an OO-purity standpoint. Or do you have a syntax for
> member initializer lists in store for us?
I've been thinking about this too. I want some sort of decision to
save
On 9/2/00 11:34 AM, Nathan Wiger wrote:
> It doesn't seem that it's that hard to add a single line to your SETUP or
> BLESS or whatever method that calls SUPER::SETUP.
I'm pretty sure one of the big points about the system described is that it
ensures both that there's always a predictable and au
On 9/2/00 12:12 PM, Nathan Wiger wrote:
> I think this RFC could work for this, but as I noted in a private email
> to Damian I'd rather see a whole new keyword made, maybe "setup"?
>
> sub new { setup {}, @_ }
> sub SETUP { ... }
Sure, but does setup() bless? That's the question... :) In othe
On 9/18/00 3:44 AM, Damian Conway wrote:
>>> 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
16 matches
Mail list logo
