Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40419
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 88.198.8.16 cause and error)
Cc: Elizabeth M Smith <auroraeosrose@shitennou.com>,
 'PHP Internals' <internals@lists.php.net>
Message-ID: <ED431DB9-F6DF-4374-B81F-9384CF63CFAF@pooteeweet.org>
To: Stanislav Malyshev <stas@zend.com>
In-Reply-To: <48C5B81F.4000504@zend.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v928.1)
Date: Tue, 9 Sep 2008 23:16:11 +0200
References: <ADD0525F-F900-4F3A-9B76-1ED332CA31E0@pooteeweet.org> <486FA5FB.1000300@php.net> <E06A1FB3-971F-4D4F-850A-D0255F7275F7@pooteeweet.org> <48C55855.4080602@zend.com> <A077B6EC-3E30-4F46-91CA-FD75D578CC7A@pooteeweet.org> <48C5624A.1040901@zend.com> <F4.39.33249.21565C84@pb1.pair.com> <48C56743.2060706@zend.com> <48C56821.2040805@shitennou.com> <48C5695E.1010404@zend.com> <48C56A51.1000307@shitennou.com> <48C56CEE.6050807@zend.com> <48C56DED.4010407@shitennou.com> <48C57045.6020003@zend.com> <48C5715C.2070102@shitennou.com> <48C574E8.1030504@zend.com> <48C57761.5030708@shitennou.com> <48C57F58.3060703@zend.com> <48C59A7D.50201@shitennou.com> <48C5A0B9.2040300@zend.com> <48C5A90E.6060902@shitennou.com> <48C5ABC4.1010008@zend.com> <48C5B010.8040301@shitennou.com> <48C5B81F.4000504@zend.com>
Subject: Re: [PHP-DEV] Re: towards a 5.3 release
From: mls@pooteeweet.org (Lukas Kahwe Smith)

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
mls@pooteeweet.org