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
signature.asc
Description: OpenPGP digital signature
