On 4/28/2016 9:43 PM, Rowan Collins wrote: > I meant specifically in the context of C#/.net. You claimed a very > specific usage within that framework, but all the articles I can find > refer to them consistently as "attributes" in that context. Event the > Wikipedia article: > >> In the C# programming language, attributes are [...] equivalent to > annotations in Java. > > That's pretty clear to me that the two languages call the same concept > different things. >
Erm, actually I did not claim anything and applied proper terminology to the C# syntax. However, if it is so important for you to stick with C# and .NET then let's do this. I previously claimed that Microsoft does a perfect job. That claim was based on the fact that the feature is called "Data Annotations" and that one can apply and create custom "Attributes" (Metadata). [1] I still stand to that claim because this is exactly how the computer science terminology defines these terms. > We can easily add validation to our application by adding Data > Annotations to our model classes. Data Annotations allow us to > describe the rules we want applied to our model properties, [...] > > --- http://www.asp.net/mvc/overview/older-versions/mvc-music-store/mvc-music-store-part-6 > When you use the Data Annotations Model Binder, you use validator > attributes to perform validation. > > --- http://www.asp.net/mvc/overview/older-versions-1/models-data/validation-with-the-data-annotation-validators-cs > --- https://www.youtube.com/watch?v=Dllb1cDDsL0 That being said, others are not so nice to Microsoft and directly call the usage of the term "Attributes" in this context a MINFU because they should call it "Annotations". [2] We already know from various sources (see initial message) that attributes are more generally just metadata. Hence, I do not agree that the usage of the term "Attribute" in the context Microsoft uses it is a MINFU. One simply should not look at the term outside of the extension/library/namespace "Data Annotations" and everything is fine. The fact that .NET documentation is most of the time only talking about "Attributes" is because the documentation explains those classes and their usage. I do not understand why this means for you that the whole feature is called attributes. On 4/28/2016 9:43 PM, Rowan Collins wrote: >> The word construct "attribute specification" is completely right, it >> specifies which attribute should be applied to the data. > > But it completely disagrees with your earlier claim that "The result of > an annotation is an attribute." There is absolutely no usage of > "annotation" in that page; there is just a description of syntax for > applying "attributes". > You need to keep in mind that they are talking about "Data Annotation Attributes" in all of the documentation. On 4/28/2016 9:43 PM, Rowan Collins wrote: > It may make sense, but can you point me to any C#/.net documentation > which describes that relationship? I'm talking about actual usage here, > not theoretical definitions. > 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. On 4/28/2016 9:43 PM, Rowan Collins wrote: >> As I said in the initial message, using the term /attribute/ is pretty >> much never wrong because the term /attribute/ is so generic. :P > > What kind of answer is that? The page clearly describes a Perl feature > very similar to the feature proposed for PHP, and it very clearly calls > it "attributes". If it's "never wrong" for Perl, surely it's "never > wrong" for PHP either? > Notice the :P at the end of the sentence. Usage of the term /attribute/ standalone is pretty much never wrong but always endlessly ambiguous and that is exactly the problem! On 4/28/2016 9:43 PM, Rowan Collins wrote: > I have already pointed out that 3 of those links do not back up your > claim. You appear to dispute this, but I'm increasingly unclear on what > grounds. > > You are perfectly entitled to the opinion that C#, Perl, and Rust are > *wrong* in their usage of the term, but they absolutely use that term in > the same way as Hack, not in the way you wish to define it. > I already went into more detail regarding C#/.NET at the beginning. 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 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. > Extra information associated with a particular point in a document or > program. Annotations may be added either by a compiler or by the > programmer. They are not usually essential to the correct function of > the program but give hints to improve performance. > > --- http://encyclopedia2.thefreedictionary.com/annotation On 4/28/2016 9:43 PM, Rowan Collins wrote: > OK, I'm completely lost now. I thought your argument was that the > feature should under no circumstances be called "attributes", because > that is too general a term, and that it should instead be called > "annotations", because that is the only correct term. Then you link to a > page which demonstrates *annotations* being used as a general term, and > *attributes* being used for the feature being proposed. > C#/.NET calls them "Data Annotation Attributes" and not "Attributes" (see above). Perl does but I am still not sure if it is wrong or right in their context and included an /if/ in my initial review of their usage of the word. In case of doubt it's wrong I guess. Hack definitely uses it wrong. Also note that the current Attributes proposal is in some way closer to "Attribute Grammar" [3] than to annotations. I just hope that we can make an annotation system out of it and not end up with an attribute grammar system (or would we have to call it /attribution/ system then). On 4/28/2016 9:43 PM, Rowan Collins wrote: > Except that the Rust example demonstrates that "annotation" can be used > just as generically and ambiguously as "attribute". There really is very > little to choose between the two terms. > > Declarations can be annotated with ‘attributes’ in Rust. > > --- https://doc.rust-lang.org/book/attributes.html That is exactly the definition I gave in the initial message. There is no annotation system in Rust: > Currently, you are not allowed to create your own attributes, the > Rust compiler defines them. > > --- https://doc.rust-lang.org/book/attributes.html I am repeating myself but: @deprecated function f() {} We annotated (`@`) the function /f/ with the `deprecated` attribute, hence, _deprecated_ is now an attribute of function /f/ because we annotated it. > Allows use of the #[start] attribute, which changes the entry point > into a Rust program. This capability, especially the signature for > the annotated function, is subject to change. > > --- https://doc.rust-lang.org/reference.html The past and current RFCs are not proposing any attributes, they are proposing a system to annotate data with custom attributes. [1] http://dataannotationsextensions.org/ [2] https://www.it-visions.de/glossar/alle/454/MetaAttribut.aspx (German) [3] https://en.wikipedia.org/wiki/Attribute_grammar -- Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
