Taking off my RM hat here. So my comments are those as joe smoe user,
who hasnt written namespaced code, but who has been reading all the
criticism people have posted (interestingly I have seen very few
people that are entirely happy .. of course people complain louder
than they praise .. still ..).
On 09.09.2008, at 01:41, Stanislav Malyshev wrote:
And I'd ask - who wants to do new DB::mysql when they can just do
mysql?
I do. Because this way I don't have to worry my mysql would clash
with someone other's mysql, and I can have all DB related stuff
under one roof.
I disagree. The idea is that I get control over how I manage to global
namespace. As such its sensible that I want to use "mysql" in my code
instead of DB::mysql.
The common usage of use is going to be to get the name as short as
possible, and NOT have to type out db:: everywhere. Do you have code
There never was a task to make use of as little characters as
possible. If you think that was the point, you are mistaken. There
were a task to make it manageable, but not at the cost of clarity
and robustness and performance.
Its not only about having to type more. Actually the need to reduce
characters is not at all driven by the effort it takes to type (cause
that is handled by tab completion), but more by how many characters I
have to read, how quickly the lines grow beyond 80 chars (80-100 chars
is generally accepted as the maximum amount of chars that a developer
can grasp quickly at a glance).
Also when it comes to resolution, inclusion order should not matter,
period. if it does we have a serious flaw in our design. if we cannot
make a performant solution in this case, we better have nothing. that
being said, i feel like there are ways to make a good performing
solution where the inclusion order does not matter for resolution.
Then let me rephrase "Useless to me" - as they are functions in
OK, I am sorry that they are useless to you. I hope you have better
luck with next feature. However, you can not realistically expect
features in PHP be based on your personal taste only, can you?
The thing is its not just Elizabeth. Its essentially all people who
have replied to my request for feedback. Granted its a small group,
but contrary to many of us they have all used the namespace
implementation in PHP 5.3 _more_ extensively than probably all core
developers. So even if some core developers have extensive experience
with namespaces in Java and packages in other languages, these people
have done more with this construct in PHP than many of us have. Also
while I do not know all of the people that replied personally, I know
a fair share of them and that they are solid developers. So I think
you are brushing their expectations off too lightly here.
You seem to be under the impression that the people writing templates
are as skilled in PHP as the people writing the code using the
templates
(or are the same people) - sadly that's very often not the case.
OK, suppose it is not. How not knowing what strlen actually does
helps you in this case? I'd say more clear the function is - both
name and what it is intended to do - less chance someone would screw
up. If you have unicode::strlen and just strlen, chances that
somebody would do unicode::strlen($binary_data) or
strlen($unicode_name) drop significantly.
I am not a friend of smarty, but for one most template engines work
very hard to keep the number of chars to a minimum in order to not
"pollute" their markup with too much PHP code (just think of the <?=
camp or _()/__() used for translation in many frameworks). Also even
lightweight template engines are known to do a lot of automatic magic
(like escaping) to again keep the PHP code to a minimum and to prevent
template developers from having to think. These are facts that I find
hard to dispute. Other uses cases mentioned was working around bugs, I
would like to add unit testing (like being able to do my unit test
friendly time()).
That being said, this is dangerous territory.
The fact that people expect that they can call a function from a
namespace in a way that looks different from a static method call
however is imho clearly something that needs to be addressed. One way
that has been asked for is to atleast be able to import the namespaced
function into the global namespace. Allowing to overload internal
functions with this is another question, which again I think needs
careful consideration, but does have its uses (see above).
The bottom line is ... I've given you reasons that I would want to
alias
functions...and you seem to be doing nothing more than saying "don't
design it that way" - which quite frankly seems silly. If there's a
Well, it doesn't seem silly to me. There are right ways to use
namespaces and wrong ways. You insist on using them wrong way and
want to make it easier to use them wrong way. I think it is a bad
thing to make it easier to use things in wrong way.
I am not convinced that you have demonstrated the mentioned used cases
are really so clearly "the wrong way" that they should not be supported.
good technical reason why you think function_alias wouldn't work
other
I could live with having function function_alias() - though I think
you are dangerously close to runkit() territory. But having function
is one, having it in language syntax is another - that is
practically endorsement. And I don't want to endorse aliasing
functions, especially when primary reason seems to be not having :
character in names and saving a couple of keystrokes. It is fine to
have tastes, it's just IMHO not enough for putting it into the
language syntax.
I think that PHP is not an OO language and as such there is no reason
to limit new constructs and syntax options to OO code only, just
because the idea for the construct/syntax originates from some OO
language.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
