Re: Properties & Methods

Front page | perl.perl6.language | Postings from April 2003

Re: Properties & Methods

Thread Previous | Thread Next

From:

Piers Cawley

Date:

April 7, 2003 22:14

Subject:

Re: Properties & Methods

Message ID:

m2el4do9gd.fsf@TiBook.bofh.org.uk

Luke Palmer <fibonaci@babylonia.flatirons.org> writes:

> Another one of my little annonyances in the current state of P6 is how
> run-time properties are accessed.  Accessing properties as methods is
> pretty, but I see it as potentially dangerous.
>
> Adding a new method to a class that happens to be the same as
> somebody's property would be lucky to get some kind of signature
> error.  In the worst case (and unfortunately, probably the common one)
> the method will have only internal side-effects, and it will be being
> called at apparently random times.

    class Foo {
        ...

        my method only_internal_side_effects { ... }
    }

Now, when something outside Foo's class hierarchy calls
$a_foo.only_internal_side_effects it would only see the property, but
when something inside the hierarchy calls it it will see the method
(which is definitely the right thing; it's unlikely to know about the
clashing property). 

> Ick.
>
> I think it'd be better to include some kind of "property hash" in
> Object, or have a keyword for checking properties.

I thought we had that already, just as an option. This is one of those
things I can argue both ways I think. Having properties that look like
methods can be really useful and also rather risky. Question is, does
the usefulness outweigh the riskiness?

> Also, junctions have this problem.  Apparently a junction only
> distributes a method call if the method isn't in the Junction class
> itself.   Consider this:
>
>     $junction.$foo();
>
> Depending on the I<run time> value of C<$foo>, the junction's method
> would be called or its junctends' methods.  That's not right.
>
> For this one, I don't think it would be too bad to have a global sub
> C<states> that takes a junction as its argument.  That removes the
> spooky intercepting delegation that the method way imposes.

Doesn't need to be a global sub, can be a method on Object:

    class Object {
        method eigenstates { return $_ }
    }

'states' is too useful a methodname to use in this fashion I
think. 'eigenstates' is almost certainly wrong too...

-- 
Piers

Thread Previous | Thread Next