On 4/30/2016 11:52 PM, Rowan Collins wrote:
Just thought I'd point out this contradiction.

It seems to me that "Data Annotations" are one particular use of a
language feature which is called "attributes". Looking through the list
of descendants of the base Attribute class [1], I can see lots of
different usages, most of which don't refer to "annotations" anywhere
that I can see, only to "applying the attribute". This is true even in
prose introductions such "Controlling XML Serialization Using
Attributes" [2] which has sentences like "Attributes can be used to
control the XML serialization of an object or to create an alternate XML
stream from the same set of classes." and "By applying a
XmlArrayAttribute, you can change the name of the XML element, as follows."
I guess I am wrong then at it truly is MINFU as others claim.
On 4/30/2016 11:52 PM, Rowan Collins wrote:
Why should we not look outside that namespace? What about that namespace
makes it so special?

If we transpose that logic to PHP, are you saying that it's OK for
php.net to refer to "attributes" to discuss the feature, as long as
Doctrine carries on using "annotations" for its usage of that feature?
Annotations are generally ignored by the compiler but are retrievable
via reflection at runtime:
Unlike comments, annotations are reflective in that they are embedded
in the files generated by the compiler and may be retrievable at

--- http://c2.com/cgi/wiki?AnnotationMetadata
metadata added to a document or program

--- https://en.wiktionary.org/wiki/annotation
While attributes are part of the actual program, we already had public,
protected, and private but there are many more like final, abstract,
static and properties of objects are also commonly called attributes.
An option or setting belonging to some object.

A semantic item with which a method or other code element may be

Properties can /be/ marked as obsolete with an attribute, which will
cause the compiler to generate a warning if they are used.

--- https://en.wiktionary.org/wiki/attribute
Class member variables are called "properties". You may also see them
referred to using other terms such as "attributes" or "fields", but
for the purposes of this reference we will use "properties".

--- https://secure.php.net/language.oop5.properties
On 4/30/2016 11:52 PM, Rowan Collins wrote:
Language is a funny thing: words mean what they mean because we agree on
that meaning, and understand each other when we use it. A "theoretical
definition" is no use at all if it's not how people actually use a word.
Computer Science terms are doubly-cursed here, because rather than
coining new words, we tend to stretch metaphorical use of existing terms
from other fields, even when those fields overlap with our own.

If a language as popular and influential as C# calls this feature
"attributes", as I hope I've demonstrated it does, then it's hard to say
that that's the "wrong" name - it is the name everybody in that
community uses, and they all agree and understand its meaning.
That is why we use dictionaries.
On 4/30/2016 11:52 PM, Rowan Collins wrote:
I still don't really understand what you mean by this. As far as I can
see, the feature in Perl is exactly equivalent to the one proposed for
PHP. Do you mean there is something in PHP which you consider to have
prior claim to the word "attributes"?
Yes and I explained it multiple times already: public, protected,
private, final, abstract, static, ... all of them are attributes that
are applied by the compiler to alter data and they are reflective.

However, one could argue that the properties themselves are attributes.
That is what Sebastian Bergman complained about with the term. It is
simply too ambiguous and he is correct there.

Hence, it is better to talk about public, protected, and private solely
as /access modifiers/ and final, abstract, and static simply as
/keywords/. The latter might be a very broad term but it is at least
unambiguous: http://onelook.com/?w=keyword&ls=a
On 4/30/2016 11:52 PM, Rowan Collins wrote:
I didn't say it was "wrong", I said it showed that "annotation" is just
as ambiguous a term as "attribute". Pretty much any syntax can be
referred to as an "annotation" (see the C# "in"/"out" example earlier),
just as pretty much any modifier or property can be referred to as an
"attribute". So in an ideal world, we wouldn't use either term if we
wanted to unambiguously refer to a new feature. At best, the Rust
example is irrelevant to the discussion; at worst, it weakens the case
for "annotation" being an unambiguous term, which I thought was part of
your argument.
I disagree in the context of programming. There are multiple
dictionaries available (and linked in this thread) that define the term
over and over again in the same manner. However, the term attribute
changes its meaning based on context.
On 4/30/2016 11:52 PM, Rowan Collins wrote:
Absolutely! But all we're deciding is what the language will call the
overall feature - what page it will be on in the manual, what word will
be used in the error messages, etc. In some languages, like Java, those
resources would refer to "Annotations"; in other languages, like C#,
those resources would refer to "Attributes".

Both terms have advantages and disadvantages, precedents and
connotations - and both have potential ambiguities with other uses of
the normal English words that have been borrowed. In the end, it really
is mostly a matter of taste.
Very true but the last sentence is not in my book; maybe in .NET, Perl,
and Hack.

I guess we can summarize:

- .NET world, Perl, and Hack are different than others.
- Rust is complicated and is definitely different than others.
- All others use the term according to most/all dictionaries.

- Richard thinks annotations is the correct term. [1]
- Rowan likes annotations but thinks attributes are equally suited.

I can live with that. Anyone can read our discussion and make up their
mind on their own (and hopefully share it with us).

[1] Unless of course---and I wrote that before---we extend the name of
the new functionality to be more precise:

- Attribute Grammar (what the current proposal effectively is)
- Meta-Attributes
- Custom Attributes
- Annotation Attributes
- Aspects [2]
- ...

[2] https://en.wiktionary.org/wiki/aspect
In aspect-oriented programming, a feature or component that can be
applied to parts of a program independent of any inheritance
Richard "Fleshgrinder" Fussenegger

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 3 | next ›
Discussion Overview
groupphp-internals @
postedApr 30, '16 at 9:53p
activeMay 1, '16 at 11:19a



site design / logo © 2019 Grokbase