>> > >> > Obviously, the `\0` is horrible and can probably be improved: depends on >> > whether the API is intended for human or machine consumption. If it is >> > machine consumption, strings are the wrong approach anyway. >> >> Machine or human? >> One goal is that these names can be used as array keys or unique >> identifiers whenever we deal with a collection of reflectors of mixed >> type. >> At the same time, the name is designed to be very close to what is >> printed in exception messages, @see doc comment, etc. >> In this case, I don't see a conflict between human-readable and >> machine-readable. >> >> Maybe when you say "machine consumption" you are thinking of something >> else? > > > Machine consumption would be VOs, not strings ;-)
One purpose of such names would be that they can be saved in a file or database, and read in another process. If you want a value object, then why not use the reflector object directly? Ok, because "side effects" - I agree. If we want a value object, it should be named like "ReflectorHandle", and then "ClassHandle", "FunctionHandle" etc. These would provide the name of a class, but not any information about it. But this should be in a separate method, e.g. ReflectionClass->getHandle(), and it would be a separate feature for a separate thread. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
