On 5/19/01 4:49 AM, Graham Barr wrote:
> On Sat, May 19, 2001 at 06:41:29PM +1000, Damian Conway wrote:
>> Graham wrote:
>>> On Fri, May 18, 2001 at 10:36:59PM -0400, John Siracusa wrote:
>>>>> print keys $foo.prop; # prints "NumberHeard"
>>>>> print values $foo.prop; # prints "loneliestever"
>>>
>>> This is an example of one of my concerns about namespace overlap
>>> with methods. What would happen if there was a method called prop ?
>>> Have we basically said that there cannot be a method called prop ?
>>
>> No, we have basically said that there cannot be a method called prop if you
>> want to access the object's properties through its prop property.
>
> Which mean that any class which defines a method prop, prevents any user
> from determining the properties of any of its object instances.
>
> I am not saying that this is a bad thing, but it will need to be docuemnted
> that doing this has such consequences. Unless there is another syntax
> for determining all the properties of a value.
To recap my previous message(s) on this topic...
My interpretation of this has always been than it's a naming *convention*
issue. After all, "system stuff" and "user stuff" have always had to live
together in the various Perl namespaces. But historically, there've been
guidelines to make this manageable.
Take the method namespace, for example. That's shared by the system and the
user, with the simple guideline that the system claims uppercase methods
(AUTOLOAD, TIEHASH, etc.) The class/package namespace follows the same
guidelines (ARRAY, HASH, SCALAR, etc.)
Even Perl 6 properties (appear to :) solve the namespace problem by
convention: all-lowercase properties are reserved for built-ins: constant,
memoized, etc. User-defined properties are Title Cased: $foo.Notes,
$bar.Purpose, etc.
The problem area is the intersection between:
* reading built-in properties, and
* calling user-defined methods
Both lay claim to the $foo.lowercase_letters syntax and naming convention,
leading the the problems cited in other posts.
Actually, it's only as big a problem as the proliferation of built-in
properties makes it. If the list of built-in properties is small and fairly
constant, it's probably something that can be dealt with.
I've tossed around ideas like changing the convention for built-in
properties to uppercase (to match built-in classes and methods), but it
still strikes me as ugly:
$foo is CONSTANT = 5;
if($foo.CONSTANT) { ... }
Ick. Then there's the suggestions to differentiate between method calls and
property access, but that kind of kills a huge part of the whole properties
scheme. I basically have no good solutions at this point, heh. I just
figured I'd re-spew my take on the subject for the benefit of this list...or
something :)
-John
