FAQ

On 30/04/2016 12:09, Fleshgrinder wrote:
Erm, actually I did not claim anything [...] I previously claimed that Microsoft does a perfect job.
Just thought I'd point out this contradiction.

That claim was based on the fact that the feature is called "Data Annotations" and that
one can apply and create custom "Attributes" (Metadata).
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."

[1] https://msdn.microsoft.com/en-us/library/system.attribute.aspx
[2] https://msdn.microsoft.com/en-us/library/2baksw0z.aspx


One simply should not look at the term outside of the
extension/library/namespace "Data Annotations" and everything is fine.
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?


The fact that .NET documentation is most of the time only talking about
"Attributes" is because the documentation explains those classes and
their usage.
Which classes?

I do not understand why this means for you that the whole
feature is called attributes.
Because the documentation talking about the feature calls it that.
Repeatedly.

"The common language runtime allows you to add keyword-like descriptive
declarations, called attributes..."
https://msdn.microsoft.com/en-us/library/5x6cd29c.aspx

"Apply the attribute to the code element by placing it immediately
before the element."
https://msdn.microsoft.com/en-us/library/bfz783fz.aspx

"Attributes provide a powerful method of associating metadata, or
declarative information, with code..."
https://msdn.microsoft.com/en-us/library/z0w1kczw.aspx


Helpfully, Microsoft make the C# Language Specification readily
available, so I downloaded that
[https://www.microsoft.com/en-us/download/details.aspx?id=7029]

The word "annotation" is used in only one context: "variance
annotations", which are the "in" and "out" keywords that allow a Generic
type parameter to be co- or contra-variant, and nothing to do with the
feature we are discussing. The word "annotate" is also used in reference
to documentation comments, and in the following sentence:
When an optional parameter is annotated with one of the caller info
attributes, omitting the corresponding argument in a call does not
necessarily cause the default parameter value to be substituted.

As far as I can see, it's not being used as a specific term in that
sentence, and you could safely substitute "is marked with".

"Attribute" meanwhile appears 19 times *in the Table of Contents*, all
describing the feature we are discussing - the ability to add some
syntax next to some code to apply metadata retrievable by reflection.
The Appendix contains a set of grammar constructions for the grammar of
the "[ Foo (Bar) ]" syntax used to apply attributes; the grammar rules
all use the word "attribute", never "annotation".

I am sorry but this is about theoretical definition and not about some
company chose to call it. Actually I am arguing against blindly
following these companies (Facebook and/or Microsoft) and complying with
the theoretical definitions.
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.

As I wrote in the initial message regarding Perl. If the linked feature
is *the only way* to add attributes than naming it attributes
(standalone) is fine. However, if there are other means than same logic
applies.
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"?

I really do not understand why the usage of the term annotation is wrong
in the Rust example. It is a hint for the compiler that can be added by
the programmer or the compiler. That's pretty much a perfect usage
according to the definition of an annotation.
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.

The past and current RFCs are not proposing any attributes, they are
proposing a system to annotate data with custom attributes.
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.

Regards,

--
Rowan Collins
[IMSoP]

Search Discussions

  • Fleshgrinder at May 1, 2016 at 10:19 am

    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
    run-time.

    --- 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
    decorated.

    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
    hierarchy.
    --
    Richard "Fleshgrinder" Fussenegger
  • Lester Caine at May 1, 2016 at 11:19 am

    On 01/05/16 11:19, Fleshgrinder wrote:
    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).
    My own 'working process' has always looked at annotation as the block of
    tags being added to an object. Then calling some elements of the
    annotation 'attributes' just dovetails in, just as other annotation may
    highlight access control or authorship. I've never though as the whole
    lot as individual attributes.
    [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]
    - ...
    Which simply highlights a working practice we have been following since
    docBloc annotation started?

    What *IS* now making a lot more sense to me is the way things that I've
    followed the practices inherited from the original PHP4 code have been
    morphed into things like 'reflections'. I still don't see the entire
    need for this layer of complexity, and the Drupal comment that they
    don't use them makes sense since their code base pre-dates the need and
    uses 'more traditional' methods to provide the same results? If you have
    never had the need for reflections adding their use is a strain.

    If a variable is public, but should only be accessible via other
    functions such as getter and setter then the underlying value variable
    needs to be private? So if all the values are private and wrapped in
    code, then any value can be extended to also provide additional metadata?

    --
    Lester Caine - G8HFL
    -----------------------------
    Contact - http://lsces.co.uk/wiki/?page=contact
    L.S.Caine Electronic Services - http://lsces.co.uk
    EnquirySolve - http://enquirysolve.com/
    Model Engineers Digital Workshop - http://medw.co.uk
    Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedApr 30, '16 at 9:53p
activeMay 1, '16 at 11:19a
posts3
users3
websitephp.net

People

Translate

site design / logo © 2018 Grokbase