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.
Properties, deleting them, and dump
At 08.53 +0100 01-05-22, Graham Barr wrote:
>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
I would write $var.name and simply not define a prop method if I
didn't want one.
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
print dump $var;
and get a complete printout of value, variable properties and value
properties of the $var variable. (And not a core dump, as I would get
in Perl 5.)
Tangentially, would it be possible to have
dump $var;
in void context automatically call print (or warn (or carp)), while
it in scalar context returns what it in void context would have
printed?
Regarding deleting properties, I don't see a need for deleting
variable properties, and value properties die when we replace a value
with a new one. To get rid of all properties while preserving the
value, one could do something like:
$var = $var.value
To delete a single run-time property, we could reuse the existing
'delete' keyword, that deletes hash elements:
delete $var.name;
These thougts are just my $0.02. I'm sure Damian and Larry have
thought this out in much more detail.
Cajo.
--
Carl Johan Berglund, [EMAIL PROTECTED], 0708-136 236
Adverb Information, http://www.adverb.se, 08-555 788 80
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
On Tue, 22 May 2001, Graham Barr wrote:
> On Tue, May 22, 2001 at 12:29:33PM +1000, Damian Conway wrote:
> >
> > 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.
>
> 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.
I am one of the people who brought this up as confusing and
requested a separate syntax, so I obviously agree with Graham. I would
like to vote against the $var'name suggestion, though, for several
reasons:
- it could conflict with old Perl 4 code (which is still out
there),
- having an unmatched ' screws up most highlighting editors
- I personally think it is an unattractive syntax (MHO)
Dave
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]
