Hi! > <<MyAnnotation(foo = 'a', bar = 'b')>>
Here you have essentially created a named parameter syntax. That may be a problem later, especially if we do implement named parameters and this won't be the syntax we choose. > $def instanceof MyAnnotation; //TRUE That looks fine, however the problem is that if MyAnnotation is a class, then PHP does not have multiple inheritance, so it's the only class it can be. And given that your class has no methods, $def has no methods either and can not have any semantics besides simple data object. Which begs the questions: a) why it needs to be a class/object at all and b) how would you support all those fancy AST things if you can't even call methods on it. Of course, this is solvable by various way, but looks a bit clunky conceptually. You expect classes to work in a certain way and attributes to work in a slightly different way, at least with current proposal. > MyAnnotation can then have whatever other methods I feel like to > access/mutate those values. If that requires limiting MyAnnotation in Mutable annotation is a very bad idea. That's BTW another problem of defining it as class - we don't have real means to express immutable value classes yet, not without some boilerplate. That's why interface is better - it allows you to do immutability cleanly. > That's essentially the same concept as I described above with the > class. Putting annotations on the object being created seems like a Very similar, expect for: 1. Interface allows you to have richer semantics since you can implement other interfaces and have other classes. Class pretty much limits you to value object unless you do dirty tricks which essentially turn it into interface. trait may be a bit in-between solution, but I didn't really think about it yet, so there may be problems there. 2. You have no mutability issues. 3. You don't confuse template with actual data - i.e., with class, if I just instantiate it, would it be a valid attribute? Of what? 4. You still can make complex attributes return ASTs. > reasonable way to handle nested annotations at first glance, although it > still doesn't resolve the main issue of Translatable which is that we > scan the source code statically to find translatable strings. (We look That can be solved by making translatability a property of an attribute, not a string. That looks to me a better design anyway - if you have a button, what would it mean if its label sometimes translatable and sometimes not? I'd expect translatability to be requirement of a context - i.e. if we use string to display a button, it's translatable. Note that it doesn't mean it *has* translations for every language - you can't ensure that anyway - but it has the *option*. And if you make it a property of the attribute itself, then your tool can have the list of translatable attributes and then extract the values for these attributes for translation. That also makes more sense to me for translation - to translate properly, you need to know the context of the string, same text can translate differently depending on the context, so you'd want to know what value you're translating. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
