1) It looks like properties proposed will introduce an inconsistency in
naming conventions. In OO-Perl programmers are advised to use leading
lowercase for object methods and leading uppercase for class methods.
Properties are lowercase for built-ins and uppercase for user-defined. Don't
we need to change the naming conventions on one or the other to avoid
confusion? Could we do something like Python and make built-in properties
pre- and post-pend __?
sub foo is __lvalue__ { ... }
Larry Wall writes:
>
> We're calling them properties now instead of attributes
> because we don't want people to confuse properties with
> object attributes (except to the extent that we do).
2) Are you sure you don't want people to confuse them? I certainly am, and
the blurred line between the two seems intentional to me. After all, isn't
it an explicit goal to make properties overloadable with object methods?
I.e., sharing the same object method call syntax.
Several people have posted messages asking that the distinction be made more
explicit and visible, and Damian has countered that doing so would defeat
the whole purpose.
Damian Conway writes:
> Er...yes...that's rather the point of the exercise: to be
> able to polymorphically override the behaviour of
> properties by defining methods.
Larry Wall writes:
> I've seen uses for compile-time properties on variables,
> and run-time properties on values, but I've not yet seen
> any decent use for run-time properties on variables. So
> I'd be inclined to disallow properties on lvalues unless
> they're in a "my" or "our"
3) Can someone state what the purposes of properties are in the above cases?
Compile-time optimizations... and what else? And why do we need properties
to do this? I.e. why can't properties simply be variable and value
attributes in an OO sense.
4) In regard to disallowing properties on lvalue subroutines: What about
function signatures? Isn't that a necessary property of the subroutine?
5) As a few people have mentioned, there seems to be a similarity between
"tying" <=> "variable properties" and "overloading" <=> "value properities".
Are these semantically different concepts, or is it possible that properties
vs. tying/overloading are 2 ways of doing the same thing? I.e., being able
to tie a scalar by defining FETCH STORE and CLEAR properties on the
variable? Create objects by calling a constructor which returns a value with
properties?
6) People have asked how you clear a property. I'm assuming that while you
might be able to clear runtime properties, that it would be impossible to
clear or modify compile-time ones at runtime.
Damian Conway writes:
>
> sub SCALAR::Purpose ($value) {
> return "This scalar value's purpose is $value.prop{Purpose}"
> }
7) This example makes me wonder about the properties as actions question.
Which ties back into tying. Would it be possible to allow properties to
optionally have both "data" and an associated code block?
my $baz;
my $foo is
FETCH () { $baz }
STORE ($) { $baz = $_[0] };
8) Last... One thing that bothers me in the Perl 5 implementation of
attributes, is that there is no way for a subroutine's attributes to access
the lexical scope of the subroutine. Would this be on the table for Perl 6?
If we allowed properties to optionally include a code block, then could this
code block execute within the same lexical scope as the subroutine proper?
