Hi!
> Anyway, all of us know that main source of complaints about PHP is lack
> of consistency. Inconsistent APIs across modules are acceptable. It's
> modules after all. However, basic language constructs like [] and {} are
> better to have predictable/consistent behaviors. i.e. how it works, raised
> errors.
They do have predictable behavior. Again, "consistent" here does not
have any defined meaning as far as I can see, given how many people use
it to mean so many different things. It became sort of a shortcut -
instead of explaining why the change is good, you just say "for
consistency" and expect everybody to nod and agree. I don't think it works.
> This RFC improves inconsistent behaviors a lot. Why not to add
> $str{} = 'string'? It's not complex nor BC as it raises syntax error
> currently.
Because it is not needed and it is an unnecessary weird syntax for the
operation we already have a syntax for - string concatenation. Moreover,
it borrows syntax from another operation - string offset - while doing
totally different thing ($a{1} = 'foo' would only use one character -
'f', but $a{} = 'foo' would use the whole string, right?). Moreover,
while there is a practical need in string offsets (though I would say
making them writable is a bit questionable) there is no need to invent
syntax for concatenation, we already have it.
> It does not worth the effort having other RFCs for
> - $str{} = 'string'
Correct, because nobody needs it and it is a bad idea.
> I agree small changes are easier to review, but it may leave lots of
> obvious inconsistency in PHP. We have too many of them already.
If you have examples of "obvious inconsistency", name them and we will
discuss it. {} is not such example.
> Making RFC and pass the vote is not easy task. Authors may not have
> time for RFCs for clean ups.
Understandable, not everyone has time to contribute to PHP. Those who
have the time, do, and we are grateful to them. However, if somebody
doesn't have the time, that is not the reason to lower our standards.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
