Hi!
> I'd love if Stas, Derick, Rasmus or Zeev comment here on criteria about
> acceptance of new features.
I can answer only for myself of course, but I don't have any single
"criteria". I look at the feature, how it can be used, how it can be
abused, how it would be seen by experienced PHP developer, how it can be
seen by novice PHP developer, how easy is to understand what's going on,
how much impact it would make on performance and robustness of the
language, how easy or hard would be for tools to support it, etc. etc. -
and then discuss with authors and decide if I'd like to have such thing
or not.
> I wonder how Annotations is different from Traits or Aspects.
I'm not sure what you mean by Aspects, but traits are different from
what was proposed as annotations because they are much simpler both
conceptually (you just put a couple of methods from one class to
another, same thing you do with inheritance but without full-blown OO
"is-a" contract) and syntactically. If annotations were at the same
level, I'd not have much problem with them, not at all. However, what is
proposed is more akin to sub-language, with its own syntax, complex
expressions, nested object instantiations and all this has to happen in
some weird space which is both code and not code. And of course it
should also have syntax that is both different from any other language
that does the same, looks like completely different syntax in at least
two other popular programming languages and two popular markup
languages, and is chosen by principle of "which symbol didn't we use
yet?". This seems to me a wrong way to do it. Not because I'm opposed to
the idea in principle, but because I'm opposed to how it is done.
> Or will you guys claim that Traits will be vastly used?
I have no idea. We will see. How can I know what a million of people
will be doing?
> Also talking about widely used support, I wonder about how
> SplDoubleLinkedList, SplInt, SplMaxHeap and all these classes that have
> very specific usages, just like also data structure readers like
> json_decode, parse_ini_file are part of the core while others also used as
> much as these ones like yaml_file are out.
I'm not sure what you're getting at here. If you think we need to add
YAML extension to core packages, please write an RFC, explain why is
this extension good enough and required, have a vote and we'll see. I'm
not sure why you're bringing it in this topic.
> You guys may now know, but 9 out of 10 most used frameworks are entirely
> OO. It's a shame that because Yahoo code is procedural (worked at Yahoo
> already), SugarCRM code has terrible OO decisions (I've seen its code),
> adopting exceptions handling !!!in July 2012!!! that makes you guys say
> there's no need to improve on OO features that community is claiming.
And I can't even begin to understand what you are talking about here.
Nobody ever said there's no need to improve on OO features, and how
SugarCRM code has anything to do with anything it's just beyond my
comprehension. That doesn't mean we need to get anything any OO language
has into PHP. Some of it is good for PHP, some of it would be better
done differently.
> 10 times. Isn't it a sign of a feature demand?
I know that some folks want to have syntax like this:
@MyApp\Acl({
"allow"=@MyApp\Acl\Allow({"john"="read", "joe"="write"}),
"deny"=@OtherApp\Acl\Deny(default="*", log=true)
})
and even more complex to be part of PHP function and property
definitions. I think it is misguided on multiple levels. That does not
mean some metadata support won't be useful - it probably would be. But
not this way.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
