Re: properties
On Tue, May 22, 2001 at 12:29:33PM +1000, Damian Conway wrote:
if so, then wouldn't it be safer to put properties inside a special object
associated with each object (the 'traits' object) so there would be little
namespace collision?
We actually want the possibility of that kind of namespace collision:
for polymorphism.
Many people keep bringig this up as a confusion and you give the same reply.
However there has not yet, AFAIK, been any description of how having a method
overload a property is useful.
If there is some compelling reason that this is a must, then fine. But many
people seem to be finding this a point of confusion.
Personally I don't see that the gain is greater than the confusion. I would
rather see properties be accessed via a different operator other than dot (.)
If a class wants to manipulate a property via a method they still can, the user
just has to call the method instead of accessing the property directly
With the current approach I can see most code accessing properties with $var.prop{name}
because they want to make sure they get the property and not a method, whereas
it would be shorter, in the common case, to have something like $var'name
Graham.
RE: Properties, deleting them, and dump
From: Carl Johan Berglund [mailto:[EMAIL PROTECTED]] Other than that, I think I like Larry's idea to have one variable_is and one value_is method. I would also very much have Data::Dumper built in as 'dump', so that I could say I would rather the bike shed be painted: @var_prop = keys $foo.is; @val_prop = keys $foo.value.is;
RE: Properties, deleting them, and dump
At 09.46 -0500 01-05-22, Garrett Goebel wrote: I would rather the bike shed be painted: @var_prop = keys $foo.is; @val_prop = keys $foo.value.is; The btw/prop/value_is/variable_is/is method(s) will return a reference to the properties hash, so Perl 6 will certainly support getting the keys of it. No matter what colour the bike shed is. Cajo. -- Carl Johan Berglund, [EMAIL PROTECTED], 0708-136 236 Adverb Information, http://www.adverb.se, 08-555 788 80
RE: properties
From: Graham Barr [mailto:[EMAIL PROTECTED]] On Tue, May 22, 2001, Damian Conway wrote: if so, then wouldn't it be safer to put properties inside a special object associated with each object (the 'traits' object) so there would be little namespace collision? We actually want the possibility of that kind of namespace collision: for polymorphism. Many people keep bringing this up as a confusion and you give the same reply. However there has not yet, AFAIK, been any description of how having a method overload a property is useful. What I don't understand is why we need properties as yet another layer of polymorphism enabling pseudo OO-Perl? Why not use the everything is an object paradigm and say that variable and value objects have default property methods that can be called and/or overridden? Hell, why not do tying by overloading default variable methods while we're at it? Or make magic accessible to mere demigods by providing something akin to $foo.value.magic.??? accessors. What is UNIVERSAL::can($foo, 'new') going to return if there is a variable and/or value property 'new' set on $foo? Blurring properties and object methods screws with \L$object \u$class method vs. \L$built \u$user property naming conventions. To my knowledge, no one has yet proposed how you can clear a user-defined property on a value?
Re: properties
On Tue, May 22, 2001 at 10:10:55AM -0500, Garrett Goebel wrote:
What is UNIVERSAL::can($foo, 'new') going to return if there is a variable
and/or value property 'new' set on $foo?
undef if there is no new method.
To my knowledge, no one has yet proposed how you can clear a user-defined
property on a value?
delete $foo.prop{name};
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
