Re: [PHP-DEV] suggested patch for ext/standard/html.c for correcthtmlentity'ing of cyrillic characters
Go ahead and commit it then..and MFH.. --Jani On Fri, 21 Mar 2003, Wez Furlong wrote: >+1 from me (I will apply it to PHP5). > >This looks like a suitable candidate for 4.3.2 also; no new code is >introduced by this patch, merely a lookup table, and adding more >encodings can be regarded as a fix. > >Opinions? > >--Wez. > >On Fri, 21 Mar 2003, Antony Dovgal wrote: > >> Hello, all. >> >> Attached patch provides cyrillic character sets support to >> htmlentities(), useful for those who wants to see correct cyrillic >> letters after using this function (at this moment htmlentities() >> successfully breaks cyrillic characters). >> KOI8-R, Windows-1251 & CP866 encodings are supported. >> >> I've tested this patch with PHP-CVS & PHP 4.3.2RC1 - it seems to be >> working correctly. >> Someone who has enough karma - please, take a look at it and apply it >> if it's ok. >> >> >> -- >> Wbr, >> Antony Dovgal aka tony2001 mailto:[EMAIL PROTECTED] >> http://phpclub.net >> --- >> Stand for something or you will fall for nothing. >> > > -- <- For Sale! -> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC/RFH : I18N and Unicode support for PHP5 [long]
hello all,
For the last few months or more i've been working on a PHP I18N extension
based on ICU (http://oss.software.ibm.com/icu/) ICU is a huge package, so i
deliberately focused on those areas that are currently lacking in PHP. those
consist of date/time/timezone handling, locales and resource management with
automatic fallback, formatting and parsing (for numbers, dates, messages
etc), and a generic Unicode string class with the usual complement of useful
methods. i deliberately omitted character set transcoding since that is
being capably handled by Moriyoshi and the other folks with the php-i18n
team at Sourceforge Japan [1].
as of now ive implemented 19 of the classes (minus exceptions) [2] and
initial scripts show that they do produce results when suitably appeased ;-)
there is a recent thread started by Nathan Frederickson on multithreading
issues with gettext. the Locale/ResourceBundle and Format classes cover the
same ground, are threadsafe by design, should work the same wherever PHP
compiles.
for an idea of userland interface, just google on Java I18N classes. ICU
also has a Java port, which aims to be JDK compatible, and the C/C++ version
displays this heritage in its class structure and interface.
the extension is ZE2 only, and i have no interest or time to support ZE1.
besides, object overloading is much nicer in ZE2.
how far is it from being complete ? i'd call it pre-pre-alpha. time to beta
is hard to say outside of testing, but it's feature complete for my
intentions. as i mentioned, ICU is huge, so there's lots more goodies to be
had for those with time and energy. im rapidly declining in both.
i've only run small tests and from visual inspection things appear "ok",
which the astute may note is not a software engineering term :-) i'm
experiencing memory errors on shutdown, but a recent newsgroup posting
suggest that they may have something to do with the ZE2/CLI combination. 4
main issues remain
1. testing - especially for the calendar classes. i would imagine these
would be one of the more heavily used components. also the resoure bundle
mechanism needs to be evaluated for thread safety and efficiency. if someone
is interested, i can lay out the exact issues.
2. porting of tools. ICU contains tools which transform Unicode data file
from Unicode.org into efficient binary representations. ive ported two of
them, but there's a few more to go. its not too hard - im just low on time.
3. code cleanup/ review. the project is a mongrel of sorts. i ported the
calendar classes from Java, most other classes from C++, and borrowed some
python code in places. needless to say the coding standard may seem
schizophrenic in places. in addition, not all memory or thread management is
ported over to PHP.
4. porting - the extension compiles and runs fine on Windows-XP. i havent
had the time to investigate porting it to other oses. however, im using
nothing other than my local extension directory, php headers/libs and
libiconv, so there should be no difficulty.
5. testing
my guesstimation is that with 3 people and some outside testing, we can have
a solid beta in about 2 months. or maybe less - my estimates are usually
pessimistic.
im writing to request some assistance in bring this to some stage of
completion, as im sure this would accrue great benefit to PHP's userbase,
provide another checklist item we can put on the back of the PHP5 box at
CompUSA, improve our marketing campaign (PHP -now more buzzword compliant
!!), and end world hunger ;-). then again, this could all be junk..
im especially prompted by the fact that zeev is pushing hard to get a beta
of ZE2 out the door in a very short period. while i dont necessarily think
i/we can make that deadline, this move may be a signal that PHP5 release
date is becoming less indefinite. im also starting a major new initiative at
work that will significantly impact the time i have to devote to this
project.
i'm also in search of webspace to place the archive until its moved to CVS.
my DSL provider is not too bright a web-hoster, so im without a site for the
moment. anyone wanting to have a look, just send an email.
as a final inducement, below is all the code you need to create a localized
"wall-style" calendar for any of the supported locales (including localized
month and day names - long or short)
toUTF8();
$grid = $month["MonthGrid"];
$dayNames = &$table["DayAbbreviations"];
// print out the localized long month name as header
echo("\t\t\t$monthName\n\n");
// print out the localized short day names as column headers
// Notice we use foreach here, since the first element in the list
corresponds
// to the locale's first day of week, which does not always equal 0. This
also
// matches the returned matix layout below
foreach ($dayNames as $name) {
echo str_pad($name->toUTF8(), " ", 4, STR_PAD_BOTH);
echo "\t";
}
echo ("\n");
// print out the "grid". NULL cells represent weekdays that do not fall
within the month,
// just as
[PHP-DEV] Bug #20836
http://bugs.php.net/bug.php?id=20836 Can someone give me sufficient karma to commit the missing documentation or simply apply the patch? - Timm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Test
This is not the e-mail you are looking for... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patch: Some undocumented php.ini directives
I'm not sure what to do with these, but it annoys me that there are directives which don't even appear in php.ini-dist which can actually affect how PHP works. Here's some I've found, but I'm not sure what the policy is. Anyone have a problem with adding these after 4.3.2? Jani: These aren't new directives. They're already there, but no one knows it. ;) See attached for patch. Index: php.ini-dist === RCS file: /repository/php4/php.ini-dist,v retrieving revision 1.186 diff -u -r1.186 php.ini-dist --- php.ini-dist19 Mar 2003 16:53:02 - 1.186 +++ php.ini-dist22 Mar 2003 17:21:53 - @@ -951,6 +951,12 @@ ; Compatability mode with old versions of PHP 3.0. mssql.compatability_mode = Off +; Undocumented +;mssql.connect_timeout = 5 + +; Undocumented +;mssql.timeout = 60 + ; Valid range 0 - 2147483647. Default = 4096. ;mssql.textlimit = 4096 @@ -959,6 +965,9 @@ ; Limits the number of records in each batch. 0 = all records in one batch. ;mssql.batchsize = 0 + +; Undocumented +;mssql.datetimeconvert = On ; Use NT authentication when connecting to the server mssql.secure_connection = Off -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Some undocumented php.ini directives
Hi, Joey Smith wrote: I'm not sure what to do with these, but it annoys me that there are directives which don't even appear in php.ini-dist which can actually affect how PHP works. Here's some I've found, but I'm not sure what the policy is. Anyone have a problem with adding these after 4.3.2? Jani: These aren't new directives. They're already there, but no one knows + +; Undocumented +;mssql.datetimeconvert = On I submitet the patch wich added this param, it just disables the internal datetimeconversion of the mssql-dblib, wich does sometimes weird things. Datetime-values are returned in the format "-MM-DD HH24:MI:SS", if this ini-param is set to off, the default value is on. bye, -- --- - Michael Bretterklieber- [EMAIL PROTECTED] JAWA Management Software GmbH - http://www.jawa.at Liebenauer Hauptstr. 200-- privat --- A-8041 GRAZ GSM: ++43-(0)676-93 96 698 Tel: ++43-(0)316-403274-12 E-mail: [EMAIL PROTECTED] Fax: ++43-(0)316-403274-10 http://www.bretterklieber.com --- - "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Some undocumented php.ini directives
Michael: Thanks for speaking up! I'd be glad to document this with your help. I have a few questions. 1) What is the format when this param is set to on? 2) This parameter doesn't appear to have any effect on the way FreeTDS returns dates from MSSQL. Can you confirm/deny that? On Sat, Mar 22, 2003 at 07:09:33PM +0100, Michael Bretterklieber wrote: > Hi, > > Joey Smith wrote: > >I'm not sure what to do with these, but it annoys me that there are > >directives which don't even appear in php.ini-dist which can actually > >affect how PHP works. Here's some I've found, but I'm not sure what the > >policy is. Anyone have a problem with adding these after 4.3.2? > > > >Jani: These aren't new directives. They're already there, but no one knows > > >+ > >+; Undocumented > >+;mssql.datetimeconvert = On > > > > I submitet the patch wich added this param, it just disables the > internal datetimeconversion of the mssql-dblib, wich does sometimes > weird things. Datetime-values are returned in the format "-MM-DD > HH24:MI:SS", if this ini-param is set to off, the default value is on. > > bye, > -- > --- - > Michael Bretterklieber- [EMAIL PROTECTED] > JAWA Management Software GmbH - http://www.jawa.at > Liebenauer Hauptstr. 200-- privat --- > A-8041 GRAZ GSM: ++43-(0)676-93 96 698 > Tel: ++43-(0)316-403274-12 E-mail: [EMAIL PROTECTED] > Fax: ++43-(0)316-403274-10 http://www.bretterklieber.com > --- - > "...the number of UNIX installations has grown to 10, with more > expected..." - Dennis Ritchie and Ken Thompson, June 1972 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Some undocumented php.ini directives
Hi, Joey Smith wrote: Michael: Thanks for speaking up! I'd be glad to document this with your help. I have a few questions. 1) What is the format when this param is set to on? its a weird format, sometimes I had the date-parts separated with spaces and the time without seconds, I guess it depends on some language settings, or the language of the installed windows. 2) This parameter doesn't appear to have any effect on the way FreeTDS returns dates from MSSQL. Can you confirm/deny that? it also works if you have compiled the MSSQL extension against FreeTDS, but currently there is a bug in the MSSQL extension when FreeTDS is compiled for the sybase-ctlib (wich is the default), wich causes a wrong month-value because the sybase-lib returns the month starting with 0 and the mssql-dblib with 1 (I submited already a patch for that to Frank M. Kromann). But I don't know the standard format of FreeTDS when converting datetime-values. However, I also saw a lot of bug-reports related this problem (weird datetime-values), it would be good to write in the docu, that this switch is a workaround for that problem. bye, -- --- - Michael Bretterklieber- [EMAIL PROTECTED] JAWA Management Software GmbH - http://www.jawa.at Liebenauer Hauptstr. 200-- privat --- A-8041 GRAZ GSM: ++43-(0)676-93 96 698 Tel: ++43-(0)316-403274-12 E-mail: [EMAIL PROTECTED] Fax: ++43-(0)316-403274-10 http://www.bretterklieber.com --- - "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] default exceptions, interfaces, etc.
Hi,
Attached is a patch (+ 2 files) that add a default "exception" class to
Zend 2. I find this very useful when you just want to throw a simple
exception inside of a try {}, but you don't want to create a new
exception for each and every error. I'll commit this tommorowish,
unless somebody objects.
-Sterling
--
"Whether you think you can or think you can't -- you are right."
- Henry Ford
Index: Makefile.am
===
RCS file: /repository/ZendEngine2/Makefile.am,v
retrieving revision 1.51
diff -u -r1.51 Makefile.am
--- Makefile.am 17 Mar 2003 11:23:42 - 1.51
+++ Makefile.am 22 Mar 2003 21:13:12 -
@@ -14,7 +14,7 @@
zend_variables.c zend.c zend_API.c zend_extensions.c zend_hash.c \
zend_list.c zend_indent.c zend_builtin_functions.c zend_sprintf.c \
zend_ini.c zend_qsort.c zend_objects.c zend_object_handlers.c \
- zend_objects_API.c zend_ts_hash.c zend_stream.c zend_mm.c
+ zend_objects_API.c zend_ts_hash.c zend_stream.c zend_mm.c zend_default_interfaces.c
libZend_la_LDFLAGS =
libZend_la_LIBADD = @ZEND_EXTRA_LIBS@
Index: zend.c
===
RCS file: /repository/ZendEngine2/zend.c,v
retrieving revision 1.214
diff -u -r1.214 zend.c
--- zend.c 2 Mar 2003 10:04:53 - 1.214
+++ zend.c 22 Mar 2003 21:13:14 -
@@ -25,6 +25,7 @@
#include "zend_constants.h"
#include "zend_list.h"
#include "zend_API.h"
+#include "zend_default_interfaces.h"
#include "zend_builtin_functions.h"
#include "zend_ini.h"
@@ -609,6 +610,7 @@
if (start_builtin_functions) {
zend_startup_builtin_functions(TSRMLS_C);
}
+ zend_register_default_interfaces(TSRMLS_C);
zend_ini_startup(TSRMLS_C);
/*
+--+
| Zend Engine |
+--+
| Copyright (c) 1998-2003 Zend Technologies Ltd. (http://www.zend.com) |
+--+
| This source file is subject to version 2.00 of the Zend license, |
| that is bundled with this package in the file LICENSE, and is|
| available at through the world-wide-web at |
| http://www.zend.com/license/2_00.txt.|
| If you did not receive a copy of the Zend license and are unable to |
| obtain it through the world-wide-web, please send a note to |
| [EMAIL PROTECTED] so we can mail you a copy immediately. |
+--+
| Authors: Sterling Hughes <[EMAIL PROTECTED]> |
+--+
*/
/* $Id: $ */
#include "zend.h"
#include "zend_API.h"
zend_class_entry *default_exception_ptr;
ZEND_FUNCTION(exception)
{
zval **message;
zval **code;
zval *object;
intargc = ZEND_NUM_ARGS();
if (zend_get_parameters_ex(argc, &message, &code) == FAILURE) {
ZEND_WRONG_PARAM_COUNT();
}
object = getThis();
if (argc > 0) {
convert_to_string_ex(message);
zval_add_ref(message);
zend_hash_update(Z_OBJPROP_P(object), "message", sizeof("message"), (void **) message, sizeof(zval *), NULL);
}
if (argc > 1) {
convert_to_long_ex(code);
zval_add_ref(code);
zend_hash_update(Z_OBJPROP_P(object), "code", sizeof("code"), (void **) code, sizeof(zval *), NULL);
}
}
ZEND_FUNCTION(getmessage)
{
zval **message;
zval *object;
if (ZEND_NUM_ARGS() > 0) {
ZEND_WRONG_PARAM_COUNT();
}
object = getThis();
if (zend_hash_find(Z_OBJPROP_P(object), "message", sizeof("message"), (void **) &message) == FAILURE) {
RETURN_FALSE;
}
*return_value = **message;
zval_copy_ctor(return_value);
}
ZEND_FUNCTION(getcode)
{
zval **code;
zval *object;
if (ZEND_NUM_ARGS() > 0) {
ZEND_WRONG_PARAM_COUNT();
}
object = getThis();
if (zend_hash_find(Z_OBJPROP_P(object), "code", sizeof("code"), (void **) &code) == FAILURE) {
RETURN_FALSE;
}
*return_value = **code;
zval_copy_ctor(return_value);
}
static zend_function_entry default_exception_functions[] = {
ZEND_FE(exception, NULL)
ZEND_FE(getmessage, NULL)
ZEND_FE(getcode, NULL)
{NULL, NULL, NULL}
};
static void zend_register_default_exception(TSRMLS_C)
{
zend_class_entry default_exception;
INIT_CLASS_ENTRY(default_exception, "exception", default_exception_functions);
default_exception_ptr = zend_register_internal_class(&default_exception TSRMLS_CC);
}
ZEND_API void zend_register_default_interfaces(TSRMLS_D)
{
zend_register_default_exception(TSRMLS_CC);
}
/*
* Local variables:
* tab-width: 4
* c-basic-offset: 4
* indent-tabs-mode: t
* End:
*/
/*
+--+
| Zend Engine
[PHP-DEV] win32 dev build broken
Compiling resources... Compiling... php_cli.c Linking... php_cli.obj : error LNK2001: unresolved external symbol _zend_is_auto_global ..\Release_TS_inline\cli\php.exe : fatal error LNK1120: 1 unresolved externals Error executing link.exe. The attached patch is a trivial fix for the compile failure. Could anyone who has ZE2 karma apply this one? Moriyoshi Index: Zend/zend_compile.h === RCS file: /repository/ZendEngine2/zend_compile.h,v retrieving revision 1.225 diff -u -r1.225 zend_compile.h --- Zend/zend_compile.h 19 Mar 2003 21:17:47 - 1.225 +++ Zend/zend_compile.h 22 Mar 2003 23:03:38 - @@ -477,8 +477,8 @@ } zend_auto_global; void zend_auto_global_dtor(zend_auto_global *auto_global); -int zend_register_auto_global(char *name, uint name_len, zend_auto_global_callback auto_global_callback TSRMLS_DC); -zend_bool zend_is_auto_global(char *name, uint name_len TSRMLS_DC); +ZEND_API int zend_register_auto_global(char *name, uint name_len, zend_auto_global_callback auto_global_callback TSRMLS_DC); +ZEND_API zend_bool zend_is_auto_global(char *name, uint name_len TSRMLS_DC); int zendlex(znode *zendlval TSRMLS_DC); -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] win32 dev build broken
I've been compiling all day with no problem. I'll do a clean build and make sure about that. Shane Moriyoshi Koizumi wrote: Compiling resources... Compiling... php_cli.c Linking... php_cli.obj : error LNK2001: unresolved external symbol _zend_is_auto_global ..\Release_TS_inline\cli\php.exe : fatal error LNK1120: 1 unresolved externals Error executing link.exe. The attached patch is a trivial fix for the compile failure. Could anyone who has ZE2 karma apply this one? Moriyoshi Index: Zend/zend_compile.h === RCS file: /repository/ZendEngine2/zend_compile.h,v retrieving revision 1.225 diff -u -r1.225 zend_compile.h --- Zend/zend_compile.h 19 Mar 2003 21:17:47 - 1.225 +++ Zend/zend_compile.h 22 Mar 2003 23:03:38 - @@ -477,8 +477,8 @@ } zend_auto_global; void zend_auto_global_dtor(zend_auto_global *auto_global); -int zend_register_auto_global(char *name, uint name_len, zend_auto_global_callback auto_global_callback TSRMLS_DC); -zend_bool zend_is_auto_global(char *name, uint name_len TSRMLS_DC); +ZEND_API int zend_register_auto_global(char *name, uint name_len, zend_auto_global_callback auto_global_callback TSRMLS_DC); +ZEND_API zend_bool zend_is_auto_global(char *name, uint name_len TSRMLS_DC); int zendlex(znode *zendlval TSRMLS_DC); -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] win32 dev build broken
The log was actually taken from snaps.php.net, and I also experienced that linker error with my VC7. Is it likely that I'm missing something? Moriyoshi Shane Caraveo <[EMAIL PROTECTED]> wrote: > I've been compiling all day with no problem. I'll do a clean build and > make sure about that. > Shane > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] win32 dev build broken
You didn't miss anything, I did. I've been working with cgi today, and failed to notice you were using cli. I'll take care of it in a moment. Shane Moriyoshi Koizumi wrote: The log was actually taken from snaps.php.net, and I also experienced that linker error with my VC7. Is it likely that I'm missing something? Moriyoshi Shane Caraveo <[EMAIL PROTECTED]> wrote: I've been compiling all day with no problem. I'll do a clean build and make sure about that. Shane -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Fields of extended class not instatiated
This code run in current code (HEAD):
class Foo {
var $arr = array();
}
class FooX extends Foo {
function bar()
{
var_dump($this->arr);
}
}
$foo = new FooX();
$foo->bar();
produces "NULL" as the output. I guess this is not the intended behaviour?
Jan.
--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] default exceptions, interfaces, etc.
Hi,
As per naming convention, I think it'd be nice if the methods were
named as:
getmessage => get_message
getcode => get_code
If those are corrected, +1 for this feature.
Moriyoshi
Sterling Hughes <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Attached is a patch (+ 2 files) that add a default "exception" class to
> Zend 2. I find this very useful when you just want to throw a simple
> exception inside of a try {}, but you don't want to create a new
> exception for each and every error. I'll commit this tommorowish,
> unless somebody objects.
>
> -Sterling
> --
> "Whether you think you can or think you can't -- you are right."
> - Henry Ford
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] default exceptions, interfaces, etc.
On Sat, 2003-03-22 at 19:02, Moriyoshi Koizumi wrote:
> Hi,
>
> As per naming convention, I think it'd be nice if the methods were
> named as:
>
> getmessage => get_message
> getcode => get_code
>
> If those are corrected, +1 for this feature.
>
I was thinking of that - I would personally prefer get_message() and
get_code() naming, but that goes against pear's naming conventions, and
I want this to integrate well with pear (as a base class.)
-Sterling
> Moriyoshi
>
> Sterling Hughes <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > Attached is a patch (+ 2 files) that add a default "exception" class to
> > Zend 2. I find this very useful when you just want to throw a simple
> > exception inside of a try {}, but you don't want to create a new
> > exception for each and every error. I'll commit this tommorowish,
> > unless somebody objects.
> >
> > -Sterling
> > --
> > "Whether you think you can or think you can't -- you are right."
> > - Henry Ford
--
"People can have the Model T in any colour -- so long as it's black."
- Henry Ford
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] default exceptions, interfaces, etc.
Okay, then I see the issue and no problem with the patch. +1. Moriyoshi Sterling Hughes <[EMAIL PROTECTED]> wrote: > On Sat, 2003-03-22 at 19:02, Moriyoshi Koizumi wrote: > > Hi, > > > > As per naming convention, I think it'd be nice if the methods were > > named as: > > > > getmessage => get_message > > getcode => get_code > > > > If those are corrected, +1 for this feature. > > > > I was thinking of that - I would personally prefer get_message() and > get_code() naming, but that goes against pear's naming conventions, and > I want this to integrate well with pear (as a base class.) > > -Sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fields of extended class not instatiated
Should be fixed now. Thanks for the test case!
Zeev
At 17:43 22/03/2003, Jan Schneider wrote:
This code run in current code (HEAD):
class Foo {
var $arr = array();
}
class FooX extends Foo {
function bar()
{
var_dump($this->arr);
}
}
$foo = new FooX();
$foo->bar();
produces "NULL" as the output. I guess this is not the intended behaviour?
Jan.
--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft
--
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-DEV] updating apache module name
Hi, Since we're all working on php5-dev now, i think its time to update the apache module name of php to php5_module or php_module (I'm for the latter). I'll go ahead and do this tommorow unless someone objects. -Sterling -- "Whether you think you can or think you can't -- you are right." - Henry Ford -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] updating apache module name
Sterling Hughes wrote: Hi, Since we're all working on php5-dev now, i think its time to update the apache module name of php to php5_module or php_module (I'm for the latter). I'll go ahead and do this tommorow unless someone objects. -Sterling This should be done for everything I think (such as the windows builds). Shane -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] updating apache module name
On Sat, 2003-03-22 at 19:42, Shane Caraveo wrote: > Sterling Hughes wrote: > > Hi, > > > > Since we're all working on php5-dev now, i think its time to update the > > apache module name of php to php5_module or php_module (I'm for the > > latter). > > > > I'll go ahead and do this tommorow unless someone objects. > > > > -Sterling > > > > This should be done for everything I think (such as the windows builds). I agree, but I can't really test with anything else but apache+linux/bsd. -Sterling > Shane -- "I can't give you a brain, so I'll give you a diploma" - The Great Oz, The Wizard of Oz -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] updating apache module name
On 22 Mar 2003, Sterling Hughes wrote: >Hi, > >Since we're all working on php5-dev now, i think its time to update the >apache module name of php to php5_module or php_module (I'm for the >latter). Make it php5_module. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] default exceptions, interfaces, etc.
At 00:43 23.03.2003, Sterling Hughes wrote: On Sat, 2003-03-22 at 19:02, Moriyoshi Koizumi wrote: > Hi, > > As per naming convention, I think it'd be nice if the methods were > named as: > > getmessage => get_message > getcode => get_code > > If those are corrected, +1 for this feature. > I was thinking of that - I would personally prefer get_message() and get_code() naming, but that goes against pear's naming conventions, and I want this to integrate well with pear (as a base class.) I agree with moriyoshi here. If pear has a problem with that - than please change pear and do not add more inconsistent featrures instead. The exception class itself was not only once requested. Another point however is the function name zend_register_default_interfaces() in the C code. Since we have interfaces and you do not register an interface with that function you are missleading here so please name that function something like zend_register_default_exceptions() and change the filenames to contain the word exception instead of interfaces. regards marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] default exceptions, interfaces, etc.
On Sun, 22 Mar 2003, Sterling Hughes wrote: > On Sat, 2003-03-22 at 19:02, Moriyoshi Koizumi wrote: > > Hi, > > > > As per naming convention, I think it'd be nice if the methods were > > named as: > > > > getmessage => get_message > > getcode => get_code > > > > If those are corrected, +1 for this feature. > > > > I was thinking of that - I would personally prefer get_message() and > get_code() naming, but that goes against pear's naming conventions, and > I want this to integrate well with pear (as a base class.) It's a PHP function, not PEAR code, so it should follow the PHP naming style. Derick -- "my other box is your windows PC" - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] default exceptions, interfaces, etc.
On Sat, 2003-03-22 at 21:14, Marcus Börger wrote: > At 00:43 23.03.2003, Sterling Hughes wrote: > >On Sat, 2003-03-22 at 19:02, Moriyoshi Koizumi wrote: > > > Hi, > > > > > > As per naming convention, I think it'd be nice if the methods were > > > named as: > > > > > > getmessage => get_message > > > getcode => get_code > > > > > > If those are corrected, +1 for this feature. > > > > > > >I was thinking of that - I would personally prefer get_message() and > >get_code() naming, but that goes against pear's naming conventions, and > >I want this to integrate well with pear (as a base class.) > > > I agree with moriyoshi here. If pear has a problem with that - than please > change > pear and do not add more inconsistent featrures instead. The exception class > itself was not only once requested. > Well, Moriyoshi agreed with me, once he understood the rationale. So, its only you. :) As for inconsistency, PEAR is the standard for OO php code, and studlyCaps are a part of their standards. PHP standards exist for procedural code, which is a different beast. > Another point however is the function name zend_register_default_interfaces() > in the C code. Since we have interfaces and you do not register an > interface with > that function you are missleading here so please name that function something > like zend_register_default_exceptions() and change the filenames to contain the > word exception instead of interfaces. > No, you misunderstand the purpose. The idea of this file is to add any standard classes, interfaces, etc. Exception just happens to be the first practical example. -Sterling > regards > marcus -- "Reductionists like to take things apart. The rest of us are just trying to get it together." - Larry Wall, Programming Perl, 3rd Edition -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] default exceptions, interfaces, etc.
On Sat, 2003-03-22 at 21:33, Derick Rethans wrote: > On Sun, 22 Mar 2003, Sterling Hughes wrote: > > > On Sat, 2003-03-22 at 19:02, Moriyoshi Koizumi wrote: > > > Hi, > > > > > > As per naming convention, I think it'd be nice if the methods were > > > named as: > > > > > > getmessage => get_message > > > getcode => get_code > > > > > > If those are corrected, +1 for this feature. > > > > > > > I was thinking of that - I would personally prefer get_message() and > > get_code() naming, but that goes against pear's naming conventions, and > > I want this to integrate well with pear (as a base class.) > > It's a PHP function, not PEAR code, so it should follow the PHP naming > style. > As I mentioned to Marcus, there are no naming conventions for OO code, only procedural code (in PHP). Also, compliance with PEAR is a pragmatic solution, because presumably all their code will be inheriting from Exception. The largest, and the official OO library should be in-sync with standard practices (and we have none yet regarding OO code.) -Sterling > Derick -- "A business that makes nothing but money is a poor kind of business." - Henry Ford -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] default exceptions, interfaces, etc.
On 22 Mar 2003, Sterling Hughes wrote: >On Sat, 2003-03-22 at 21:33, Derick Rethans wrote: >> On Sun, 22 Mar 2003, Sterling Hughes wrote: >> >> > On Sat, 2003-03-22 at 19:02, Moriyoshi Koizumi wrote: >> > > Hi, >> > > >> > > As per naming convention, I think it'd be nice if the methods were >> > > named as: >> > > >> > > getmessage => get_message >> > > getcode => get_code >> > > >> > > If those are corrected, +1 for this feature. >> > > >> > >> > I was thinking of that - I would personally prefer get_message() and >> > get_code() naming, but that goes against pear's naming conventions, and >> > I want this to integrate well with pear (as a base class.) >> >> It's a PHP function, not PEAR code, so it should follow the PHP naming >> style. >> > >As I mentioned to Marcus, there are no naming conventions for OO code, >only procedural code (in PHP). Also, compliance with PEAR is a >pragmatic solution, because presumably all their code will be inheriting >from Exception. The largest, and the official OO library should be >in-sync with standard practices (and we have none yet regarding OO >code.) Even if we don't have specific rules (yet) for OO stuff, IMO, it should follow the existing rules. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: default exceptions, interfaces, etc.
Sterling, have you thought of public accessors (maybe even macros) for exception properties. this is for the benefit of extension authors who want to subclass. right now i have to basically copy the code for the constructor to my new class, or resort using call_user_function_ex. for my extension classes i usually do something like this : int myclass_init_zval(zval *return_val,int foo, char *bar, void *etc); /* create a myclass obj stored in return_val */ and put it in the header so i can create an instance of the class from anywhere i need to. the constructor function also calls this. another idea is basic macros /* set up the common properties. subclasses can add others. also set EG(exception) to return_zval if not set */ ZEND_RAISE_EXCEPTION_EX(return_zval, exception_or_subclass_ce, code, message, ...) /* for extension authors to handle exceptions in C */ ZEND_LOWER_EXCEPTION() /* just to be less arcane */ ZEND_HAS_EXCEPTION() (NULL != EG(exception)) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / Makefile.am zend.c zend_default_classes.czend_default_classes.h php4 configure.in
Sterling Hughes wrote: > Log: > add a standard Exception class. Could you please also add a standard Throwable interface and make Exception implement it? Thank you, Sebastian -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: default exceptions, interfaces, etc.
Sterling, another issue - im writing a shared extension, so simply declaring default_exception_ptr as extern does'nt work. we need some way to export it so subclassing works... l0t3k (arent you sorry you stat\rted this mess ? ;-)) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: default exceptions, interfaces, etc.
ah, forget it. i just took a look at the usage of zend_register_internal_class_ex (parameter 3) note to self: Use the source, Luke ! - Original Message - From: "l0t3k" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, March 23, 2003 2:52 AM Subject: Re: default exceptions, interfaces, etc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
