Re:PHP functions
by
tenman
·
· Score: 4, Interesting
what about the XMLDB libs? please don't come out of the box ditching on PHP cause you can't think of anything better to slabdown to get the phirst post. PHP 3.0 requiered libs to connect to any database, and now supports plenty of the nativly to help techno weenies adopt the platform. But just because the authors wanted to make language easy to use, doen't mean that it not still a powerful force. You can still mod and lib the engine, and you can still tweek the install configs where it beats the pants off of an asp server. You won't hear me talk bad about the 4.0, and I don't want to hear you talk bad about it eather.
Re:PHP functions
by
Fweeky
·
· Score: 4, Interesting
Yeah, it's a bit ugly having a flat namespace of, let's see;
Although I can see the argument for having all the compiled-in extensions loaded all the time, having absolutely everything in the same namespace makes writing procedural code a little dangerous, not to mention leaving a nasty taste in your mouth if you're trying to code in an OO fasion.
The answer is, of course, to put your functions in a seperate namespace (a class in Zend 1, a proper namespace in Zend 2), or to use a naming scheme that's less likely to conflict (personally I use WordCaps (or camelCase) instead of under_scores, but since PHP doesn't stick to under_score style all the time and isn't case sensitive, this isn't a wonderful solution).
Coding in an OO fasion's less an issue for namespace conflicts, and more an issue for getting procedural code thrown in everywhere unless you load performance draining wrappers. PHP's weak object model doesn't help here. After using Ruby I find myself running into PHP's limits a lot harder. *grumble*
I hope that they will move extensions to make use of namespaces sometime (PHP 5, or 6 maybe); i.e. MySQL::connect(), PgSQL::connect(), etc. If nothing else this will help make the language cleaner.
BTW, as for CPAN, some of the PHP bods are trying to produce something like it; PEAR, which includes a passable database abstraction layer, among other things.
Personally, I'd be using Ruby if it had better webserver embeddability (mod_ruby doesn't yet support Apache 2, and the Apache 1 support feels a bit immature) and a nicer CGI API. Running it as a daemon might be an interesting solution, but finding hosts who will allow that might be a bit of a pain. Maybe I should try it out while I can:)
external variables
by
iguild
·
· Score: 2, Interesting
External variables (from the environment, the HTTP request, cookies or the web server) are no longer registered in the global scope by default.
Umm... I'm not sure about others but to me this sounds like a *very* radical change in PHP's behaviour. I updated to PHP 4.2.0 on my server and not a single script worked because PHP simply ignored the variables. For example SquirrelMail didn't even show the login page.
Does someone know how to enable the old behaviour?
Re:PHP functions
by
bluegreenone
·
· Score: 2, Interesting
You are very correct, it's silly to have such DB platform-specific syntax in the language. In addition to PEAR which others have mentioned there is also John Lim's ADODB, a DB abstraction layer for PHP. It seems pretty robust, check it out.
what about the XMLDB libs? please don't come out of the box ditching on PHP cause you can't think of anything better to slabdown to get the phirst post. PHP 3.0 requiered libs to connect to any database, and now supports plenty of the nativly to help techno weenies adopt the platform. But just because the authors wanted to make language easy to use, doen't mean that it not still a powerful force. You can still mod and lib the engine, and you can still tweek the install configs where it beats the pants off of an asp server. You won't hear me talk bad about the 4.0, and I don't want to hear you talk bad about it eather.
Yeah, it's a bit ugly having a flat namespace of, let's see;
:)
-<freaky@voi:~/src/phpdoc/en/functions>-
-% grep '<refentry id="function\.' *.xml |wc -l
2579
2579 functions.
Although I can see the argument for having all the compiled-in extensions loaded all the time, having absolutely everything in the same namespace makes writing procedural code a little dangerous, not to mention leaving a nasty taste in your mouth if you're trying to code in an OO fasion.
The answer is, of course, to put your functions in a seperate namespace (a class in Zend 1, a proper namespace in Zend 2), or to use a naming scheme that's less likely to conflict (personally I use WordCaps (or camelCase) instead of under_scores, but since PHP doesn't stick to under_score style all the time and isn't case sensitive, this isn't a wonderful solution).
Coding in an OO fasion's less an issue for namespace conflicts, and more an issue for getting procedural code thrown in everywhere unless you load performance draining wrappers. PHP's weak object model doesn't help here. After using Ruby I find myself running into PHP's limits a lot harder. *grumble*
I hope that they will move extensions to make use of namespaces sometime (PHP 5, or 6 maybe); i.e. MySQL::connect(), PgSQL::connect(), etc. If nothing else this will help make the language cleaner.
BTW, as for CPAN, some of the PHP bods are trying to produce something like it; PEAR, which includes a passable database abstraction layer, among other things.
Personally, I'd be using Ruby if it had better webserver embeddability (mod_ruby doesn't yet support Apache 2, and the Apache 1 support feels a bit immature) and a nicer CGI API. Running it as a daemon might be an interesting solution, but finding hosts who will allow that might be a bit of a pain. Maybe I should try it out while I can
External variables (from the environment, the HTTP request, cookies or the web server) are no longer registered in the global scope by default.
Umm... I'm not sure about others but to me this sounds like a *very* radical change in PHP's behaviour. I updated to PHP 4.2.0 on my server and not a single script worked because PHP simply ignored the variables. For example SquirrelMail didn't even show the login page.
Does someone know how to enable the old behaviour?
You are very correct, it's silly to have such DB platform-specific syntax in the language. In addition to PEAR which others have mentioned there is also John Lim's ADODB, a DB abstraction layer for PHP. It seems pretty robust, check it out.