Re: [PHP] Sayonara PHP
2007/12/26, Andrés Robinet [EMAIL PROTECTED]: Well, my fellow countryman... one of my classmates at college had a saying: el hombre es un animal de costumbres (translate it you gringos :) - no offense). And I guess it's most of the time like that... we learn something, we are never willing to unlearn it. But the truth is, there are at least as many habits and learnt behaviors as people are there walking in the streets. So, sometimes, we should be a bit more tolerant to foreign habits (unless we are Micro$oft.. but even so...). If my intuition is right you must come from the Java/C++ world (my bet is java 80/20). Maybe you have evaluated the hassles of implementing namespaces into PHP... and you have concluded it's not possible. Or maybe, that it will be a buggy implementation in the end; like PHP 4 OOP (which doesn't look like OOP at all). Maybe some old-seasoned gurus in the internals community have set you apart, or have treated your opinions with contempt (this is just my assumption, like most of this email's contents). So, you are now assuming that you won't need PHP, and that it will 'die(alone)' like some poem of your authorship stated in one of its verses. Yes, after all developers find out the hassles of namespaces and type hinting in PHP, they will give up... won't they? (just reading your mind... forgive my arrogance and continue). Well, it's been years since I've done anything important in Java or C++. I've been doing mostly scripting languages in all sorts of flavors. I don't really care that my opinion felt to /dev/null or something else, I just kept trying, and when I understood that I had to get my hands really dirty to be taken into consideration, that's what I did. The short time I had been dwelling through php source code, I finally understood why the core developers have such a short temper. To be fair with the core developers, the php community should issue a thank you for keeping php running email each week. The poem! That was fun! =D It's not an assumption that I won't need PHP, it's just that I wanna try doing something that's far away from web development and php. It would have been a waste to leave everything I wrote in the first mail in the garbage bin. That's why I wrote it, so if there's someone who sees that something is sensible or useful in there, he can just take it. That was my only intention. I don't expect developers to just give up. I expect them to (a) accept them and continue doing as always (b) ignore them (c) complain (d) use them wrongly. I'll go for (d) if you wanna bet. You know... I think I'm about your age (judging for the picture of yours at phpclasses.org, if that's your picture). Maybe a bit younger, or a bit older... but just a bit. And the thing is, I heard about two years ago or so, a big buzz around a PHP replacement. It was something about trains (that's the farthest understanding I reached on it... something about trains). I think it was called, railroad, or railway, or diamond on a train... ... nope, now I remember, it's ruby on rails (if you have a sarcasm detector, use it now). Last time I checked, it was still alive... arguably in a much more evolved fashion, and some (may I say few?) hosting companies support it now. I don't know much about current statistics, but I'm tempted to say that: - There are many more Books on PHP than on RoR - There are many more PHP hosting offers than RoR's counterpart (even if we reduce the stats to PHP 5 - just a guess) - There are many many more websites built on top of PHP than the RoR's counterpart - There are many many more extensions, APIs and Frameworks for PHP than for RoR (actually, RoR IS a framework itself) - There are many many more PHP developers than RoR developers In the shared market niche, PHP has beaten java, coldfusion, asp, and perl, which already existed. PHP has survived .Net rumbling, despite the Vb, C#, J# or C++ flavors and the awesome Vi$ual $tudio IDE. And despite all the predictions and prophecies about PHP's doom... it is still here, and will be here and in the top 5 for at least 10 years. By the time PHP is replaced by RoR or anything else, I will probably be selling RoR T-Shirts, or be retired, or be dead (maybe of lung cancer, or cirrhosis, or just because no-one can live past 120's)... Please, don't let me get started on the Freaks on Rails. RoR is a stillborn baby. It wasn't just bad enough that the RoR developer failed while doing the first video presentation of RoR. People still kept boarding that train. And it become worst, people from PHP started to think that RoR was actually a good idea to be copied. There are two major faults with RoR: 1) The MVC design pattern is not applied correctly 2) The whole application is designed around the (faulty) MVC design pattern The MVC design pattern has one purpose and one purpose only, user interface implementation. RoR forces you to put code that's not pertinent to
RE: [PHP] Sayonara PHP
and MySQL 3.23 (there are still some of those archaic hosting
packages over there
I dont need to tell you). So, I just had to get used
to this new OOP of PHP 4 (which is almost no OOP at all).
All in all, my fellow countryman, I guess that unless you have a huge
positive bank account balance, and you drive a BMW (I dont like them
anyway
) youd better off tolerating PHP for this little namespace issue
if you want to stay in business. Unless, of course, that you have an
incoming contract to develop a core system for an NSA mainframe. And if
thats the case please tell them I prepare the most awesome mate
(http://en.wikipedia.org/wiki/Mate_(beverage)) in the world, and that you
cannot work without it.
I know that, even if you wish to leave PHP forever, youll come back
all
the roads will lead you to it. So, youd better take a smart decision now
than have no other choice in the future (... ok, that was kind of The
Godfathers script, lol).
Enjoy your holidays,
Rob
Andrés Robinet | Lead Developer | BESTPLACE CORPORATION
5100 Bayview Drive 206, Royal Lauderdale Landings, Fort Lauderdale, FL 33308
| TEL 954-607-4207 | FAX 954-337-2695
Email: [EMAIL PROTECTED] | MSN Chat: [EMAIL PROTECTED] | SKYPE:
bestplace | Web: http://www.bestplace.biz | Web: http://www.seo-diy.com
From: Martin Alterisio [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 26, 2007 2:04 AM
To: PHP Developers Mailing List; PHP General
Subject: [PHP] Sayonara PHP
Please let me do a little explanation of the title first. Japanese is
an
interesting language where context is vital to the meaning of a word.
Sayonara usually means a simple good bye, but within a different
context
can mean we'll probably never meet again.
To understand this mail you'll have to know that I was just another
user of
PHP, an user that was probably too eager. I wanted to get more involved
with
the development of PHP as I do believe in all the philosophy of open-
source.
In the end I found my attempts ended in frustration, but, nevertheless,
I
learned a lot in just a few months. I don't want this mail to be one
where I
get to display all my frustration, instead I want to leave here all my
findings, the things I researched, the few things I managed to actually
code, and mostly the ideas that someone else might find useful.
To those who may want to involve in the php internals
For those in the generals list that may ever try to venture in the
internals
of PHP, remember that you have to back your point of view with a patch.
So,
sit down, remember the old days in college using the c compiler, and
code
like a cowboy before trying to promote anything in the internals. It's
the
status quo of the PHP development community, as I did learn too late.
Namespaces: function imports
Here is the patch to add function imports to 5.3. To be consistent
constants
imports have to be added too:
http://martinalterisio.com.ar/php5.3/use.function.v2b.patch
If you don't know what imports are, they are just a way to refer to a
longer
name with a shorter name. For example:
?php
class MyRowset extends Zend::Db::Table::Rowset::Abstract {
...
or with imports:
?php
use Zend::Db::Table::Rowset::Abstract as Rowset;
class MyRowset extends Rowset {
...
The use statement behavior currently supports only class names
aliasing.
Functions and constants have to referred with full name, although these
too
can be namespaced.
Import statement is broken, why, how can be fixed
While doing the previous patch I realized that the use statement is
broken.
It should generate and error when you try to override an existing name.
But
the use statement is handled at compile, where it's unknown if a name
will
be overridden or not. What happens is that the error might be triggered
depending on the conditions and order of compilation. If you have an
opcode
cache, this error may not appear until the cache is invalidated.
On a suggestion by Dmitry, which I really don't know if he knew about
this
issue with use or not, but, anyway, his idea solved this issue, I made
this
patch:
http://martinalterisio.com.ar/php5.3/file.scope.use.patch
With this the use statement is checked only against the names used in
the
current file (or namespace if using multiple namespaces per file).
Since the
imports only affect the current file, this is more sensible, and the
issue
mentioned before disappears.
Name clash and ambiguity issue introduced by namespaces
There's another pending issue with namespaces, there's a name clash
that
currently goes undetected, and makes static methods partially
unavailable.
This is due to the fact that using :: as namespace separator generates
ambiguity. foo::bar() can refer to the static method bar in class foo,
or to
the function bar in the namespace foo. This is an issue to php library
developers. Someone can inject a namespaced function
[PHP] Sayonara PHP
Please let me do a little explanation of the title first. Japanese is an
interesting language where context is vital to the meaning of a word.
Sayonara usually means a simple good bye, but within a different context
can mean we'll probably never meet again.
To understand this mail you'll have to know that I was just another user of
PHP, an user that was probably too eager. I wanted to get more involved with
the development of PHP as I do believe in all the philosophy of open-source.
In the end I found my attempts ended in frustration, but, nevertheless, I
learned a lot in just a few months. I don't want this mail to be one where I
get to display all my frustration, instead I want to leave here all my
findings, the things I researched, the few things I managed to actually
code, and mostly the ideas that someone else might find useful.
To those who may want to involve in the php internals
For those in the generals list that may ever try to venture in the internals
of PHP, remember that you have to back your point of view with a patch. So,
sit down, remember the old days in college using the c compiler, and code
like a cowboy before trying to promote anything in the internals. It's the
status quo of the PHP development community, as I did learn too late.
Namespaces: function imports
Here is the patch to add function imports to 5.3. To be consistent constants
imports have to be added too:
http://martinalterisio.com.ar/php5.3/use.function.v2b.patch
If you don't know what imports are, they are just a way to refer to a longer
name with a shorter name. For example:
?php
class MyRowset extends Zend::Db::Table::Rowset::Abstract {
...
or with imports:
?php
use Zend::Db::Table::Rowset::Abstract as Rowset;
class MyRowset extends Rowset {
...
The use statement behavior currently supports only class names aliasing.
Functions and constants have to referred with full name, although these too
can be namespaced.
Import statement is broken, why, how can be fixed
While doing the previous patch I realized that the use statement is broken.
It should generate and error when you try to override an existing name. But
the use statement is handled at compile, where it's unknown if a name will
be overridden or not. What happens is that the error might be triggered
depending on the conditions and order of compilation. If you have an opcode
cache, this error may not appear until the cache is invalidated.
On a suggestion by Dmitry, which I really don't know if he knew about this
issue with use or not, but, anyway, his idea solved this issue, I made this
patch:
http://martinalterisio.com.ar/php5.3/file.scope.use.patch
With this the use statement is checked only against the names used in the
current file (or namespace if using multiple namespaces per file). Since the
imports only affect the current file, this is more sensible, and the issue
mentioned before disappears.
Name clash and ambiguity issue introduced by namespaces
There's another pending issue with namespaces, there's a name clash that
currently goes undetected, and makes static methods partially unavailable.
This is due to the fact that using :: as namespace separator generates
ambiguity. foo::bar() can refer to the static method bar in class foo, or to
the function bar in the namespace foo. This is an issue to php library
developers. Someone can inject a namespaced function which overrides your
static method.
One possible solution I approached was to prevent the name clash altogether,
but I found this approach inappropriate for 2 reasons: the performance
impact is too big; is not consistent with how other name clashes are handled
in php (classes and functions may have the same name).
Another approach, which I believe is the correct one but never got the
chance to implement in a patch, is to change the order of name resolution,
search first the static method and then the namespaced function, and if the
user wants to refer to the function he can import the function. This way
both remain accessible although the user has to solve the ambiguity. Also
this reduces the impact of adding namespaces on legacy code, since there's
an impact to all static method calls (because first the namespaced function
is searched).
Reducing impact on performance introduced by namespaces
I found out that although the philosophy behind the namespaces
implementation is to do as much as possible in compile time, but much is
pushed to the executor. Those could be solved on compile time. Much can be
optimized changing the name resolution rules. If these become more explicit,
the compiler can discern which is the actual name that's referred to. As of
now, it can be optimized using imports and explicit names, which are used as
alternative notation. In other words, the normal use of namespaces is not
optimal.
There's still one name resolution that seems inevitable that it will fall to
the executor: the ambiguity mentioned earlier between
