RE: [PHP-DEV] YANP (Yet Another Namespace Proposal)
David, You are right, classes that don't use self might break, although there might be a solution for this: when a class declaration is started, immediately "import" the class. This will fix the problem, but I don't really think it's necessary. After all, if you're using an new feature as namespaces for your classes, shouldn't you also be using the new self:: keyword? To answer your question, yes, "My:Nested:Namespace:Class::staticMethod()" should work! In the test I posted in my patch post, I echo a static variable in the class, my_ns:class2::my_static, and it works great! -- Jessie David Zülke wrote: > Sounds sweet. However, I already found a problem there, it has to do with > aliasing. Lots of code (libraries) will, even inside the same class, use > the class name for method calls instead of the "self" keywords for various > reasons. This will break if the user decides to alias the class and use > it, I guess. Other than that, I don't see any problems so far. Does a > My:Nested:Namespace:Class::staticMethod() work? > > Nice work man, keep it up, let's hope we can finally have some > namespaces/packaging support in PHP ;) I wish you luck. +1 from me. > > - David > > P.S: check out http://article.gmane.org/gmane.comp.php.devel/29492, might > be of help, dunno > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: YANP (Yet Another Namespace Proposal)
For previewing purposes, I have attached a patch of what I have so far so
that others can look at it and try it out. I have also attached two PHP
files for testing (_testns.php is the script that should be run after the
patch is applied. This script includes a class from class3.php to
demonstrate two things: namespaces may be spread out in files, and classes
do not have to be immediately available for imports to work).
I based my patch on PHP 5.1.0b2 (not CVS, yet). I have not used the diff
utility before, but here is the command I ran to produce the patch (let me
know if there's a better way):
diff -Bbruw -X diff_exclude.txt php-5.1.0b2-bak/Zend php-5.1.0b2/Zend/ >
ns.patch
Anyways, all the features I've mentioned have been enabled in the patch
except the following:
1) Automatic including of class files.
2) Wildcard imports (or full namespace imports).
I have been checking the code to see what it would take to apply the current
include/require logic against a different INI variable (class_path), but I
digged deeper and deeper into the code and got lost in the streams
functions. So far, it seems I have to create my own opcode (like
ZEND_INCLUDE_OR_EVAL), and when that's encountered, then call whatever
stream function is needed to perform the include against class_path. It
seems like it will take me some time to figure this out, so that's why I
haven't included it yet (maybe someone can help me?).
Please try it out and let me know what you think. I believe this solution
compiles the code to be the equivalent of prefixing all classes, so I think
most of the issues presented in the archives are solved with this solution.
Let me know if you need anything else from me to get it working on your
installation. Also, I'm not sure if there are any attachment restrictions
in this group (email me privately if you can't open the files).
--
Jessie
_class3.php
Description: application/php
diff -Bbruw -X diff_exclude.txt php-5.1.0b2-bak/Zend/zend.c php-5.1.0b2/Zend/zend.c
--- php-5.1.0b2-bak/Zend/zend.c 2005-06-15 15:05:55.0 -0400
+++ php-5.1.0b2/Zend/zend.c 2005-07-09 00:44:41.0 -0400
@@ -34,10 +34,12 @@
# define GLOBAL_CLASS_TABLE global_class_table
# define GLOBAL_CONSTANTS_TABLE global_constants_table
# define GLOBAL_AUTO_GLOBALS_TABLEglobal_auto_globals_table
+# define GLOBAL_IMPORT_CLASS_TABLE global_import_class_table
#else
# define GLOBAL_FUNCTION_TABLECG(function_table)
# define GLOBAL_CLASS_TABLE CG(class_table)
# define GLOBAL_AUTO_GLOBALS_TABLECG(auto_globals)
+# define GLOBAL_IMPORT_CLASS_TABLE CG(import_class_table)
#endif
#if defined(ZEND_WIN32) && ZEND_DEBUG
@@ -88,6 +90,7 @@
HashTable *global_class_table;
HashTable *global_constants_table;
HashTable *global_auto_globals_table;
+HashTable *global_import_class_table;
#endif
ZEND_API zend_utility_values zend_uv;
@@ -430,6 +433,7 @@
{
zend_function tmp_func;
zend_class_entry *tmp_class;
+ zval tmp_zval;
compiler_globals->compiled_filename = NULL;
@@ -443,6 +447,16 @@
zend_set_default_compile_time_values(TSRMLS_C);
+ /* initialize namespace variables */
+ compiler_globals->namespace_prefix = NULL;
+ compiler_globals->namespace_prefix_lc = NULL;
+ compiler_globals->namespace_prefix_len = 0;
+
+ /* initialize the import table */
+ compiler_globals->import_class_table = (HashTable *) malloc(sizeof(HashTable));
+ zend_hash_init_ex(compiler_globals->import_class_table, 10, NULL, ZVAL_DESTRUCTOR, 1, 0);
+zend_hash_copy(compiler_globals->import_class_table, global_import_class_table, NULL, &tmp_zval, sizeof(zval));
+
CG(interactive) = 0;
compiler_globals->auto_globals = (HashTable *) malloc(sizeof(HashTable));
@@ -465,6 +479,10 @@
zend_hash_destroy(compiler_globals->auto_globals);
free(compiler_globals->auto_globals);
}
+ if (compiler_globals->import_class_table != GLOBAL_IMPORT_CLASS_TABLE) {
+ zend_hash_destroy(compiler_globals->import_class_table);
+ free(compiler_globals->import_class_table);
+ }
}
@@ -588,11 +606,13 @@
GLOBAL_FUNCTION_TABLE = (HashTable *) malloc(sizeof(HashTable));
GLOBAL_CLASS_TABLE = (HashTable *) malloc(sizeof(HashTable));
GLOBAL_AUTO_GLOBALS_TABLE = (HashTable *) malloc(sizeof(HashTable));
+ GLOBAL_IMPORT_CLASS_TABLE = (HashTable *) malloc(sizeof(HashTable));
#ifdef ZTS
GLOBAL_CONSTANTS_TABLE = (HashTable *) malloc(sizeof(HashTable));
#endif
zend_hash_init_ex(GLOBAL_FUNCTION_TABLE, 100, NULL, ZEND_FUNCTION_DTOR, 1, 0);
zend_hash_init_ex(GLOBAL_CLASS_TABLE, 10, NULL, ZEND_CLASS_DTOR, 1, 0);
+ zend_hash_init_ex(GLOBAL_IMPORT_CLASS_TABLE, 10, NULL, ZVAL_DESTRUCTOR, 1, 0);
zend_hash_init_ex(&module_registry, 50, NULL, ZEND_MODULE_DTOR, 1, 0);
zend_init_rsrc_list_dtors();
@@ -618,10 +638,12 @@
compiler_globals->in_compilation = 0;
compiler_globals->function_table = (HashTable *) malloc(sizeof(HashTable));
compiler_globals->class_table = (HashTable *) malloc(sizeof(HashTable
[PHP-DEV] is_callable and method_exists always true when __call is defined
Dear all, I came across something when I found this bug (http://bugs.php.net/bug.php?id=33621). Should is_callable() and method_exists() always return true when the method doesn't *really* exist? i.e. it would only be called via __call() Is it possible to add an argument to make it only check "real" methods at the very least? Or some way to additionally distinguish between these two things? - Davey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] YANP (Yet Another Namespace Proposal)
One more thing, here's an example of how things go in the enterprise and where namespaces make or break PHP being used. Every now and then, someone says "Let's merge projects A and B", and those projects could be in different parts of the world, each having 10s if not 100s of developers, and very large code bases. These projects may rarely communicate if ever if they sell to different markets. In Java, you can start writing code to tie them together, because each of them has defined their own package, and you can re-use that code without modifying it inside new code. You just do an import, perhaps use the full namespace prefix (e.g. package) when using classes that conflict otherwise. In PHP today, there are two possibilities. Either someone was smart and enforced some coding guidelines (e.g. PEAR) and people have prefixed their classnames (unlikely as this is an uncommon programming aspect) OR we have a deal breaker issue. Project A has 10,000 lines of code, and Project B has 10,000 lines of code and we have 50 classes of the same name. A global replace doesn't do it, because I may have SQL, other variables, function names similar to that class name. So, one project may get a rewrite or invest a large number of resources to make things compatible and hopefully one project doesn't get the axe. If management gets word of what happened, PHP will be made out to be the villian and there'll be a big fuss and a technology change to Java or something else. I just wanted to throw this out there to set some context on why it's important to the enterprise. I know this feels like a corner case to everyone else, but this is what happens when you have huge organizations developing vast amounts of code. PHP is already a tough sell to a population that has been trained (thanks to colleges) and experienced in something like Java. Thankfully, there are pragmmatic developers out there who see the light of PHP, adopt it, and watch their productivity shoot through the roof for web applications. Anyways, I'm +1 on this YANP sans the import feature as defined in Jessie's proposal. Thanks! Al On Fri, 2005-07-08 at 20:25 -0400, Al Baker wrote: > I think we're trying to boil the ocean here, and in doing so failing to > see both the problems that need to be solved, and the possible > solutions. I'd like to break things down a little bit here to address > what the real problem is with a lack of namespaces in PHP. > > In my eyes, there are really only two problems that arise because of > lack of namespaces. The first is the one true problem we should try to > solve and that is class naming conflicts. Now that PHP is growing and > make inroads into big business, several large development groups may > collaborate on a project. Or, they may want to use a library, only to > find out a class naming conflict. After all they love about PHP, it > seems like this problem makes their lives more difficult by having to > manually prefix all of their classes and use those prefixes throughout > their code. > > So, the most basic namespace proposal should just be a prefix to > classes, allowing the compiler to differentiate between two classes of > the same name, but from different packages. $myobj = new > MySpace:MyClass(); seems good to enough to me. If this is all > namespaces are, an extra label to prefix classes with - no function > namespace, no import, then I say no problem. A namespace hierarchy > should be problem free as well, allowing developers a little more > structure. At compile time, it just results in a longer prefix than if > it were a single namespace. > > This would also solve a slightly different problem, and that is one of > perception to enterprise developers. I know that productivity wise, the > above namespace proposal hardly saves the developer more time than > having to hardcode prefixes into class names. But what it does do, is > it makes sense to a large population of developers, especially those > 'enterprise' (ie Java guys). Honestly, when I pitch how productive PHP > is on my project (100+ developers), the lack of namespaces is a good jab > against PHP. I know people cringe at the term enterprise a little > because accomodating the enterprise doesn't always mean accomodating > everyone. However, in this case, I would say we have critical mass of > interest in namespaces. Having a better prefixing mechanism wouldn't > break legacy code, would be optional, and would make a bunch of people > happy. > > Now, I would assert that Java's import system (of which this proposal > and others often try to follow) is only partially about namespaces, but > is more of a mix of their compile system, source structure, and even > naming conventions. We could do the namespace proposal and not do > imports. > > The whole concept of Java's imports is only partially related to > namespaces. There are a lot of assumptions made in Java's import > system, such as a configuration setting where to loo
Re: [PHP-DEV] YANP (Yet Another Namespace Proposal)
I think we're trying to boil the ocean here, and in doing so failing to see both the problems that need to be solved, and the possible solutions. I'd like to break things down a little bit here to address what the real problem is with a lack of namespaces in PHP. In my eyes, there are really only two problems that arise because of lack of namespaces. The first is the one true problem we should try to solve and that is class naming conflicts. Now that PHP is growing and make inroads into big business, several large development groups may collaborate on a project. Or, they may want to use a library, only to find out a class naming conflict. After all they love about PHP, it seems like this problem makes their lives more difficult by having to manually prefix all of their classes and use those prefixes throughout their code. So, the most basic namespace proposal should just be a prefix to classes, allowing the compiler to differentiate between two classes of the same name, but from different packages. $myobj = new MySpace:MyClass(); seems good to enough to me. If this is all namespaces are, an extra label to prefix classes with - no function namespace, no import, then I say no problem. A namespace hierarchy should be problem free as well, allowing developers a little more structure. At compile time, it just results in a longer prefix than if it were a single namespace. This would also solve a slightly different problem, and that is one of perception to enterprise developers. I know that productivity wise, the above namespace proposal hardly saves the developer more time than having to hardcode prefixes into class names. But what it does do, is it makes sense to a large population of developers, especially those 'enterprise' (ie Java guys). Honestly, when I pitch how productive PHP is on my project (100+ developers), the lack of namespaces is a good jab against PHP. I know people cringe at the term enterprise a little because accomodating the enterprise doesn't always mean accomodating everyone. However, in this case, I would say we have critical mass of interest in namespaces. Having a better prefixing mechanism wouldn't break legacy code, would be optional, and would make a bunch of people happy. Now, I would assert that Java's import system (of which this proposal and others often try to follow) is only partially about namespaces, but is more of a mix of their compile system, source structure, and even naming conventions. We could do the namespace proposal and not do imports. The whole concept of Java's imports is only partially related to namespaces. There are a lot of assumptions made in Java's import system, such as a configuration setting where to look, having one class per file, having that class as the filename for that file, etc. This file including system for the compile matches up with the namespace syntax. Though there's an impression that this is a great system, I would say that it still results in confusion. The dot notation in Java can be used in the context of prefixing a class for proper compilation, accessing a function, a member variable (including those that are classes), a function, and you can string them together like mypackage.myclass.function.returnfunctionsobject.function;. There's no Java.ini to set a directory, you have to set environment variables. If we want to build a more advanced include system, then I would say that the labels should map to sub-directories in some directory specified in php.ini, and the last token in the import statement just performs a normal PHP include. E.g. if it's import mypackage.*; it would go to the predefined directory, go to the my package subdirectory, and perform an include on all the class files in that directory. Of course, we'd always want to have strict class/file names for this to work as well and only one class per file. Thanks, Al
Re: [PHP-DEV] YANP (Yet Another Namespace Proposal)
JH>>With the above scenario, nothing will be affected if there is an JH>>opcode cache or not. The only situation I can think of where an opcode JH>>cache can affect this is when the script DYNAMICALLY creates classes JH>>from the imported namespace. Maybe there's other situations, but I JH>>can't come up with any at the moment. No, more simple - somebody removes one of the classes. Even if nothing in your code ever used it, you'd start getting errors about missing files. JH>>Either way, I'm not sure if full namespace imports are a good idea anyways. Without this, only thing you are achieving with imports is saving a couple of keystrokes. If you have to declare each imported class anyway, why not name it by the full name? Just saving a dozen of keystrokes (which any good code-completing editor would save anyway) and one require statement is not worth the trouble, IMHO. JH>>Issues like the one you presented are one reason, and the other is that it JH>>is bad practice. If multiple namespaces are imported, readability is JH>>affected (which class belongs to which namespace?). Also, if two namespaces That's a general problem with all namespace imports. JH>>are imported, and one day a new class is added to one which has the same JH>>name as another, then there will suddenly be a compile error, and the error JH>>will be elusive. Right, that's one more problem with namespace imports. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date/timezone classes
Since the underlying way of passing internal data would be an object, the functions you propose may as well be object methods. Aside from that the API looks good. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date/timezone classes
Hello Pierre-Alain, since we now have ext/date shouldn't we rename pecl/date to something different for easier integration? And i also do not know if we aren't running into problems later if two extensions have the same name. marcus Friday, July 8, 2005, 12:44:45 PM, you wrote: > On Fri, 8 Jul 2005 09:16:29 +0200 (CEST) > [EMAIL PROTECTED] (Derick Rethans) wrote: >> Objects are not harder to implement, I found it actually more >> straight forward. Besides that, making it an object allows other >> people to extend it, something that Pierre wants for his pecl/ >> date. > I do not want to extend a basic date object. This adds overheads for > nothing. pecl/date was originally designed to be integrated in php, > see: > http://marc.theaimsgroup.com/?l=php-dev&m=104540995515576&w=2 > Integrate it in ext/date, keeping full BC with existing functions as > they do not change. When the implementations reach a stable state, > we could have been able to use it inside the current functions and > move them to ext/date. > By the way, an object with basic method/properties and more > "advanced" methods/ properties will not consume more memory, will > not add overhead to people who does not want to use an object. >> ? The way how they expose datatypes doesn't really differ. It's >> just that *currently* I've no plans to add fancy methodnames. All >> other functions on standard datatypes work with functions. This >> falls IMO in the same category as not wanting a full blown String >> class in the core of PHP. > Even if I agree on you about a String class, you miss the point. A > 12k buffer upper cased with current functions ends with 2x 12k > buffers. > About a date/time object, these values have much more properties. > It is slighty more difficult to deal with them (non linear, > exceptions, etc.). People needs to work with ranges, arythmetics. > They also need some simple (and fast) function to get informations > other than the current properties. > Another additions are iterators, filtered iterators are a killing > feature for people having to create complex calendar applications. > a complex calendar applications is something else that the current > month calendar displayed on every single blog out there. > But words are sometimes useless, I will put my thoughts in pecl/ > date. This is a perfect place to make experiments on an usefull > APIs and get feedbacks. Once we (not only you and me but everyone > having some clue) agree on the features and the specifications, we > can then put in ext/date. > Regards, > --Pierre -- Best regards, Marcusmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date/timezone classes
Hello Derick,
Friday, July 8, 2005, 2:31:14 PM, you wrote:
> On Fri, 8 Jul 2005, Edin Kadribasic wrote:
>> I would love to be able to do something like this:
>>
>> $d = new Date(time());
>> $d->month++;
>> $d->print("Y-m-d"); // date() equiv.
> Adding methods is no problem, that's what you get for free anyway, I
> just think that $d->month is too much magic, and not reproducable in non
> OO.
I wouldn't care for non oo here. And instead pretty much appreciate such
stuff since it'd heavliy simplify working on calendar tools and still
have nice readable code.
--
Best regards,
Marcusmailto:[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date/timezone classes
At 02:36 PM 7/8/2005 +0200, Pierre-Alain Joye wrote:
On Fri, 8 Jul 2005 14:31:14 +0200 (CEST)
Derick Rethans <[EMAIL PROTECTED]> wrote:
> On Fri, 8 Jul 2005, Edin Kadribasic wrote:
>
> > I would love to be able to do something like this:
> >
> > $d = new Date(time());
> > $d->month++;
> > $d->print("Y-m-d"); // date() equiv.
>
> Adding methods is no problem, that's what you get for free
> anyway, I just think that $d->month is too much magic, and not
> reproducable in non OO. (Also, passing a timestamp with time() is
> not always working, because of windows' limitations with it,
> that's the reason why I made it a string, or empty in case you
> want to use current time).
for the current time, it's fine. For example getting the next
monday is pretty easy using this way.
Properties are not magic. Thier behiavors have to be well
documented. And how they work discussed.
I talked a bit with Derick on IRC. I will take some times to
finalize the specifications and put them online. We can then have a
document to talk about. Not like I like to talk endlessly but there
is issues we have to agree on before any implementation. Expect it
over the weekend.
Great. I definitely think you two should work together on this one.
Andi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date/timezone classes
On Fri, 8 Jul 2005 14:31:14 +0200 (CEST)
Derick Rethans <[EMAIL PROTECTED]> wrote:
> On Fri, 8 Jul 2005, Edin Kadribasic wrote:
>
> > I would love to be able to do something like this:
> >
> > $d = new Date(time());
> > $d->month++;
> > $d->print("Y-m-d"); // date() equiv.
>
> Adding methods is no problem, that's what you get for free
> anyway, I just think that $d->month is too much magic, and not
> reproducable in non OO. (Also, passing a timestamp with time() is
> not always working, because of windows' limitations with it,
> that's the reason why I made it a string, or empty in case you
> want to use current time).
for the current time, it's fine. For example getting the next
monday is pretty easy using this way.
Properties are not magic. Thier behiavors have to be well
documented. And how they work discussed.
I talked a bit with Derick on IRC. I will take some times to
finalize the specifications and put them online. We can then have a
document to talk about. Not like I like to talk endlessly but there
is issues we have to agree on before any implementation. Expect it
over the weekend.
Regards,
--Pierre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date/timezone classes
On Fri, 8 Jul 2005, Edin Kadribasic wrote:
> I would love to be able to do something like this:
>
> $d = new Date(time());
> $d->month++;
> $d->print("Y-m-d"); // date() equiv.
Adding methods is no problem, that's what you get for free anyway, I
just think that $d->month is too much magic, and not reproducable in non
OO. (Also, passing a timestamp with time() is not always working,
because of windows' limitations with it, that's the reason why I made it
a string, or empty in case you want to use current time).
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date/timezone classes
On Friday 08 July 2005 02:17, Pierre-Alain Joye wrote:
[snip]
> This is what I talk about when I say a common Date object in php.
> Derick exported the headers on my demand, this is a good first step.
I agree that it would be a great idea to have a common Date object in PHP. And
since most of it is already implemeted by the new timelib and the existing
object code in PECL/date I see no reason not merge that in core date module.
I would love to be able to do something like this:
$d = new Date(time());
$d->month++;
$d->print("Y-m-d"); // date() equiv.
And implement all other datetime functions in similar matter.
Edin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date/timezone classes
On Fri, 8 Jul 2005 09:16:29 +0200 (CEST) [EMAIL PROTECTED] (Derick Rethans) wrote: > Objects are not harder to implement, I found it actually more > straight forward. Besides that, making it an object allows other > people to extend it, something that Pierre wants for his pecl/ > date. I do not want to extend a basic date object. This adds overheads for nothing. pecl/date was originally designed to be integrated in php, see: http://marc.theaimsgroup.com/?l=php-dev&m=104540995515576&w=2 Integrate it in ext/date, keeping full BC with existing functions as they do not change. When the implementations reach a stable state, we could have been able to use it inside the current functions and move them to ext/date. By the way, an object with basic method/properties and more "advanced" methods/ properties will not consume more memory, will not add overhead to people who does not want to use an object. > ? The way how they expose datatypes doesn't really differ. It's > just that *currently* I've no plans to add fancy methodnames. All > other functions on standard datatypes work with functions. This > falls IMO in the same category as not wanting a full blown String > class in the core of PHP. Even if I agree on you about a String class, you miss the point. A 12k buffer upper cased with current functions ends with 2x 12k buffers. About a date/time object, these values have much more properties. It is slighty more difficult to deal with them (non linear, exceptions, etc.). People needs to work with ranges, arythmetics. They also need some simple (and fast) function to get informations other than the current properties. Another additions are iterators, filtered iterators are a killing feature for people having to create complex calendar applications. a complex calendar applications is something else that the current month calendar displayed on every single blog out there. But words are sometimes useless, I will put my thoughts in pecl/ date. This is a perfect place to make experiments on an usefull APIs and get feedbacks. Once we (not only you and me but everyone having some clue) agree on the features and the specifications, we can then put in ext/date. Regards, --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php_pgsql.dll
OK, I see what's going on here. The downloads page is just bad... It says "there are no extensions in the installer" and it also says "the extensions are available in the pecl download" Whereas in fact the pecl download does not include all the extensions that are not available in the installer. So in fact the installer is basically useless... Pretty confusing... Chris Nicholas Telford wrote: Regardless, you need to download the ZIP that is clearly stated on the downloads page. The installer contains no additional modules, this is also clearly stated. This question should have been posted to php.general or php.install, not internals. Nicholas Telford Christopher Kings-Lynne wrote: No, I just said that the "Collection of PECL modules for PHP 5.0.4" on the downloads page does NOT contain php_pgsql.dll - nor any other db for that matter. Chris Dan Scott wrote: Of course -- the "Collection of PECL modules for PHP 5.0.4" from http://php.net/downloads.php. I had leapt to the (probably false) conclusion that Christopher wanted a newer version of the module. Dan On 7/7/05, Edin Kadribasic <[EMAIL PROTECTED]> wrote: Just download regular php-5.0.4-Win32.zip The download page clearly states that there are no extension bundled with the installer. Edin - Original Message - From: "Dan Scott" <[EMAIL PROTECTED]> To: "Christopher Kings-Lynne" <[EMAIL PROTECTED]> Cc: "php-dev" Sent: Thursday, July 07, 2005 12:48 PM Subject: Re: [PHP-DEV] php_pgsql.dll Try http://snaps.php.net/ for the "PECL extensions for the Stable 5.0 branch". Dan. On 7/6/05, Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote: Where do you get php_pgsql.dll for the PHP for windows 5.0.4 installer? I installed the PECL package - no pgsql. I searched the PECL site - no pgsql. What gives? Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php_pgsql.dll
Regardless, you need to download the ZIP that is clearly stated on the downloads page. The installer contains no additional modules, this is also clearly stated. This question should have been posted to php.general or php.install, not internals. Nicholas Telford Christopher Kings-Lynne wrote: No, I just said that the "Collection of PECL modules for PHP 5.0.4" on the downloads page does NOT contain php_pgsql.dll - nor any other db for that matter. Chris Dan Scott wrote: Of course -- the "Collection of PECL modules for PHP 5.0.4" from http://php.net/downloads.php. I had leapt to the (probably false) conclusion that Christopher wanted a newer version of the module. Dan On 7/7/05, Edin Kadribasic <[EMAIL PROTECTED]> wrote: Just download regular php-5.0.4-Win32.zip The download page clearly states that there are no extension bundled with the installer. Edin - Original Message - From: "Dan Scott" <[EMAIL PROTECTED]> To: "Christopher Kings-Lynne" <[EMAIL PROTECTED]> Cc: "php-dev" Sent: Thursday, July 07, 2005 12:48 PM Subject: Re: [PHP-DEV] php_pgsql.dll Try http://snaps.php.net/ for the "PECL extensions for the Stable 5.0 branch". Dan. On 7/6/05, Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote: Where do you get php_pgsql.dll for the PHP for windows 5.0.4 installer? I installed the PECL package - no pgsql. I searched the PECL site - no pgsql. What gives? Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: date/timezone classes
On Thu, 7 Jul 2005, Pierre-Alain Joye wrote:
> The other are only duplicated with current function. This is maybe
> useless. The worst being to rely on strtotime to manipulate date,
> this is maybe human readable (understandable is another
> question ;), but it is slooow, and the best way to hell for non
> english application.
I've been thinking about this, but the other way I could come up with is
by passing a complex array instead of the textual description, something
like:
$modi = array('month' => 1);
But then does that mean: next month, month 1 (january) or "first
month"... I'm open here for other solutions, I just didn't find a better
one that using strtotime() equivalent modifiers here. I also think that
consistency is good :)
> When we talked about a common object or resource in PHP, based on
> what you did not read in pecl/date, it was about real transparency
> throug methods able to work with date/time values.
>
> I suggest to make this enhancement in pecl/date. All the base is
> already here.
Right, one of the reasons that I made it an object, you can easily
extend it there.
> This is anyway a task post 5.1, for now your implementation has to
> be bullet proofed until that (thinking about timezone and some
> function like week number or other sources of annoyance).
Week numbers work fine? Do you see a bug? If so, send me a reproducable
script.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date/timezone classes
On Thu, 7 Jul 2005, Andi Gutmans wrote: > If you're just wrapping the date type with a class, I don't see why it > shouldn't be a resource. It'd give you the same thing but would be easier to > implement (unless I'm missing something). Objects are not harder to implement, I found it actually more straight forward. Besides that, making it an object allows other people to extend it, something that Pierre wants for his pecl/date. > I realize you personally aren't fond of OO but it actually would work very > nicely with a Date class. I'm not talking about OO as in over-architecting and > having a huge hierarchy but just having easy to use methods on the > Date/TimeZone classes (one simple level). > > It would look the following: > > $timeZone->getName(); > vs. > date_timezone_get($date); Those are not equivalent. > $date->getOffset(); > vs. > date_offset_get($date); > > Personally, unrelated to OO I think it's a nicer and cleaner way of exposing > such an API. It would also make it easier for some of the other new extensions > like SimpleXML, SOAP, PDO , etc. to take advantage of it when exposing data > types. ? The way how they expose datatypes doesn't really differ. It's just that *currently* I've no plans to add fancy methodnames. All other functions on standard datatypes work with functions. This falls IMO in the same category as not wanting a full blown String class in the core of PHP. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
