On 4/24/2016 1:58 PM, Benjamin Eberlei wrote: > The article *you* reference about attributes lists C# attributes as the > *first* example. > > And defines an attribute as: > > "For clarity, attributes should more correctly be considered metadata > <https://en.wikipedia.org/wiki/Metadata>. An attribute is frequently and > generally a property of a property." > > HHVM uses the name attribute, for the same syntax that Dimitry proposes > here. > > *MUST* is such a strong word in this context, this is not an 0 XOR 1 issue. >
On 4/24/2016 2:07 PM, Zeev Suraski wrote: > Thanks for the programming 101 lesson :) > > I pointed out to Sebastian, who suggested that 'attributes' are equivalent to 'member variables' or 'properties', that they're very consistently referred to in PHP as 'properties' and that I'm not aware that they were ever referred to as 'attributes'. > > Nothing in your links suggested otherwise, arguably the opposite. According to https://en.wikipedia.org/wiki/Attribute_(computing), "An attribute is frequently and generally a property of a property", and while "the term attribute can and is often treated as equivalent to a property depending on the technology being discussed", when the technology in question is PHP, this is not the case. > > Of course, member visibility modifiers and access modifiers (public/protected/private, static, etc.) are a different thing. Saying member variables are referred to as attributes (incorrect in the context of PHP, AFAIK) is very different from saying these modifiers are referred to as attributes (correct and sensible). > > Last, we're absolutely allowed to have our own definitions of terms as long as they're sensible. Both attributes and annotations are sensible here, and the fact there may be languages that treat attributes as equivalent to properties isn't a strong reason against using that term for something sensible, that is different from these other languages, in PHP. > > Zeev > As I said, unless somebody knows an even better term. It also depends on which source code is going to be allowed to have this kind of additional metadata. If we limit it to functions, classes, properties, and methods: /all good./ Why? We might want to allow adding of metadata to other parts of the source code in the future. I already asked regarding annotating files themselves (as is possible with PhpDoc's file-level docblock) and then it becomes complicated. I am not saying we need this, I am saying we need to clarify this. Using the term attribute without defining what the term means is problematic. I know, Facebook/HHVM/Hack but we are not required to be compliant with them and they are not our benchmark. Using the term annotation is not so problematic because it has a clear definition (not only in computer science) and it does not say anything about the applicability of what it does, it only states the functionality of the feature itself: /adding metadata to data/. You want to avoid writing extensive definitions of terms that are going to be used since people then need to learn these terms. Just think about the normal usage of the word attribute in language, e.g. describe the attributes of this image. The answer could be "it shows a woman with long hair and blue eyes". Hence, /long hair/ and /glue eyes/ are attributes of the woman. However, asking for the annotations of this image would result in a different answer, the asked person, assuming she knows what the word in general means, turns the image and would tell us the date and time it was taken or printed, or maybe the ISO level, ... whatever. Is *public* an attribute of the property? /Yes/ Is *static* an attribute of the method? /Yes/ Is *name* an attribute of a person? /Yes/ Is *__toString* an attribute of the class? /Yes, behavioral/ Is *inattentive* an attribute of the child? /Yes/ ... So, what should `$r->getAttributes()` return? It is to broad, it is to generic, it is too often mixed up. `$r->getAnnotations()` is less ambiguous in the context of programming and thus a better choice. I hope you can follow my /Gedankenspiel/ (mind game) better now. :) -- Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
