pdd15_objects.pod, attributes, properties, and life

[Mitchell N Charity]

docs/pdds/pdd15_objects.pod, =head2 Translation, includes (edited)

What .NET calls an attribute parrot calls a property
What .NET calls a property parrot calls an attribute

Ouch.

In these lines one hears the echos of future years of confusion,
endlessly repeated explanations, failed searches, lost hours, lost
opportunities, and simple pain.

Perhaps adding a line or two of explanation would be worthwhile? ;)

Just so folks know we are aware .NET is likely to be a dominant
vocabulary for the next few years, but that this choice has advantages
which outweigh the live(s) it may cost. (say 80khr/person-work-life)

Mitchell

[Dan Sugalski]

At 5:29 PM -0500 2/26/04, Mitchell N Charity wrote:
>docs/pdds/pdd15_objects.pod, =head2 Translation, includes (edited)
>
> What .NET calls an attribute parrot calls a property
> What .NET calls a property parrot calls an attribute
>
>Ouch.

Oh, yeah. No matter which way we go we'll be confusing someone, since
there are languages that call what we call an attribute an attribute.
The .NET reversal's just the big nasty one.

Not much for it--we've got to choose some name, and I grabbed the one
that Perl 6 was shooting for.
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk

[Paolo Molaro]

On 02/27/04 Dan Sugalski wrote:
> > What .NET calls an attribute parrot calls a property
> > What .NET calls a property parrot calls an attribute

[...]

> Oh, yeah. No matter which way we go we'll be confusing someone, since
> there are languages that call what we call an attribute an attribute.
> The .NET reversal's just the big nasty one.

In the CLR properties are defined by:
a name
an optional set method
an optional get method
One of the two methods must exist (enabling readonly/writeonly
properties). So, the only thing CLR properties have in common with
Parrot attributes is that they both have a name:-) From the pod
description it looks like Parrot attributes have per-object values,
though CLR properties can be static or instance properties.
At least half of the name confusion goes away by simply rewriting the
sentence to:
What .NET (and C/C++ etc) calls a field parrot calls an attribute
Though I would personally just use the name 'field' for them and have no
need to explain to programmers what attributes are.
Apparently, there are two vtable methods to get and set an attribute,
still this doesn't mean an attribute is like a CLR property, since the
access methods are per-class in Parrot, while per-property in the CLR.

Small comment on a chunk of the doc:
=item addattribute Px, Sy

Add attribute Sy to class Px. This will add the attribute slot to all
objects of class Px and children of class Px, with a default value of
C<Null>.

This basically means that all the alive objects in the heap must be
considered and a possibly expensive isa() op is run on them and if they
are derived from Px a lot of memmoves would be going on in the
attriibutes array. Hope no one calls this method on a busy server:-)

Next issue: parrot properties. The description says:
=item Property

A name and value pair attached to a PMC. Properties may be attached to
the PMC in its role as a container or the PMC in its role as a value.

Properties are global to the PMC. That is there can only be one
property named "FOO" attached to a PMC, and it is globally visible to
all inspectors of the PMCs properties. They are I<not> restricted by
class.

Properties are generally assigned at runtime, and a particular
property may or may not exist on a PMC at any particular
time. Properties are not restricted to objects as such, and any PMC
may have a property attached to it.

Basically a parrot property has a name and a value "generally assigned
at runtime" to a PMC (considered as a value or as a container), whatever
its type.
A CLR attribute is a completely different thing:-) It is an object
defined only at compile time for some specific metadata elements:
assemblies (libraries), types, methods, fields, method
arguments, properties, events.
They have no name, so there can be multiple different objects of the
same type associated to a metadata element (actually getting the same
attribute object repeatedly will give different object instances...).

So the other half of the naming confusion goes away by simply removing
the misleading statement:

What .NET calls an attribute parrot calls a property

Hope this helps. Thanks.
lupus

--
-----------------------------------------------------------------
lu...@debian.org debian/rules
lu...@ximian.com Monkeys do it better

[Dan Sugalski]

At 4:41 PM +0100 2/27/04, Paolo Molaro wrote:
>On 02/27/04 Dan Sugalski wrote:
>> > What .NET calls an attribute parrot calls a property
>> > What .NET calls a property parrot calls an attribute
>[...]
>> Oh, yeah. No matter which way we go we'll be confusing someone, since
>> there are languages that call what we call an attribute an attribute.
> > The .NET reversal's just the big nasty one.

[Paolo's property and attribute for .net explanation snipped]

Okay, now I'm *really* confused. This seems to contradict the
explanations in the "C# in a Nutshell" book, assuming that C# and
.NET use the same underlying terminology. OTOH I could be misreading
the book, and OTTH I'd be foolish to not take Paolo's explanation as
most correct. I think I may well just chop out part of the glossary.

I swear, I'm going to rename these things to Fred and Barney and not
tell anyone which is which...

[Gordon Henriksen]

On Friday, February 27, 2004, at 12:22 , Dan Sugalski wrote:

> At 4:41 PM +0100 2/27/04, Paolo Molaro wrote:
>> On 02/27/04 Dan Sugalski wrote:
>>> > What .NET calls an attribute parrot calls a property
>>> > What .NET calls a property parrot calls an attribute
>> [...]
>>> Oh, yeah. No matter which way we go we'll be confusing someone, since
>>> there are languages that call what we call an attribute an attribute.
>> > The .NET reversal's just the big nasty one.
>
> [Paolo's property and attribute for .net explanation snipped]
>
> Okay, now I'm *really* confused. This seems to contradict the
> explanations in the "C# in a Nutshell" book, assuming that C# and .NET
> use the same underlying terminology. OTOH I could be misreading the
> book, and OTTH I'd be foolish to not take Paolo's explanation as most
> correct. I think I may well just chop out part of the glossary.
>
> I swear, I'm going to rename these things to Fred and Barney and not
> tell anyone which is which...

Ordered by ascending esotericism:

Fields: Class data members.
Properties: Syntactic sugar for getter and setter methods.
Attributes: Extensible metadata for compile-time objects.

In context:

using System;
using ICLUBcentral.Testing;

namespace ICLUBcentral.Example {
class Eg {
// This is a field:
private int _num;

// This is a property:
public int Num {
get { return _num; }
set { _num = value; }
}

[TestCase(2)] // <-- This is an attribute.
private void _TestNum() {
Test.OK(Num == 0, "default value");
Num = 43;
Test.OK(Num == 43, "changed value");
}
}
}

I have a program which will load the resultant DLL and run all methods
which have a TestCase attribute applied to them.

Am very, very sure of this terminology.

—

Gordon Henriksen
mali...@mac.com