[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Type hintsrevisited [IllegalArgumentException instead of E_ERROR]
On Sat, 2003-03-29 at 12:59, Zeev Suraski wrote: > Remember that we don't want to encourage exception based programming anyway. > Catching an exception should typically be the last thing done in a program, > right before it terminates. Writing exception-driven applications is > extremely discouraged. What is the rationale behind this? -- Best regards, Per Lundberg / Capio ApS Phone: +46-18-4186040 Fax: +46-18-4186049 Web: http://www.capio.com signature.asc Description: This is a digitally signed message part
[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Missing P in PPP as in package?!
On Sat, 2003-03-29 at 02:56, Preston L. Bannister wrote: > PHP is not Java - and for good reason. PHP is a rather nice scripting > language. PHP scripts are loaded and run for /each and every /request. Your whole argumentation is based on this assumption, that PHP *only* is used for writing web scripts. This is a faulty assumption. PHP is already used for writing stand-alone applications (think PHP-GTK and the CLI SAPI), and this is likely to increase in the future because of the improvements in the OOP support in PHP 5. I totally agree a 100% that a quick little web script don't really need OOP. But PHP, or rather, the Zend Engine 2, is not limited to only web scripting. It can be used for so much more, and that needs to be taken into consideration when discussing these things. -- Best regards, Per Lundberg / Capio ApS Phone: +46-18-4186040 Fax: +46-18-4186049 Web: http://www.capio.com signature.asc Description: This is a digitally signed message part
[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Type hints revisited [IllegalArgumentException instead of E_ERROR]
At 11:35 31/03/2003, Per Lundberg wrote: On Sat, 2003-03-29 at 12:59, Zeev Suraski wrote: > Remember that we don't want to encourage exception based programming anyway. > Catching an exception should typically be the last thing done in a program, > right before it terminates. Writing exception-driven applications is > extremely discouraged. What is the rationale behind this? (a) This is very much the case for all languages that have exceptions. Exception handling is *slow*. Coding exception-driven apps in Java and C++ is a bad idea too. Exceptions were designed to handle errors, and not provide some nifty way of shifting control from one place to another. (b) In PHP, exception handling results in memory leaks. Like all leaks in PHP, they'd be taken care of at the end of the request. Until the end of the request, however, certain chunks of memory will not be reclaimed. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Type hintsrevisited [IllegalArgumentException instead of E_ERROR]
On Mon, 2003-03-31 at 10:53, Zeev Suraski wrote:
> At 11:35 31/03/2003, Per Lundberg wrote:
> >On Sat, 2003-03-29 at 12:59, Zeev Suraski wrote:
> > > Writing exception-driven applications is extremely discouraged.
> >What is the rationale behind this?
> (a) This is very much the case for all languages that have
> exceptions. Exception handling is *slow*. Coding exception-driven apps in
> Java and C++ is a bad idea too. Exceptions were designed to handle errors,
> and not provide some nifty way of shifting control from one place to another.
I agree. But is it a problem if error handling is slow? I mean,
errors are not the normal flow of the application, and need not be
optimized as such.
If it slows down the code too much even when the exception is not
thrown, I can agree with your reasoning. And yes, there are certainly
cases where exceptions are being used when not really neccessary.
> (b) In PHP, exception handling results in memory leaks. Like all leaks in
> PHP, they'd be taken care of at the end of the request. Until the end of
> the request, however, certain chunks of memory will not be reclaimed.
This could turn out to be a big problem for people developing non-web
applications with PHP, applications running for a long time. Why do
exception handling leak? Would it be impossible/very hard to fix this
behavior?
Another thing that just hit me: it would be incredibly useful to do like
this:
try {
eval($string);
}
catch (FatalErrorException $e) {
// handle the error.
}
Imagine the scenario with a standalone application loading in some
script from the user's home directory. It would really be very bad if
the application just died here; it would limit the usability of the Zend
Engine for such an application a lot.
Yes, eval could be changed to return an error code, but that would
slightly break BC since the eval is to return the return()-value from
the eval()'ed code.
Do you agree that exceptions would be very convenient for this kind of
code/situation?
--
Best regards,
Per Lundberg / Capio ApS
Phone: +46-18-4186040
Fax: +46-18-4186049
Web: http://www.capio.com
signature.asc
Description: This is a digitally signed message part
Re: [PHP-DEV] Re: [Zend Engine 2] Type hints revisited [IllegalArgumentException instead of E_ERROR]
How does this differ from the return values of functions using WRONG_PARAM_COUNT and zend_parse_parameters()? --Wez On Sat, 29 Mar 2003, Zeev Suraski wrote: > At 16:23 29/03/2003, Timm Friebe wrote: > >On Sat, 2003-03-29 at 13:10, Zeev Suraski wrote: > >[...] > > > >After reading through a bunch of mails this generated, I get the idea > > > >that most people here would be happier with an E_WARNING and the > > > >function not being executed. > > > > > > ?! > > > > > > How the heck can we even think about such a thing? When you call a > > > function, you expect it to run. The code that follows it may rely on > > stuff > > > that it has done. Not running it is simply not an option, I can't even > > > begin to imagine the possible consequences of such an approach! > > > >Well, at the moment, the function is not run either, isn't it? The > >program dies. > > Right. Code assuming that it ran successfully is therefore never > reached. That is fundamentally different from just not running the > function and returning control to the caller. That's *extremely* dangerous. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Type hints revisited [IllegalArgumentExceptioninstead of E_ERROR]
Type hinting, if it causes a bail-out, renders the scripts non-portable to (the growing number of) applications that intend to stick around for longer than a short web-request. So yes, I'd be happier without anyone having type hints than having type hints E_ERROR. (which is inconsistent with all of the other parameter checking macros and functions already in use in PHP). --Wez. On Sun, 30 Mar 2003, Stanislav Malyshev wrote: > DR>> > Just to be clear: I'd be happier without type hinting then type hinting > DR>> > throwing an E_ERROR (a E_WARNING would also make me happy). > DR>> > DR>> I agree 100% here. > > If so, what on the Earth prevents you from not using type hinting and > being happy? Or you want to say you would be better without _others_ using > type hinting than _others_ using it with E_ERROR? That's one strange point > of view then :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Type hints revisited [IllegalArgumentExceptioninstead of E_ERROR]
WF>> Type hinting, if it causes a bail-out, renders the scripts WF>> non-portable to (the growing number of) applications that intend to WF>> stick around for longer than a short web-request. Well, I do not completely understand how it is "non-portable". If the script calls "hinted" function with wrong parameters, it is a fatal error - I see no sane (meaning, safe not for your particular application, but for all of them) way to continue from here except for saying the user "Well, doh!" and exiting. That's like calling function with wrong name - how can you continue from there and expect it works? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] magic_quotes_sybase and php_stripslashes
could some1 explain the first if here (php_stripslashes:cybase mode) http://lxr.php.net/source/php4/ext/standard/string.c#2324 that have nothing with slashes but with quotes? could this if be removed safely? tnx moshe. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Type hints revisited [IllegalArgumentExceptioninstead of E_ERROR]
You can use function_exists() to avoid a fatal error, but there is no equivalent function_parameters_are_ok() API to avoid a miserable death in the situations that I have already mentioned. Why not just be consistent with all the other parameter checks and raise an E_WARNING and RETURN_NULL when the parameters are incorrect? I don't see what is so special about hinted parameters that they have to bail out the engine, while the built-in (and extension) functions will happily return NULL and continue execution. --Wez. On Mon, 31 Mar 2003, Stanislav Malyshev wrote: > WF>> Type hinting, if it causes a bail-out, renders the scripts > WF>> non-portable to (the growing number of) applications that intend to > WF>> stick around for longer than a short web-request. > > Well, I do not completely understand how it is "non-portable". If the > script calls "hinted" function with wrong parameters, it is a fatal error > - I see no sane (meaning, safe not for your particular application, but > for all of them) way to continue from here except for saying the user > "Well, doh!" and exiting. That's like calling function with wrong name - > how can you continue from there and expect it works? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Type hints revisited [IllegalArgumentExceptioninstead of E_ERROR]
On Mon, 31 Mar 2003, Wez Furlong wrote: > You can use function_exists() to avoid a fatal error, but there is no > equivalent function_parameters_are_ok() API to avoid a miserable death > in the situations that I have already mentioned. > > Why not just be consistent with all the other parameter checks and raise > an E_WARNING and RETURN_NULL when the parameters are incorrect? > I don't see what is so special about hinted parameters that they have to > bail out the engine, while the built-in (and extension) functions will > happily return NULL and continue execution. Sounds logical to me too... 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] Re: Type hints revisited [IllegalArgumentExceptioninstead of E_ERROR]
WF>> I don't see what is so special about hinted parameters that they have to WF>> bail out the engine, while the built-in (and extension) functions will WF>> happily return NULL and continue execution. The functions that are built-in have defined behaviour of returning NULL in case of error (if they do not and they still return NULL as error - that's a serious bug). However, this is not true for each and every function out there. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Type hints revisited [IllegalArgumentException instead of E_ERROR]
At 15:55 31/03/2003, Wez Furlong wrote: You can use function_exists() to avoid a fatal error, but there is no equivalent function_parameters_are_ok() API to avoid a miserable death in the situations that I have already mentioned. Why not just be consistent with all the other parameter checks and raise an E_WARNING and RETURN_NULL when the parameters are incorrect? I don't see what is so special about hinted parameters that they have to bail out the engine, while the built-in (and extension) functions will happily return NULL and continue execution. I see a huge difference. First off, most functions don't return NULL or even bail out at all, they just convert their argument as necessary and try to make do. Secondly, I see a big difference between built-in functions and userland functions. With userland functions, I think there's a very high WTF factor for them returning without actually running their code. I don't think that this WTF factor exists for built-in functions, as they are perceived as black-boxes. Returning NULL works well in case your function has a meaningful return value, such a result set, SQL link, a string or what not. It's not that useful when your function is returning nothing, or when it has a return value that's not likely to be checked. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] magic_quotes_sybase and php_stripslashes
On Mon, Mar 31, 2003 at 03:45:13PM +0200, moshe doron wrote: > could some1 explain the first if here (php_stripslashes:cybase mode) > http://lxr.php.net/source/php4/ext/standard/string.c#2324 > that have nothing with slashes but with quotes? Sybase escapes ' with '' and NUL with \0 so we needed a special version of php_stripslashes(). Sander > > could this if be removed safely? > > tnx > moshe. > > > > -- > 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: Type hints revisited [IllegalArgumentExceptioninstead of E_ERROR]
IMO, both built-in and user-land functions should be equally black box. Please don't have it bail out unless there is some kind of function_parameters_are_ok() API so that careful programmers can work around this issue. --Wez. On Mon, 31 Mar 2003, Zeev Suraski wrote: > At 15:55 31/03/2003, Wez Furlong wrote: > >You can use function_exists() to avoid a fatal error, but there is no > >equivalent function_parameters_are_ok() API to avoid a miserable death > >in the situations that I have already mentioned. > > > >Why not just be consistent with all the other parameter checks and raise > >an E_WARNING and RETURN_NULL when the parameters are incorrect? > >I don't see what is so special about hinted parameters that they have to > >bail out the engine, while the built-in (and extension) functions will > >happily return NULL and continue execution. > > I see a huge difference. First off, most functions don't return NULL or > even bail out at all, they just convert their argument as necessary and try > to make do. Secondly, I see a big difference between built-in functions > and userland functions. With userland functions, I think there's a very > high WTF factor for them returning without actually running their code. I > don't think that this WTF factor exists for built-in functions, as they are > perceived as black-boxes. Returning NULL works well in case your function > has a meaningful return value, such a result set, SQL link, a string or > what not. It's not that useful when your function is returning nothing, or > when it has a return value that's not likely to be checked. > > Zeev > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Type hints revisited [IllegalArgumentExceptioninstead of E_ERROR]
WF>> Please don't have it bail out unless there is some kind of WF>> function_parameters_are_ok() API so that careful programmers can work WF>> around this issue. Careful programmers should know interface of called functions and never call them with parameters that do not match the interface. :) -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Type hints revisited [IllegalArgumentExceptioninstead of E_ERROR]
Yes, but when using call_user_function, __call(), and RPC servers, you don't always know what function you are calling at the time you write the script. Thats where is_callable()/function_exists() are extremely useful. --Wez. On Mon, 31 Mar 2003, Stanislav Malyshev wrote: > WF>> Please don't have it bail out unless there is some kind of > WF>> function_parameters_are_ok() API so that careful programmers can work > WF>> around this issue. > > Careful programmers should know interface of called functions and never > call them with parameters that do not match the interface. :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] magic_quotes_sybase and php_stripslashes
Heh..so magic_quotes_sybase ini setting affects how stripslashes() function works too? Pretty high WTF factor there. It should be an additional option for php_stripslashes() that is passed where appropriate. --Jani On Mon, 31 Mar 2003, Sander Roobol wrote: >On Mon, Mar 31, 2003 at 03:45:13PM +0200, moshe doron wrote: >> could some1 explain the first if here (php_stripslashes:cybase mode) >> http://lxr.php.net/source/php4/ext/standard/string.c#2324 >> that have nothing with slashes but with quotes? > >Sybase escapes ' with '' and NUL with \0 so we needed a special >version of php_stripslashes(). > >Sander > >> >> could this if be removed safely? >> >> tnx >> moshe. >> >> >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > > -- <- For Sale! -> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] magic_quotes_sybase and php_stripslashes
Quoting Jani Taskinen <[EMAIL PROTECTED]>: > Heh..so magic_quotes_sybase ini setting affects how stripslashes() > function works too? Pretty high WTF factor there. It should be > an additional option for php_stripslashes() that is passed where > appropriate. As long as it affects addslashes() it should also affect stripslashes(). The WTF factor would be even higher else. > On Mon, 31 Mar 2003, Sander Roobol wrote: > > >On Mon, Mar 31, 2003 at 03:45:13PM +0200, moshe doron wrote: > >> could some1 explain the first if here (php_stripslashes:cybase mode) > >> http://lxr.php.net/source/php4/ext/standard/string.c#2324 > >> that have nothing with slashes but with quotes? > > > >Sybase escapes ' with '' and NUL with \0 so we needed a special > >version of php_stripslashes(). > > > >Sander > > > >> > >> could this if be removed safely? 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] magic_quotes_sybase and php_stripslashes
"Sander Roobol" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Mon, Mar 31, 2003 at 03:45:13PM +0200, moshe doron wrote: > > could some1 explain the first if here (php_stripslashes:cybase mode) > > http://lxr.php.net/source/php4/ext/standard/string.c#2324 > > that have nothing with slashes but with quotes? > > Sybase escapes ' with '' and NUL with \0 so we needed a special > version of php_stripslashes(). ok stupid me, i didn't realized that php_*slashes are just intended to deal with magic mode. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] magic_quotes_sybase and php_stripslashes
there is one more problem just like the
http://bugs.php.net/bug.php?id=22904 bug
the problem is also for 'regular' magic mode.
the addslashes add slashes anly when the slash follow by '\'' or '\"' or
'\\' but on stripslashes it's nuke all the slashes without considering whats
came after that.
here is 'first shoot' fix for both bugs (i didn't even compiled it) hope
i'll time to debug it and write test tomorrow
Index: string.c
===
RCS file: /repository/php4/ext/standard/string.c,v
retrieving revision 1.365
diff -u -r1.365 string.c
--- string.c 31 Mar 2003 12:08:31 - 1.365
+++ string.c 31 Mar 2003 15:36:28 -
@@ -2322,8 +2322,9 @@
if (PG(magic_quotes_sybase)) {
while (l > 0) {
+ l--;
if (*t == '\'') {
-if ((l > 0) && (t[1] == '\'')) {
+if ((l >= 0) && (t[1] == '\'')) {
t++;
if (len != NULL) {
(*len)--;
@@ -2331,17 +2332,24 @@
l--;
}
*s++ = *t++;
- } else if (*t == '\\' && l > 0 && t[1] == '0') {
+ } else if (*t == '\\' && l > 0) {
+t++;
+if (*t == '0') {
*s++='\0';
- t += 2;
- if (len != NULL) {
- (*len)--;
- }
- l--;
+ t++;
+} else if (*s=='\\'){
+ *s++ = *t++;
+}else{
+ *s++; = '\\';
+ continue;
+}
+l--;
+if (len != NULL) {
+ (*len)--;
+}
} else {
*s++ = *t++;
}
- l--;
}
*s = '\0';
@@ -2349,29 +2357,28 @@
}
while (l > 0) {
- if (*t == '\\') {
- t++;/* skip the slash */
- if (len != NULL) {
-(*len)--;
+ l--;
+ if (*t == '\\' && l > 0) {
+ t++;
+ if (*t == '0') {
+*s++='\0';
+t++;
+ } else if (*s=='\\'||*s=='\''||*s=='\"'){
+*s++ = *t++;
+ }else{
+*s++; = '\\';
+continue;
}
l--;
- if (l > 0) {
-if (*t == '0') {
- *s++='\0';
- t++;
-} else {
- *s++ = *t++; /* preserve the next character */
-}
-l--;
+ if (len != NULL) {
+(*len)--;
}
} else {
*s++ = *t++;
- l--;
}
}
- if (s != t) {
- *s = '\0';
- }
+ *s = '\0';
+
}
/* }}} */
@@ -2627,6 +2634,10 @@
case '\'':
*target++ = '\'';
*target++ = '\'';
+ break;
+case '\\':
+ *target++ = '\\';
+ *target++ = '\\';
break;
default:
*target++ = *source;
"Jani Taskinen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Heh..so magic_quotes_sybase ini setting affects how stripslashes()
> function works too? Pretty high WTF factor there. It should be
> an additional option for php_stripslashes() that is passed where
> appropriate.
>
> --Jani
>
>
>
> On Mon, 31 Mar 2003, Sander Roobol wrote:
>
> >On Mon, Mar 31, 2003 at 03:45:13PM +0200, moshe doron wrote:
> >> could some1 explain the first if here (php_stripslashes:cybase mode)
> >> http://lxr.php.net/source/php4/ext/standard/string.c#2324
> >> that have nothing with slashes but with quotes?
> >
> >Sybase escapes ' with '' and NUL with \0 so we needed a special
> >version of php_stripslashes().
> >
> >Sander
> >
> >>
> >> could this if be removed safely?
> >>
> >> tnx
> >> moshe.
> >>
> >>
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >>
> >
> >
>
> --
> <- For Sale! ->
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] modules and registering destructors
On Sun, Mar 30, 2003 at 04:34:36PM -0500, Rob Richards wrote: > My questions for the other day seem a lot off. After going through modules > much more, I need someone to either confirm or explain a little more on how > resources within a module are destroyed. What I am seeing stepping through > the code is the following: > > a module loaded from the ini file destroys its resources in the reverse > order that they are created via the script. > > a module loaded from a dl command destroys resources in the order that they > are registered in the PHP_MINIT_FUNCTION via > zend_register_list_destructors_ex. > > The memory leaks I seem to be seeing then would be due to the fact that > there are some dependencies on the resource destructions, which would mean > that the destructors would need to be defined in the order they should be > destroyed in (to support loading via dl). > > Is correct? If not can someone shed a little more light on this? using dl() is generally not as "good" as loading extensions via php.ini. > > The problem I am stepping through is in the domxml. php_free_xml_doc is the > first destructor registered, so when the extension is loaded via the dl > command, php_free_xml_doc is the first destructor called, leaving the other > resources (node references, etc..) which were created in the script to crash > when they get called to be destroyed since xmlFreeDoc was already called. i was the guy that requested the destructors to be called in reverse order of creation, but i have never invstigated what happens if extensions are loaded via dl(). > > Any info on how the destructors work in the 2 different scenarios would be > greatly helpful. they shouldn't IMHO. if you could prepare a patch that fixes this i'm sure it'll be discussed here. but as not too many ppls actually think that dl() is a GoodFunction(tm) don't expect that anyone will "jump on" you problem just 'cause you reported it. so - my advice: a) include domxml in your php-build -or- b) load the shared lib via php.ini. if you _have_ to use dl() during your script (which will always be waaay slower than a or b) you will have to either c) fix the problem yourself and propose a patch or d) find someone who does that for you. my 2c, tc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Type hints revisited [IllegalArgumentException instead of E_ERROR]
At 14:03 31.03.2003, Stanislav Malyshev wrote: WF>> Type hinting, if it causes a bail-out, renders the scripts WF>> non-portable to (the growing number of) applications that intend to WF>> stick around for longer than a short web-request. Well, I do not completely understand how it is "non-portable". If the script calls "hinted" function with wrong parameters, it is a fatal error - I see no sane (meaning, safe not for your particular application, but for all of them) way to continue from here except for saying the user "Well, doh!" and exiting. That's like calling function with wrong name - how can you continue from there and expect it works? Exceptions are exceptions (try to think about the meaning of the spoken word). And the sense of exception handlers is to take care of such exceptions. Now calling a non existing function or calling it with the wrong parameters is an exception. The first is the exception that the necessary function is not present and the second is the exception that an illegal parameter was passed. The first typically happens when some dynamic loading failed. As someone writing safe and robust code you should take care of this. And in some cases you might be able to do a fallback rather then the only current possibility to pull out a nice error message. The second typically happens in when in a portable application something went wrong. In those cases there is only some little part not working and often this can be more or less ignored if taken care of in an exception handler. Having exceptions *only* to throw user defined exceptions stands in total contrast to what they are about. If so the less expirienced programmer is lead to use his own exceptions. And as someone already said (was it Zeev) typically exceptions are to expensive. regards marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: Type hints revisited [IllegalArgumentException instead of E_ERROR]
At 14:55 31.03.2003, Wez Furlong wrote: You can use function_exists() to avoid a fatal error, but there is no equivalent function_parameters_are_ok() API to avoid a miserable death in the situations that I have already mentioned. Why not just be consistent with all the other parameter checks and raise an E_WARNING and RETURN_NULL when the parameters are incorrect? I don't see what is so special about hinted parameters that they have to bail out the engine, while the built-in (and extension) functions will happily return NULL and continue execution. We are NOT consistent. Some functions return NULL, some return false and most functions do not even document what they do. And there are functions that return NULL and false depending on the type of error. marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] crash problem in php's mysql library (Threads !)
Im using the libmysql bundled with PHP. Are you suggesting the use of external libmysql instead of the one bundled with PHP ? --Roshan > -Original Message- > From: Georg Richter [mailto:[EMAIL PROTECTED] > Sent: Saturday, March 29, 2003 10:34 PM > To: NAIK,ROSHAN (HP-Cupertino,ex1) > Subject: Re: [PHP-DEV] crash problem in php's mysql library > (Threads !) > > > On Saturday 29 March 2003 04:04, you wrote: > > Hello, > > which version of libmysql do you use? The bundled libmysql or > do you use an > external one? Do you are able to reproduce this error with > the latest stable > libmysql (3.23.56 or 4.0.12) ? > > I found a similar problem on the internal MySQL AB lists, so > I think the > problem is solved with newer versions of libmysql. The > bundled lib is the > 3.23.49 Version with some additional security fixes/patches. > > Regards > > Georg > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] magic_quotes_sybase and php_stripslashes
> well, since magic mode could be corrupted if we handly playing with the string, e.g. > adding slash into string, i wrong here. the only problem was the reported bug thats > now fixed on the cvs. this fix also addslashes no matter sybase or not but still > exist delte between sybase and regular mode regrading the way quotes are > manipulating. i must put disclaimer here: this can break scripts that used asdslashes with magic quotes off for sybase. on the other hand, leaving the code as it was, make the used of magic quotes usless for some situations (e.g u have forum for programers and the massages contains code with '\0') so this change may won't go into the PHP_4_3. > regrading the WTF factor, sincs add\strip slash function main, if not only, target > is database related, caution on the documentation is enough. otherwise, u may want > complatly fork php_*_slashes into php_*_magic, thats olso contains the check if > magic mode set on. this can be comprehend solution. i'm +1 for it.
Re: [PHP-DEV] Reflection API RFC
On Sun, 30 Mar 2003, Alan Knowles wrote:
> - If you stored token start/end then you would be able to do getSource
> for function/method/class.. etc.. (which can do a load file/tokenizer
> and return implode('',array_range(starttoken,endtoken)
Keeping track of the tokens this way would require quite some code, I
think.
> * it may also be better to store the token of the doc comment - On some
> of the pear classes the comment code is larger than the PHP code, and
> would be quite an overhead... - just make it throw an exception if you
> forgot to load the tokens for it..
Hmm, I see the point, but is that really a problem? If a lot of people
are worried about the overhead of storing doc comments, we could perhaps
store only the starting/ending line of the comment and let the other
tools extract them. But it means that the tools have to have access to
the original source file - not really possible with 3rd party software
distributed under an encoder, for example.
> - there appears to be no arguments array for methods/functions
No really good way of doing it with the current architecture. I defer to
Andi/Zeev to see if it's possible to capture the declared parameters
somehow..
> - not sure if extendsClass(), would be implemented by Implements?, and
> theres no getExtendsArray(), to return the tree of extends
What would extendsClass() do?
> - constructors: -
> $classdetails = new ClassType('myclass');
> $classdetails = new ClassType($this);
> rather than
> $classdetails = ClassType::fromName('myclass')
> $classdetails = ClassType::fromInstance('myclass')
I'd rather avoid overloading. And in this case, these methods are
basically factories.
> - I still think it would be nice to implement some of them as variables
> so that
> print_r($classdetails); would display some cute output...
We could always have toString() method for each one..
> btw - It would also be nice to have unloadclass - so
> a) the codedoc generators - could load and free classes.
> b) php-gtk could reload modules rather than having to restart each time
> to test code..
What do you mean by unloadclass?
-Andrei http://www.gravitonic.com/
"This isn't right. This isn't even wrong."
-- Wolfgang Pauli
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: [Zend Engine 2] Re: [PHP-DEV] Re: Type hints revisited [IllegalArgumentException instead of E_ERROR]
> Well, I do not completely understand how it is "non-portable". If the > script calls "hinted" function with wrong parameters, it is a > fatal error > - I see no sane (meaning, safe not for your particular > application, but > for all of them) way to continue from here except for saying the user > "Well, doh!" and exiting. That's like calling function with "Well, doh! Reenter the frickin' parameter." harald -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: [Zend Engine 2] Re: [PHP-DEV] Re: Type hints revisited [IllegalArgumentException instead of E_ERROR]
> WF>> Please don't have it bail out unless there is some kind of > WF>> function_parameters_are_ok() API so that careful > programmers can work > WF>> around this issue. > > Careful programmers should know interface of called functions > and never > call them with parameters that do not match the interface. :) you mean they should check them with 'is interface' before calling a typehinted function ?! harald -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP is now a Microsoft Partner
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 PHP is now a Microsoft Partner Issued on: April 1, 2003 Software: PHP Platforms: All The PHP Group has is proud to announce that we are now a partner of Microsoft Corporation. Description After many hours of talking with people from Microsoft, we came up with an agreement, which will make us a partner with them. This will have many benefits for both the users and the developers. Impact PHP will be included in the next upcoming release of their operating system, both as CLI and as CGI and ISAPI for IIS. Microsoft have released theirsource code to IIS to some of our developement team so we will be able to tightly integrated PHP with their webserver. Except that, this will lead to many improvements in PHP. Microsoft have agreed to hire our top 5 developers plus an extra 10 that only will work with the developement of PHP in Windows and UNIX environment. They have also agreed to host all of our websites (.php.net) on new highend servers within a month. The downside is that we will change our license to be more restrictive, but it will still be opensource. Microsoft, however, will have to accept every single commit before they get into our CVS, so we will also change the commitment system in a way that it will first go to a Microsoft representant that will validate the patch and then apply it if it gets accepted. Credits The PHP Group would like to thank Microsoft Corporation and their staff for being excellent to work with and make buisness with. Copyright (c) 2003 The PHP Group. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+USyr/HlsOzd2WlERAtLKAJ9GPbPt6Vg77zIcPTGKh78WofmmeACgneDV tUERfwp/RXtcH13vdv0CGGY= =rYm5 -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP is now a Microsoft Partner
haha, happy April Fools troll. On Monday, March 31, 2003, at 10:40 PM, Magnus Maatta wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 PHP is now a Microsoft Partner -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c basic_functions.h
Sterling Hughes wrote: > sterling Tue Apr 1 00:01:50 2003 EDT > > Modified files: > /php4/ext/standardbasic_functions.c basic_functions.h > Log: > Add the landonize() and landonize_url() functions which provide a > secure alternative to the sha1() and sha1_file() functions. Happy April's 1st to you, too ;-) -- 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
Re: [PHP-DEV] PHP is now a Microsoft Partner
It's joke?? If it is, it's bad joke, man.. Akelavlk > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > >PHP is now a Microsoft Partner > > Issued on: April 1, 2003 > Software: PHP > Platforms: All > > >The PHP Group has is proud to announce that we are now a partner of >Microsoft Corporation. > > > Description > >After many hours of talking with people from Microsoft, we came up with >an agreement, which will make us a partner with them. This will have many >benefits for both the users and the developers. > > > Impact > >PHP will be included in the next upcoming release of their operating system, >both as CLI and as CGI and ISAPI for IIS. Microsoft have released theirsource code to IIS to some of our developement team so we will be able to >tightly integrated PHP with their webserver. > >Except that, this will lead to many improvements in PHP. Microsoft have >agreed to hire our top 5 developers plus an extra 10 that only will work >with the developement of PHP in Windows and UNIX environment. > >They have also agreed to host all of our websites (.php.net) on new >highend servers within a month. > >The downside is that we will change our license to be more restrictive, >but it will still be opensource. Microsoft, however, will have to accept >every single commit before they get into our CVS, so we will also change >the commitment system in a way that it will first go to a Microsoft >representant that will validate the patch and then apply it if it gets >accepted. > > > Credits > >The PHP Group would like to thank Microsoft Corporation and their staff >for being excellent to work with and make buisness with. > > > Copyright (c) 2003 The PHP Group. > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE+USyr/HlsOzd2WlERAtLKAJ9GPbPt6Vg77zIcPTGKh78WofmmeACgneDV > tUERfwp/RXtcH13vdv0CGGY= > =rYm5 > -END PGP SIGNATURE- > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > http://www.pobox.sk/ - najvacsi slovensky freemail -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: mbr
I wanna translate (a complete translation) the PHP documentation in Romanian; also I wanna help with other PHP developping stuff. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reflection API RFC
Andrei Zmievski wrote: > What do you mean by unloadclass? I think what the name suggests: unload a class, ie. undeclare it. -- 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: PHP is now a Microsoft Partner
Nice try ! -- Regards. M.CHAILLAN Nicolas [EMAIL PROTECTED] www.WorldAKT.com Hébergement de sites internets. "Magnus Maatta" <[EMAIL PROTECTED]> a écrit dans le message news: [EMAIL PROTECTED] > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > >PHP is now a Microsoft Partner > > Issued on: April 1, 2003 > Software: PHP > Platforms: All > > >The PHP Group has is proud to announce that we are now a partner of >Microsoft Corporation. > > > Description > >After many hours of talking with people from Microsoft, we came up with >an agreement, which will make us a partner with them. This will have many >benefits for both the users and the developers. > > > Impact > >PHP will be included in the next upcoming release of their operating system, >both as CLI and as CGI and ISAPI for IIS. Microsoft have released their source code to IIS to some of our developement team so we will be able to >tightly integrated PHP with their webserver. > >Except that, this will lead to many improvements in PHP. Microsoft have >agreed to hire our top 5 developers plus an extra 10 that only will work >with the developement of PHP in Windows and UNIX environment. > >They have also agreed to host all of our websites (.php.net) on new >highend servers within a month. > >The downside is that we will change our license to be more restrictive, >but it will still be opensource. Microsoft, however, will have to accept >every single commit before they get into our CVS, so we will also change >the commitment system in a way that it will first go to a Microsoft >representant that will validate the patch and then apply it if it gets >accepted. > > > Credits > >The PHP Group would like to thank Microsoft Corporation and their staff >for being excellent to work with and make buisness with. > > > Copyright (c) 2003 The PHP Group. > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE+USyr/HlsOzd2WlERAtLKAJ9GPbPt6Vg77zIcPTGKh78WofmmeACgneDV > tUERfwp/RXtcH13vdv0CGGY= > =rYm5 > -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Type hints revisited [IllegalArgumentException instead of E_ERROR]
At 16:32 31/03/2003, Wez Furlong wrote: Yes, but when using call_user_function, __call(), and RPC servers, you don't always know what function you are calling at the time you write the script. I'd argue that it makes sense that the function in that case will not use type hints, then, and use instanceof based checking if necessary. Feeding a function with certain restrictions to an API that may feed it anything is a bad programming practice, IMHO. You should only be sending such functions based on the knowledge that the caller will be calling them with a certain convention. E.g., if the caller expects them to belong to a certain interface or class. Thats where is_callable()/function_exists() are extremely useful. I think that we may need some sort of a method_implements_interface() callback to make this set of tools complete. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] magic_quotes_sybase and php_stripslashes
> the problem is also for 'regular' magic mode. > the addslashes add slashes anly when the slash follow by '\'' or '\"' or > '\\' but on stripslashes it's nuke all the slashes without considering whats > came after that. well, since magic mode could be corrupted if we handy playing with the string, e.g. adding slash into string, i wrong here. the only problem was the reported bug thats now fixed on the cvs. this fix also addslashes no matter sybase or not but still exist delte between sybase and regular mode regrading the way quotes are manipulating. regrading the WTF factor, sincs add\strip slash function main, if not only, target is database related, caution on the documentation is enough. otherwise, u may want complatly fork php_*_slashes into php_*_magic, thats olso contains the check if magic mode set on.
Re: [PHP-DEV] modules and registering destructors
I have 2 different patches that fix this specific issue, but am not sure if they are actually correct - as there may be a lower level issue, or even which one would be correct. One patch is on the Zend engine which will go through the destructor list in reverse within zend_clean_module_rsrc_dtors. The other is directly in domxml by just moving the php_free_xml_doc call to the end of the registered destructor list. Which is actually correct, I have no idea. There is no documentation on which order destructors should be defined within a module, so dont know if there is a standard already in place. As you note it is most likely due to dl() not being a good function and few modules probably have a dependency issue like this. Although it is not an ideal way to load extensions, the function does exist. The real issue comes down to why when coming from the ini file, things are destroyed in reverse from how they were created within a php script, while if loaded from dl(), they are destroyed based on the order the destructors are defined within the module. Is this really a lower level issue and I am just seeing the surface of it? This is one sure fire way to dive into the engine piece I can tell you. On 31 Mar 2003, Thies C. Arntzen wrote: > > using dl() is generally not as "good" as loading extensions via > php.ini. > > > The problem I am stepping through is in the domxml. php_free_xml_doc is the > > first destructor registered, so when the extension is loaded via the dl > > command, php_free_xml_doc is the first destructor called, leaving the other > > resources (node references, etc..) which were created in the script to crash > > when they get called to be destroyed since xmlFreeDoc was already called. > > i was the guy that requested the destructors to be called in > reverse order of creation, but i have never invstigated what > happens if extensions are loaded via dl(). > > > Any info on how the destructors work in the 2 different scenarios would be > > greatly helpful. > > they shouldn't IMHO. if you could prepare a patch that fixes > this i'm sure it'll be discussed here. but as not too many > ppls actually think that dl() is a GoodFunction(tm) don't > expect that anyone will "jump on" you problem just 'cause you > reported it. > > so - my advice: a) include domxml in your php-build -or- b) > load the shared lib via php.ini. if you _have_ to use dl() > during your script (which will always be waaay slower than a > or b) you will have to either c) fix the problem yourself and > propose a patch or d) find someone who does that for you. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Type hints revisited [IllegalArgumentException instead of E_ERROR]
At 15:27 31.03.2003, Stanislav Malyshev wrote: WF>> Please don't have it bail out unless there is some kind of WF>> function_parameters_are_ok() API so that careful programmers can work WF>> around this issue. Careful programmers should know interface of called functions and never call them with parameters that do not match the interface. :) But not all programmers are that carefull and in bigger applications this cannot always ensured especially when some underlying stuff changes a bit... marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
