Tonight I started trying to write a proposal for even more simplified annotations, e.g. something simple enough that it cannot result in fatal errors. I eventually gave up, and here's why.
Essentially, if you have to restrict yourself to things that cannot under any circumstances error out, the only things you can use are constant scalar values - even constant scalar expressions could not be allowed, because even those could error when CONST_NAME or Class::CONST_NAME aren't defined. So, in a nutshell, what you're saying (Richard) is that annotations can only consist of scalar values, and possibly arrays of values? (and I don't even see your gist doing that - it's just invoking closures, as far as I can tell, and any of those could error, or not?) So, regardless of syntax, literally the only annotation data allowed would be blatantly simple things like: ["max_length" => 20] ["data_type" => "int"] Or in other words, constant arrays, int, string, float and bool values. Nothing else. Nothing can depend on any kind of external symbol (class names, constants, etc.) since any such reference can cause an error. No static analysis or type-checking of any kind can ever be performed - no assertions or declarations can be made about the shape or types of metadata, at all. The problem is, that's simply not useful. It's also not very different from what we have today with php-doc blocks - the only real difference is we can check array nesting and int, string, float and bool syntax, e.g. nothing really useful or important. In other words, this would be a very slight improvement on syntax - nothing that actually amounts to any kind of functionality. If we were to ship a feature like that, what would happen is precisely the same thing that happened with php-doc blocks: the real work will be done in userland (and likely dominated by one library), there will be no IDE support (except proprietary support for that one dominating library), no useful offline static analysis tools. At the end of the day, what we end up with will have all of the same issues we have with php-doc blocks and existing libraries. I don't understand how such a feature would be useful to anybody? I especially don't understand why you want a language feature that isn't allowed to reference external symbols - e.g. isn't allowed to have any kind of relationship with anything declared in userland. It seems to me a peculiar, arbitrary and unrealistic restriction to put on annotations. It's going to have no immediate usefulness, and mapping the data to objects is going to happen in userland, just as it does today. I'd like to work on this proposal, but I feel that you're giving me nothing to work with here. On Mon, May 16, 2016 at 12:38 PM, Fleshgrinder <p...@fleshgrinder.com> wrote: > On 5/13/2016 2:11 PM, Rasmus Schultz wrote: >> Dear Internals, >> >> I'm announcing a simplified RFC for annotations: >> >> https://wiki.php.net/rfc/simple-annotations >> > > -1 again, I am sorry. > > The problem is that an annotation by definition is just meta-data. Your > proposal however might result in fatal errors from meta-data: > > $reflector = new ReflectionClass(User::class); > $reflector->getAnnotations(); > > // Fatal error: Uncaught Error: Class 'TableName' not found ... > > This is an absolute No-Go for meta-data. > > -- > Richard "Fleshgrinder" Fussenegger > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php