Re: [PHP-DEV] type hinting
On Wed, 2008-01-09 at 00:58 +0200, Tomi Kaistila wrote: Ok, but a scalar becomes useful for a couple of important things. Scalars are all displayable values, that can be stored in a db, outputted, etc. The scalar type hint prevents errors related to objects, resources, and arrays attempting to be stored in the db or echoed. True, but honestly I do not see a whole lot of use for this. In a word, it is very limited. _Too_ limited to be truly useful in my opinion. It is simple statistics; there is more need for specific types than scalars in general, when using type hinting. I do agree that it is a good idea to allow for type hinting scalars in general, but it should not be considered a solution. It is more like a comfortable add-on. And to be frank, this really feels like a secondary price (bronze at most). If pressed I would go bold say that this really feels like a screw. A way of saying that we went out of our way to fix this feature that was limited by adding a seemingly useful attribute to it, but in the end still leaving the feature limited and not really fixing anything. A useful addon is better than none though, regardless. I agree this is not a full solution, but I'd rather have 3 type hints than 2. Tomi Kaistila PHP Developer -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting
Hi, I am still wondering if we ever going to get a summary of this discussion. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] date/timelib: use system timezone database
Hi folks. It's a bit of a maintenance headache for distributions when
packages include their own copy of the timezone database, since this
needs to be updated frequently.
I've prepared a patch to allow the timelib code to use the system
timezone database directly; would something like this be acceptable, any
thoughts? This passes the ext/date tests, and reduces the PHP binary
size by about 300K to boot.
Notes:
1) I've not implemented timelib_timezone_builtin_identifiers_list() here
since it doesn't seem to be used, is it there for third-party
extensions? It could be implemented by iterating through the directory.
2) there's no general way that I can find to obtain the database
version, so I just invented a string here.
joe
Index: ext/date/lib/parse_tz.c
===
RCS file: /repository/php-src/ext/date/lib/parse_tz.c,v
retrieving revision 1.35
diff -u -r1.35 parse_tz.c
--- ext/date/lib/parse_tz.c 31 Dec 2007 07:12:08 - 1.35
+++ ext/date/lib/parse_tz.c 9 Jan 2008 14:04:28 -
@@ -20,6 +20,14 @@
#include timelib.h
+#ifdef HAVE_SYSTEM_TZDATA
+#include sys/mman.h
+#include sys/stat.h
+#include limits.h
+#include fcntl.h
+#include unistd.h
+#endif
+
#include stdio.h
#ifdef HAVE_STRING_H
@@ -27,7 +35,10 @@
#else
#include strings.h
#endif
+
+#ifndef HAVE_SYSTEM_TZDATA
#include timezonedb.h
+#endif
#if (defined(__APPLE__) || defined(__APPLE_CC__)) (defined(__BIG_ENDIAN__)
|| defined(__LITTLE_ENDIAN__))
# if defined(__LITTLE_ENDIAN__)
@@ -202,6 +213,86 @@
}
}
+#ifdef HAVE_SYSTEM_TZDATA
+
+#ifdef HAVE_SYSTEM_TZDATA_PREFIX
+#define ZONEINFO_PREFIX HAVE_SYSTEM_TZDATA_PREFIX
+#else
+#define ZONEINFO_PREFIX /usr/share/zoneinfo
+#endif
+
+static const timelib_tzdb timezonedb_system = { 0.system, 0, NULL, NULL };
+
+/* Return the mmap()ed tzfile if found, else NULL. On success, the
+ * length of the mapped data is placed in *length. */
+static char *map_tzfile(const char *timezone, size_t *length)
+{
+ char fname[PATH_MAX];
+ struct stat st;
+ char *p;
+ int fd;
+
+ snprintf(fname, sizeof fname, ZONEINFO_PREFIX /%s, timezone);
+
+ fd = open(fname, O_RDONLY);
+ if (fd == -1) {
+ return NULL;
+ } else if (fstat(fd, st) != 0 || st.st_size 21) {
+ close(fd);
+ return NULL;
+ }
+
+ *length = st.st_size;
+ p = mmap(NULL, st.st_size, PROT_READ, MAP_SHARED, fd, 0);
+ close(fd);
+
+ return p != MAP_FAILED ? p : NULL;
+}
+
+const timelib_tzdb *timelib_builtin_db(void)
+{
+ return timezonedb_system;
+}
+
+const timelib_tzdb_index_entry *timelib_timezone_builtin_identifiers_list(int
*count)
+{
+ *count = 0;
+ return NULL;
+}
+
+int timelib_timezone_id_is_valid(char *timezone, const timelib_tzdb *tzdb)
+{
+ char fname[PATH_MAX];
+
+ snprintf(fname, sizeof fname, ZONEINFO_PREFIX /%s, timezone);
+
+ return access(fname, R_OK) == 0 ? 1 : 0;
+}
+
+timelib_tzinfo *timelib_parse_tzfile(char *timezone, const timelib_tzdb *tzdb)
+{
+ char *tzf, *orig;
+ timelib_tzinfo *tmp;
+ size_t len;
+
+ orig = map_tzfile(timezone, len);
+ if (orig == NULL) {
+ return NULL;
+ }
+
+ tmp = timelib_tzinfo_ctor(timezone);
+
+ tzf = orig + 20;
+ read_header(tzf, tmp);
+ read_transistions(tzf, tmp);
+ read_types(tzf, tmp);
+
+ munmap(orig, len);
+
+ return tmp;
+}
+#else
+
static int seek_to_tz_position(const unsigned char **tzf, char *timezone,
const timelib_tzdb *tzdb)
{
int left = 0, right = tzdb-index_size - 1;
@@ -258,6 +349,7 @@
return tmp;
}
+#endif
static ttinfo* fetch_timezone_offset(timelib_tzinfo *tz, timelib_sll ts,
timelib_sll *transition_time)
{
Index: ext/date/lib/timelib.m4
===
RCS file: /repository/php-src/ext/date/lib/timelib.m4,v
retrieving revision 1.4
diff -u -r1.4 timelib.m4
--- ext/date/lib/timelib.m4 3 Jul 2005 23:30:52 - 1.4
+++ ext/date/lib/timelib.m4 9 Jan 2008 14:04:28 -
@@ -78,3 +78,17 @@
dnl Check for strtoll, atoll
AC_CHECK_FUNCS(strtoll atoll strftime)
+
+PHP_ARG_WITH(system-tzdata, for use of system timezone data,
+[ --with-system-tzdata[=DIR] to specify use of system timezone data],
+no, no)
+
+if test $PHP_SYSTEM_TZDATA != no; then
+ AC_DEFINE(HAVE_SYSTEM_TZDATA, 1, [Define if system timezone data is used])
+
+ if test $PHP_SYSTEM_TZDATA != yes; then
+ AC_DEFINE_UNQUOTED(HAVE_SYSTEM_TZDATA_PREFIX, $PHP_SYSTEM_TZDATA,
+ [Define for location of system timezone data])
+ fi
+fi
+
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] date/timelib: use system timezone database
Definitely a great idea, since most linux distributions already bundle this
information and update it frequently.
BTW, your implementation seems to require some security checks for timezone
names like ../../../etc/passwd.
Nuno
- Original Message -
From: Joe Orton [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; internals@lists.php.net
Sent: Wednesday, January 09, 2008 2:15 PM
Subject: [PHP-DEV] [PATCH] date/timelib: use system timezone database
Hi folks. It's a bit of a maintenance headache for distributions when
packages include their own copy of the timezone database, since this
needs to be updated frequently.
I've prepared a patch to allow the timelib code to use the system
timezone database directly; would something like this be acceptable, any
thoughts? This passes the ext/date tests, and reduces the PHP binary
size by about 300K to boot.
Notes:
1) I've not implemented timelib_timezone_builtin_identifiers_list() here
since it doesn't seem to be used, is it there for third-party
extensions? It could be implemented by iterating through the directory.
2) there's no general way that I can find to obtain the database
version, so I just invented a string here.
joe
Index: ext/date/lib/parse_tz.c
===
RCS file: /repository/php-src/ext/date/lib/parse_tz.c,v
retrieving revision 1.35
diff -u -r1.35 parse_tz.c
--- ext/date/lib/parse_tz.c 31 Dec 2007 07:12:08 - 1.35
+++ ext/date/lib/parse_tz.c 9 Jan 2008 14:04:28 -
@@ -20,6 +20,14 @@
#include timelib.h
+#ifdef HAVE_SYSTEM_TZDATA
+#include sys/mman.h
+#include sys/stat.h
+#include limits.h
+#include fcntl.h
+#include unistd.h
+#endif
+
#include stdio.h
#ifdef HAVE_STRING_H
@@ -27,7 +35,10 @@
#else
#include strings.h
#endif
+
+#ifndef HAVE_SYSTEM_TZDATA
#include timezonedb.h
+#endif
#if (defined(__APPLE__) || defined(__APPLE_CC__))
(defined(__BIG_ENDIAN__) || defined(__LITTLE_ENDIAN__))
# if defined(__LITTLE_ENDIAN__)
@@ -202,6 +213,86 @@
}
}
+#ifdef HAVE_SYSTEM_TZDATA
+
+#ifdef HAVE_SYSTEM_TZDATA_PREFIX
+#define ZONEINFO_PREFIX HAVE_SYSTEM_TZDATA_PREFIX
+#else
+#define ZONEINFO_PREFIX /usr/share/zoneinfo
+#endif
+
+static const timelib_tzdb timezonedb_system = { 0.system, 0, NULL,
NULL };
+
+/* Return the mmap()ed tzfile if found, else NULL. On success, the
+ * length of the mapped data is placed in *length. */
+static char *map_tzfile(const char *timezone, size_t *length)
+{
+ char fname[PATH_MAX];
+ struct stat st;
+ char *p;
+ int fd;
+
+ snprintf(fname, sizeof fname, ZONEINFO_PREFIX /%s, timezone);
+
+ fd = open(fname, O_RDONLY);
+ if (fd == -1) {
+ return NULL;
+ } else if (fstat(fd, st) != 0 || st.st_size 21) {
+ close(fd);
+ return NULL;
+ }
+
+ *length = st.st_size;
+ p = mmap(NULL, st.st_size, PROT_READ, MAP_SHARED, fd, 0);
+ close(fd);
+
+ return p != MAP_FAILED ? p : NULL;
+}
+
+const timelib_tzdb *timelib_builtin_db(void)
+{
+ return timezonedb_system;
+}
+
+const timelib_tzdb_index_entry
*timelib_timezone_builtin_identifiers_list(int *count)
+{
+ *count = 0;
+ return NULL;
+}
+
+int timelib_timezone_id_is_valid(char *timezone, const timelib_tzdb
*tzdb)
+{
+ char fname[PATH_MAX];
+
+ snprintf(fname, sizeof fname, ZONEINFO_PREFIX /%s, timezone);
+
+ return access(fname, R_OK) == 0 ? 1 : 0;
+}
+
+timelib_tzinfo *timelib_parse_tzfile(char *timezone, const timelib_tzdb
*tzdb)
+{
+ char *tzf, *orig;
+ timelib_tzinfo *tmp;
+ size_t len;
+
+ orig = map_tzfile(timezone, len);
+ if (orig == NULL) {
+ return NULL;
+ }
+
+ tmp = timelib_tzinfo_ctor(timezone);
+
+ tzf = orig + 20;
+ read_header(tzf, tmp);
+ read_transistions(tzf, tmp);
+ read_types(tzf, tmp);
+
+ munmap(orig, len);
+
+ return tmp;
+}
+#else
+
static int seek_to_tz_position(const unsigned char **tzf, char *timezone,
const timelib_tzdb *tzdb)
{
int left = 0, right = tzdb-index_size - 1;
@@ -258,6 +349,7 @@
return tmp;
}
+#endif
static ttinfo* fetch_timezone_offset(timelib_tzinfo *tz, timelib_sll ts,
timelib_sll *transition_time)
{
Index: ext/date/lib/timelib.m4
===
RCS file: /repository/php-src/ext/date/lib/timelib.m4,v
retrieving revision 1.4
diff -u -r1.4 timelib.m4
--- ext/date/lib/timelib.m4 3 Jul 2005 23:30:52 - 1.4
+++ ext/date/lib/timelib.m4 9 Jan 2008 14:04:28 -
@@ -78,3 +78,17 @@
dnl Check for strtoll, atoll
AC_CHECK_FUNCS(strtoll atoll strftime)
+
+PHP_ARG_WITH(system-tzdata, for use of system timezone data,
+[ --with-system-tzdata[=DIR] to specify use of system timezone
data],
+no, no)
+
+if test $PHP_SYSTEM_TZDATA != no; then
+ AC_DEFINE(HAVE_SYSTEM_TZDATA, 1, [Define if system timezone data is
used])
+
+ if test $PHP_SYSTEM_TZDATA != yes; then
+ AC_DEFINE_UNQUOTED(HAVE_SYSTEM_TZDATA_PREFIX, $PHP_SYSTEM_TZDATA,
+ [Define for location of system timezone data])
+ fi
+fi
+
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Re: [PHP-DEV] [PATCH] date/timelib: use system timezone database
2008/1/9, Joe Orton [EMAIL PROTECTED]: Hi folks. It's a bit of a maintenance headache for distributions when packages include their own copy of the timezone database, since this needs to be updated frequently. +1000 :-D -- http://www.kissofjudas.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] date/timelib: use system timezone database
2008/1/9, Joe Orton [EMAIL PROTECTED]: Hi folks. It's a bit of a maintenance headache for distributions when packages include their own copy of the timezone database, since this needs to be updated frequently. It is also a bit of a headache when a server does not have a complete timezone database for an application to utilize. PHP did use the system timezone database for a long time. But, applications like Phorum would have to end up making their own (and not nearly as robust) anyway because servers would not have all the timezones on the system. The new way of PHP solves this for application developers. -1000 -- Brian Moon Senior Developer -- When you care enough to spend the very least. http://dealnews.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] date/timelib: use system timezone database
The reason we do not use the system database is because it is
inconsistent and likely is updated less frequently then the one
included with PHP.
-1.
On 9-Jan-08, at 9:15 AM, Joe Orton wrote:
Hi folks. It's a bit of a maintenance headache for distributions when
packages include their own copy of the timezone database, since this
needs to be updated frequently.
I've prepared a patch to allow the timelib code to use the system
timezone database directly; would something like this be acceptable,
any
thoughts? This passes the ext/date tests, and reduces the PHP binary
size by about 300K to boot.
Notes:
1) I've not implemented timelib_timezone_builtin_identifiers_list()
here
since it doesn't seem to be used, is it there for third-party
extensions? It could be implemented by iterating through the
directory.
2) there's no general way that I can find to obtain the database
version, so I just invented a string here.
joe
Index: ext/date/lib/parse_tz.c
===
RCS file: /repository/php-src/ext/date/lib/parse_tz.c,v
retrieving revision 1.35
diff -u -r1.35 parse_tz.c
--- ext/date/lib/parse_tz.c 31 Dec 2007 07:12:08 - 1.35
+++ ext/date/lib/parse_tz.c 9 Jan 2008 14:04:28 -
@@ -20,6 +20,14 @@
#include timelib.h
+#ifdef HAVE_SYSTEM_TZDATA
+#include sys/mman.h
+#include sys/stat.h
+#include limits.h
+#include fcntl.h
+#include unistd.h
+#endif
+
#include stdio.h
#ifdef HAVE_STRING_H
@@ -27,7 +35,10 @@
#else
#include strings.h
#endif
+
+#ifndef HAVE_SYSTEM_TZDATA
#include timezonedb.h
+#endif
#if (defined(__APPLE__) || defined(__APPLE_CC__))
(defined(__BIG_ENDIAN__) || defined(__LITTLE_ENDIAN__))
# if defined(__LITTLE_ENDIAN__)
@@ -202,6 +213,86 @@
}
}
+#ifdef HAVE_SYSTEM_TZDATA
+
+#ifdef HAVE_SYSTEM_TZDATA_PREFIX
+#define ZONEINFO_PREFIX HAVE_SYSTEM_TZDATA_PREFIX
+#else
+#define ZONEINFO_PREFIX /usr/share/zoneinfo
+#endif
+
+static const timelib_tzdb timezonedb_system = { 0.system, 0,
NULL, NULL };
+
+/* Return the mmap()ed tzfile if found, else NULL. On success, the
+ * length of the mapped data is placed in *length. */
+static char *map_tzfile(const char *timezone, size_t *length)
+{
+ char fname[PATH_MAX];
+ struct stat st;
+ char *p;
+ int fd;
+
+ snprintf(fname, sizeof fname, ZONEINFO_PREFIX /%s, timezone);
+
+ fd = open(fname, O_RDONLY);
+ if (fd == -1) {
+ return NULL;
+ } else if (fstat(fd, st) != 0 || st.st_size 21) {
+ close(fd);
+ return NULL;
+ }
+
+ *length = st.st_size;
+ p = mmap(NULL, st.st_size, PROT_READ, MAP_SHARED, fd, 0);
+ close(fd);
+
+ return p != MAP_FAILED ? p : NULL;
+}
+
+const timelib_tzdb *timelib_builtin_db(void)
+{
+ return timezonedb_system;
+}
+
+const timelib_tzdb_index_entry
*timelib_timezone_builtin_identifiers_list(int *count)
+{
+ *count = 0;
+ return NULL;
+}
+
+int timelib_timezone_id_is_valid(char *timezone, const timelib_tzdb
*tzdb)
+{
+ char fname[PATH_MAX];
+
+ snprintf(fname, sizeof fname, ZONEINFO_PREFIX /%s, timezone);
+
+ return access(fname, R_OK) == 0 ? 1 : 0;
+}
+
+timelib_tzinfo *timelib_parse_tzfile(char *timezone, const
timelib_tzdb *tzdb)
+{
+ char *tzf, *orig;
+ timelib_tzinfo *tmp;
+ size_t len;
+
+ orig = map_tzfile(timezone, len);
+ if (orig == NULL) {
+ return NULL;
+ }
+
+ tmp = timelib_tzinfo_ctor(timezone);
+
+ tzf = orig + 20;
+ read_header(tzf, tmp);
+ read_transistions(tzf, tmp);
+ read_types(tzf, tmp);
+
+ munmap(orig, len);
+
+ return tmp;
+}
+#else
+
static int seek_to_tz_position(const unsigned char **tzf, char
*timezone, const timelib_tzdb *tzdb)
{
int left = 0, right = tzdb-index_size - 1;
@@ -258,6 +349,7 @@
return tmp;
}
+#endif
static ttinfo* fetch_timezone_offset(timelib_tzinfo *tz, timelib_sll
ts, timelib_sll *transition_time)
{
Index: ext/date/lib/timelib.m4
===
RCS file: /repository/php-src/ext/date/lib/timelib.m4,v
retrieving revision 1.4
diff -u -r1.4 timelib.m4
--- ext/date/lib/timelib.m4 3 Jul 2005 23:30:52 - 1.4
+++ ext/date/lib/timelib.m4 9 Jan 2008 14:04:28 -
@@ -78,3 +78,17 @@
dnl Check for strtoll, atoll
AC_CHECK_FUNCS(strtoll atoll strftime)
+
+PHP_ARG_WITH(system-tzdata, for use of system timezone data,
+[ --with-system-tzdata[=DIR] to specify use of system
timezone data],
+no, no)
+
+if test $PHP_SYSTEM_TZDATA != no; then
+ AC_DEFINE(HAVE_SYSTEM_TZDATA, 1, [Define if system timezone data
is used])
+
+ if test $PHP_SYSTEM_TZDATA != yes; then
+ AC_DEFINE_UNQUOTED(HAVE_SYSTEM_TZDATA_PREFIX,
$PHP_SYSTEM_TZDATA,
+ [Define for location of system timezone
data])
+ fi
+fi
+
Re: [PHP-DEV] [PATCH] date/timelib: use system timezone database
On Wed, 9 Jan 2008, Joe Orton wrote: It's a bit of a maintenance headache for distributions when packages include their own copy of the timezone database, since this needs to be updated frequently. There is a PECL extension to provide those updates: http://pecl.php.net/package/timezonedb It is a drop-in replacement to update the rules. I've prepared a patch to allow the timelib code to use the system timezone database directly; would something like this be acceptable, any thoughts? Quite a few actually. Notes: 1) I've not implemented timelib_timezone_builtin_identifiers_list() here since it doesn't seem to be used, is it there for third-party extensions? It could be implemented by iterating through the directory. It's not used (anymore). However, there is a PHP function timezone_identifiers_list that uses the index information to enumerate all entries. Your patch prevents this function from working as both struct elements index_size and index are set to 0/null. 2) there's no general way that I can find to obtain the database version, so I just invented a string here. Not having the version creates another problem, as the PECL timezonedb extension will then *always* override the builtin database. The extension uses the version number to see if the extension provides a later rules set. With your patch, this extra check will not work correctly anymore if PHP's built-in version is newer (which would happen if PHP got upgraded). Some other issues: - This patchs allows accessing any file on the filesystem (because the path is not sanitized). - Opening a file is less quick than having the data in memory. - The system's format of tzfiles does not necessarily have to be the same as the one that PHP reads. On my (Debian) system the tz provided data is already 64bit read. Once I update the extension to use this extra data, reading the system tz files won't work anymore. - It would be possible to use a wrong set of tzdata, resulting in bugs like http://bugs.php.net/bug.php?id=35958 The reason to bundle the database is to have a operating system independent source of tzdata, which is something that this patch destroys. I am because of this, and all the other issues, quite against adding this patch - especially because there is already a solution for this. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] date/timelib: use system timezone database
On Wed, 9 Jan 2008, Cristian Rodriguez wrote: 2008/1/9, Ilia Alshanetsky [EMAIL PROTECTED]: The reason we do not use the system database is because it is inconsistent and likely is updated less frequently then the one included with PHP. please consider this patch as an alternative for us !! Why do you need this? There is the PECL timezonedb extension which is updated just as frequently. in anycase, you will probably find this patch included in distros anyway, because this particular feature causes a lot of unnecesary manteniance pain, distributions just update the system timezonedb in regular basis. Yes, and that means bye-bye to support on it. If everybody would patch PHP then how can we every support things? regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] date/timelib: use system timezone database
2008/1/9, Derick Rethans [EMAIL PROTECTED]: Why do you need this? It is simple, even releasing an update for a particular extension, trigger the whole manteniance and QA in distributions, and it unneccesary work , when the system tz is used you have QA and mantain just one component, the timezone package. jfyi: in a complete distribution, there are only 3 components that has this highly questionable behaviuor, Evolution, PHP and JAVA all the other hundred of components do the right thing or at least offer an option just like the Joe's patch. my 2 CLP. -- http://www.kissofjudas.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] date/timelib: use system timezone database
2008/1/9, Ilia Alshanetsky [EMAIL PROTECTED]: The reason we do not use the system database is because it is inconsistent and likely is updated less frequently then the one included with PHP. please consider this patch as an alternative for us !! in anycase, you will probably find this patch included in distros anyway, because this particular feature causes a lot of unnecesary manteniance pain, distributions just update the system timezonedb in regular basis. -- http://www.kissofjudas.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] date/timelib: use system timezone database
On Wed, 9 Jan 2008 17:14:29 -0300, Cristian Rodriguez [EMAIL PROTECTED] wrote: 2008/1/9, Derick Rethans [EMAIL PROTECTED]: Why do you need this? It is simple, even releasing an update for a particular extension, trigger the whole manteniance and QA in distributions, and it unneccesary work , when the system tz is used you have QA and mantain just one component, the timezone package. jfyi: in a complete distribution, there are only 3 components that has this highly questionable behaviuor, Evolution, PHP and JAVA all the other hundred of components do the right thing or at least offer an option just like the Joe's patch. If a PECL module can override PHP's built-in tz database with its own, shouldn't it be possible to write a PECL module that always overrides it and then stubs out to the system tz database? That sounds like an option just like Joe's patch that should work fine. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Set default namespace
Sorry for the ambiguous subject line, but I could not find a better wording for it. Currently, when you use namespaces in PHP, whenever you want to call a function from inside a namespace you must either use the entire name of the namespace (potentially very long) or give it a shorter alias. Here is an example: namespace.inc namespace ProjectA; const WORD = 'foobar'; execute.php use ProjectA as A; print A::WORD; This works out fine. But when I change the two last lines in execute.php to: use ProjectA; print WORD; I get a warning saying The use statement with non-compound name 'ProjectA' has no effect ... and naturally also a notice about using a non-defined constant. So, the default namespace in use, is always global. What about if the default could be changed? It would put to rest the need to always specify the namespace from which to look for the function or class. This would mean that the last example of execute.php would be valid. You could also still access the global space with the following syntax: execute.php const BOOK = 'Two Towers'; use ProjectA; print ::BOOK; Any thoughts on this? Was this sort of approach considered when the namespaces were being implemented? Tomi Kaistila PHP Developer -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] date/timelib: use system timezone database
Hi Ilia, Joe, On Wednesday 09 January 2008 08:50:59 pm Ilia Alshanetsky wrote: The reason we do not use the system database is because it is inconsistent and likely is updated less frequently then the one included with PHP. -1. Personally I think this patch would be great, and I will recommend it to the other debian php maintainers for review. It would certainly be a lot better than our current solution, where the timezone db has been ripped out of php and put into a seperate package which is managed outside of the stable release cycle (in the volatile release area). I understand that it may make the job of developing/releasing/supporting easier for you to bundle the timezone db (just like libgd, et c), but please consider the position of those who are responsible for maintaining not just your software but thousands of other projects' packages... wouldn't it be possible to at least make this some kind of compile-time option for those of us who do like the idea? sean finney (debian php package maintainer) signature.asc Description: This is a digitally signed message part.
[PHP-DEV] CVS Account Request: maddogg
Translating the php5 documentation to Arabic. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
