RE: [PHP-DEV] my last attempt at sanity with namespaces
Hi,
http://wiki.php.net/rfc/namespaceissues
Read it and discuss.
Solution #1 is imho the best one to disambiguate everything, but the
readability problem is not to be overlooked. To keep this short, just
read the following rewrite of the lines for the problem code:
foo.php
?php
namespace one..step;
function two(){}
namespace one;
class step {
static function two(){}
}
?
main.php
?php
include 'foo.php';
one..step::two(); // clearly namespace one, static method on class step
one..step..two(); // clearly namespace one..step, function two
?
Addressing the cons for the ::: separator:
1. all existing namespace code must still be rewritten, sorry about
that.
2. this..example..with::slight..error..is..much..easier..to::see();
Two sequential dots currently produce a syntax error, so the
implementation doesn't have to worry about ambiguity or bc-issues.
Disclaimer: I have not written any namespaced php code yet (so I'm not
worried about con #1 ;-)).
Ciao, Marc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] moving extensions to pecl
Hiyall and Wez in particular, In general, unless the extension is a really ancient forgotten thing, the person moving it should coordinate with the current maintainer to set that up. That would have been nice :-) Would you mind creating the appropriate package.xml file and tarball and releasing dbx via PECL, Marc? I wouldn't mind but I don't know when I can find some time. Is there some documentation available for the packaging process? I couldn't find a clear pointer on pecl.php.net. Let me know if you need an account for the PECL site. I'm not sure if I now have cvs permissions for dbx in the pecl folder, I used to have them for the /ext folder. Username is mboeren. Anything else I need to package dbx for pecl (and maintain it) would be appreciated too. Ciao, Marc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] moving extensions to pecl
Hiyall, Please note this: This was only removed from PHP 5.1-dev (HEAD), it still exists in the PHP_4_4 branch.. And AFAIK, there are no releases of PHP 5.1 (other than betas) out yet? :) Still, some work needs to be done to make the transition to pecl smoother, such as getting it in the packages list, perhaps the docs should mention it is in pecl too, that kind of thing. Plus it does have a package.xml. Added in 2004/03/24.. Ah, I missed that. So what is needed to get it on the pecl site in the packages list? Ciao, Marc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] moving extensions to pecl
Hiyall, So what is needed to get it on the pecl site in the packages list? 1) It needs to become registered as a package: http://pecl.php.net/package-new.php 2) In order to be downloadable it needs a release: http://pecl.php.net/release-upload.php For all of these steps you need the necessary PECL Karma which you can apply to with this form: http://pecl.php.net/account-request.php Not if I want to keep my existing username :) I'm following up this thread in pecl-dev with my request for pecl-karma. Cheers, Marc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] moving extensions to pecl
Hiyall, A while back ext/dbx and ext/ircg were 'moved to pecl' (without any discussion, but that's not the point). However, there are no packages on pecl for either extension, which might lead people to believe that a 'move to pecl' is more like a 'remove from php' action. Should it not be policy to require the necessary packaging for pecl _before_ the source is moved in cvs? Ciao, Marc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Calling PHP functions from an extension
Doesn't ext/dbx already do what you're doing? John wrote ADOdb so he is looking to speed it up. Which is funny, as I just wrote a pure-PHP version of ext/dbx for use in environments where the C dbx extension is unavailable :-) Cheerio, Marc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PDO (was: SQLite API deficiency)
Hi, I apologize for not going to the end of the thread to see if you posted a link online somewhere to this, but I would love a copy none the less. It wasn't posted yet, but you can find it here: http://www.guidance.nl/php/dbx/dbx.p Cheerio, Marc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PDO (was: SQLite API deficiency)
Hi, i'll update the checkout on my server but you will have it through PECL anyway in a week. I'll wait :-) Great. What are the initial backends that will be supported? SQLite, MySQL, PGSQL? SQLite and Oracle first. We're hoping that the exact two you mentioned follow very shortly after puttin pdo into pecl. Good plan. I would follow that very shortly with MS SQL (which I don't use but should be supported for more corporate reasons) Cheerio, Marc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] differences in the RDBMS ext API's
Hi, [Ard] First of all, in my opinion it would be more useful to concentrate on a true cross-database PHP-level data-object API which can really hide the differences between db implementations, instead of using the exact same function names, and ignoring the implementation differences between the various systems. I'd rather implement buffered queries at the PHP-level for all extensions instead of for Interbase only. I just skim the php-dev list nowadays, but this seems a bit like what the dbx extension does (I wrote that). Now I know dbx is just a lightweight wrapper that doesn't try to emulate specific functionality, and it may still need some more wrapper functions (like commit/rollback and parameter binding) and support for more databases and a better efficiency, but one thing it does is provide a common api and common behaviour for all supported databases (no, Interbase is not among them, but feel free... :-) It does return buffered resultsets for all queries (except when the unbuffered flag is set). It also includes a testset that you can use with any of the supported databases. There are now only very few quirks between databases. I've used it in production with MySQL, ODBC (MS Access really) and Oracle, where I develop in MySQL and deploy in any other: the only modification I must make before deployment is the dbx_connect call: it must specify the correct parameters. Note that you should take care to make your SQL-statements portable too. Anyway, this plug has gone on too long now... :-) Cheerio, Marc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] differences in the RDBMS ext API's
Hi, IMO there are some problems with the dbx extension: - it is a wrapper for PHP modules instead for the underlying database API (therefore slower) True, but this makes for a lot less build-headaches: dbx has no build-dependencies - you cannot rely on it if you depend on an ISP that does not support this extension True for any non-standard extension (however, for this case I usually make a simple, pure-php wrapper with the dbx_function names mapped directly to the database). I would like to see more ISPs include dbx of course, and since it builds without any dependencies and has just a small footprint it should be really easy to do. - it does not include a C API that would be useful for custom PHP modules to access a database I have successfully used the dbx extension from within another (C++)-extension, perhaps not as clean as I would have with an API, but ok. - it does not include an OOP API OOP-ish :-) My dream is a full featured SQL extension completely replacing all other database modules, fast, flexible, build-in by default, recommended to be the best way to access databases in PHP. Yeah, I would have liked that too ;-). I do like the way this is solved in Python with its DB-API, however they have great namespace/module resolution... Just my two cents Appreciated. Cheerio, Marc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
