Re: [PHP-DEV] Large file support for PHP
hi, On Monday 15 October 2007 07:41:11 pm Stanislav Malyshev wrote: I didn't dive yet too deep into the patch, but shouldn't it be fixed on stream level and not function level? I.e. there are a lot of functions using streams (including files) - would they support bigger files too? i would suggest that anywhere where one is doing something with a size or offset and not using the posix size_t/off_t types should get such changes. and like i said, i don't see the motivation behind this extra step of returning the size in double form if it's bigger than LONG_MAX. I also think that while using size_t is good, changing binary structures might be rather dangerous, unless we can ensure all PHPs built on the certain platform would use the same setting. i don't think switching from long/int - size_t is a problem in the scope of function internal variables. the only place where you need to worry about this is in headers/structs/function declarations that are exported to the API/ABI. sean signature.asc Description: This is a digitally signed message part.
AW: AW: [PHP-DEV] Method overloading by method signature
It allows you to be strict when messing with types but it doesn't allow you to overload type hinted methods ... so this is no solution to the problem of overloading type hinted methods, is it ? -Ursprüngliche Nachricht- Von: Stanislav Malyshev [mailto:[EMAIL PROTECTED] Gesendet: Mo 15.10.2007 18:38 An: Umberto Salsi Cc: internals@lists.php.net Betreff: Re: AW: [PHP-DEV] Method overloading by method signature That's why I developed PHPLint, a PHP parser and validator that performs a static analysis of the source, ensuring the safe handling of types. In a word, this tool makes PHP very close to a strong-typed language without the need to further complicate the interpreter with new features that would pervert the nature of the language. I think this is better solution than messing with the language :) -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] My thanks to the PHP community.
http://news.php.net/php.internals/32789 On 15/10/2007, Antony Dovgal [EMAIL PROTECTED] wrote: Thank you? I can't recall when I heard it last time. Really, how about right now! Unconditionally and without reservation, I would like to take this opportunity to say thank you to every single developer, documenter, debugger who has ever responded to my sometimes lengthy comments/posts. Without all of your skill, dedication, understanding, and more often than not, perseverance, I would be having a harder time doing my job. The effort you have all put into making PHP the truly successful language it is today has allowed me to be gainfully employed for many years. I would like to make special mention of Nuno Lopes who, many years ago, helped me get into the PHP documentation system and also to Hannes Magnusson for his continual support and advice in aid of my lack of understanding of some of the sometimes quite basic concepts of the new PHD documentation system. As I have in my signature, I am Standing on the shoulders of some VERY clever giants!. Thank you. Richard Quadling. -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] My musings on problems I've had with the PHP community
On Mon, 2007-10-15 at 19:03 -0300, Cristian Rodriguez wrote: 2007/10/15, Antony Dovgal [EMAIL PROTECTED]: Thank you? Rarely, as the year advances, people is getting more and more stressed and is certainly not fun to deal with the reports. It's fun to certain point. I've also come to same conclusion as Antony and I only take a peek once in a while to the bug db nowadays. Which is propably a relief to some people reporting stuff there. ;) Also some people tend to think that their bug reports have to be reviewed now (I mean NOW!!!), unfortunately, they fail to recognize that the project is run by volunteers That's the main issue in here, somehow the common thinking is that someone pays (all) the people going over the reports. Having done the job for about 6 years now, I can count the thank you messages with one hand. And that includes the extremely rare cases when I got paid by them..:) -- Patches/Donations: http://pecl.php.net/~jani/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Method overloading by method signature
On 15/10/2007, Hans Moog [EMAIL PROTECTED] wrote:
When it would be:
==
function xpath(DomDocument $arg) {
return new DomXPath($arg);
}
function xpath(XmlTree $arg) {
return new DomXPath($this-loadXML($arg-getSource(;
}
function xpath(string $arg) {
return new DomXPath($this-loadXML($arg));
}
==
(since when method overloding by sigantures wer put into php, scalar types
should be possible, too, shouldn't they?)
I would prefer the second one because I understand the behaviour much faster
than analyzing the if switch (and this if switch is really simple to
understand because there is only one command in every block). The second
reason for me to select the second version is, that I am able to write better
documentation for each behaviour (although, in this situation there isn't
that much to be commented).
-Ursprüngliche Nachricht-
Von: Timm Friebe [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 15. Oktober 2007 20:47
An: internals@lists.php.net
Betreff: Re: [PHP-DEV] Method overloading by method signature
Hi,
[...]
Later we added type hints to help code readability.
Let me jump at this:
==
function xpath($arg) {
if ($arg instanceof DomDocument) {
return new DomXPath($arg);
} else if ($arg instanceof XmlTree) {
return new DomXPath($this-loadXML($arg-getSource()));
} else if (is_string($arg)) {
return new DomXPath($this-loadXML($arg));
} else {
throw new IllegalArgumentException('Unsupported argument type');
}
}
== vs. ==
function xpath(DomDocument $arg) {
return new DomXPath($arg);
}
function xpath(XmlTree $arg) {
return new DomXPath($this-loadXML($arg-getSource(;
}
function xpath($arg) { // Untyped = default
if (!is_string($arg)) {
throw new IllegalArgumentException('Unsupported argument type');
}
return new DomXPath($this-loadXML($arg));
}
==
If we consider the readability argument only: Which one of the above more
readable? You decide:)
- Timm
As the PHP Documentation may have to is starting adding multiple
signatures (Docbook has no mechanism if grouping optional parameters
it seems), it seems only fair that PHP itself should (flame-retardant
suit fully fitted) catch-up. (Hey when has documentation EVER been
ahead of the game!?!).
If this feature makes PHP (or at least some aspects of it), a typed
language, then that's OK by me. It means my code is more consistent
with other languages.
--
-
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731
Standing on the shoulders of some very clever giants!
Re: AW: [PHP-DEV] Method overloading by method signature
Hans Moog wrote:
When it would be:
==
function xpath(DomDocument $arg) {
return new DomXPath($arg);
}
function xpath(XmlTree $arg) {
return new DomXPath($this-loadXML($arg-getSource(;
}
function xpath(string $arg) {
return new DomXPath($this-loadXML($arg));
}
==
function xpathFromDom($arg) {
return new DomXPath($arg);
}
function xpathFromTree($arg) {
return new DomXPath($this-loadXML($arg-getSource(;
}
function xpathFromString($arg) {
return new DomXPath($this-loadXML($arg));
}
Works perfectly well. And you don't even need to document them because
the names speak for themselves. A much simpler (and clearer) solution IMHO.
If you want an OO way I'd prefer something like
$xpath = $obj-getXPath();
to
$xpath = $this-xpath($obj);
anyway. This doesn't work with basic types like strings but having a
special case there is not a problem IMHO as using those two
interchangeably will lead to other problems anyway.
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
AW: AW: [PHP-DEV] Method overloading by method signature
And if you have more than one parameter you will name it
methodFromStringIntegerSampleClassBoolean ?!?
And how would you do the same for constructors ?!? Create a
initWithStringIntegerSampleClassBoolean method which has to be called after
object creation ?!?
-Ursprüngliche Nachricht-
Von: Christian Schneider [mailto:[EMAIL PROTECTED]
Gesendet: Di 16.10.2007 11:45
An: Hans Moog
Cc: internals@lists.php.net
Betreff: Re: AW: [PHP-DEV] Method overloading by method signature
Hans Moog wrote:
When it would be:
==
function xpath(DomDocument $arg) {
return new DomXPath($arg);
}
function xpath(XmlTree $arg) {
return new DomXPath($this-loadXML($arg-getSource(;
}
function xpath(string $arg) {
return new DomXPath($this-loadXML($arg));
}
==
function xpathFromDom($arg) {
return new DomXPath($arg);
}
function xpathFromTree($arg) {
return new DomXPath($this-loadXML($arg-getSource(;
}
function xpathFromString($arg) {
return new DomXPath($this-loadXML($arg));
}
Works perfectly well. And you don't even need to document them because
the names speak for themselves. A much simpler (and clearer) solution IMHO.
If you want an OO way I'd prefer something like
$xpath = $obj-getXPath();
to
$xpath = $this-xpath($obj);
anyway. This doesn't work with basic types like strings but having a
special case there is not a problem IMHO as using those two
interchangeably will lead to other problems anyway.
- Chris
Re: AW: AW: [PHP-DEV] Method overloading by method signature
Hans Moog wrote: And if you have more than one parameter you will name it methodFromStringIntegerSampleClassBoolean ?!? No, I would rethink my interface. And how would you do the same for constructors ?!? Create a initWithStringIntegerSampleClassBoolean method which has to be called after object creation ?!? No, I would either use factory methods or the OO approach I outlined in my previous message. But let's agree that we fundamentally disagree on style. I think you're using the wrong language but that's just me Over and out, - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: AW: AW: [PHP-DEV] Method overloading by method signature
And if you have more than one parameter you will name it methodFromStringIntegerSampleClassBoolean ?!? No, I would rethink my interface. Sometimes you need more than one parameter and even rethinking wouldn't solve this requirement. And how would you do the same for constructors ?!? Create a initWithStringIntegerSampleClassBoolean method which has to be called after object creation ?!? No, I would either use factory methods or the OO approach I outlined in my previous message. O_O really?!? You would use factory methods just to allow more than one parameter to be passed to the constructor? Oka. But let's agree that we fundamentally disagree on style. Yup :) I think you're using the wrong language but that's just me Over and out, - Chris I agree. But PHP (until PHP 5.2.x) was the wrong language for everyone who wanted to use namespaces, too. But a programming language is able to evolve and sometimes new features are really usefull and should be included. And in this special case the new feature would not harm anyone because it would be fully backward compatible and in my humble opinion it would push php to an enterprise level when it comes to object orientation. Btw: I really LOVE PHP and the way it handles things. You are able to develop applications VERY fast but when it comes to big applications it is sometimes better to be more strict and structure things a little bit different, especially when you have to mess around with 3rdparty developers.
Re: AW: AW: AW: [PHP-DEV] Method overloading by method signature
On 16.10.2007, at 13:43, Hans Moog wrote: I agree. But PHP (until PHP 5.2.x) was the wrong language for everyone who wanted to use namespaces, too. But a programming language is able to evolve and sometimes new features are really usefull and should be included. And in this special case the new feature would not harm anyone because it would be fully backward compatible and in my humble opinion it would push php to an enterprise level when it comes to object orientation. The point is that I do not see this feature at all relevant to solving the web problem. This is where PHP needs to focus. Namespaces help in solving the web problem, because it eases cooperation of independent developers to supply libraries. The feature you are proposing is solved easily in userland (just like named parameters). Its is a feature I could see using in a heavy lifting language, but not in a glue language. Where do we draw the line? Somewhere relatively arbitrary, but my gut tells me that this is a good candidate to be on lets leave it out of php side of the line. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: AW: AW: AW: [PHP-DEV] Method overloading by method signature
The point is that I do not see this feature at all relevant to solving the web problem. This is where PHP needs to focus. Namespaces help in solving the web problem, because it eases cooperation of independent developers to supply libraries. The feature you are proposing is solved easily in userland (just like named parameters). Its is a feature I could see using in a heavy lifting language, but not in a glue language. Where do we draw the line? Somewhere relatively arbitrary, but my gut tells me that this is a good candidate to be on lets leave it out of php side of the line. regards, Lukas When it comes to interoperation between systems and or developers, it is always a good idea to define strict standards of how the communication between libarys and components has to take place (since public methods are something like an interface bewteen interoperating libraries and classes), to be sure that all components work together as expected. One of the best approaches to explain the usage of the class to a foreign developer and to be sure that your class is used correctly and help the foreign developer to understand how your classes have to be used (beside documentation), is to typehint your parameters. But when you do so, you are no longer able to overload your methods anymore. Because of this, I think this feature is EXTREMELY relevant to solving the web problem. Not being able to overload methods anymore is a bad thing since overloaded methods allow to use a class in much more situations than just being able to use it in one single way. You are not able to tell the developer to use integer OR string values but NO arrays, booleans, Objects and so on when calling your method. You could mention it in the comment but when he misunderstands the comment, php doesn't notify him about his error. When using type hinted parameters, php would do so. You are not able to provide strict api's out of the box right now. You will always have to check the types of the passed parameters manually.
Re: AW: AW: AW: [PHP-DEV] Method overloading by method signature
On 16.10.2007, at 15:09, Hans Moog wrote: When it comes to interoperation between systems and or developers, it is always a good idea to define strict standards of how the communication between libarys and components has to take place (since public methods are something like an interface bewteen interoperating libraries and classes), to be sure that all components work together as expected. One of the best approaches to explain the usage of the class to a foreign developer and to be sure that your class is used correctly and help the foreign developer to understand how your classes have to be used (beside documentation), is to typehint your parameters. I do not agree that its always a good idea to make your communication strict when you are using a type less language. Are you implying that for some reason typeless-ness only becomes relevant in your user land code? I do agree that libraries tend to be a bit more static and therefore less in need of quickness in development, but I do not see this validating your core assumption that strictness is a good thing for libraries. PHP has always tended more towards keeping running when at all possible rather than throwing fatal errors. The advent of exceptions has changed part of this game already, but I do not think that the solution is to start turning every situation the developer hasnt thought off into fatal errors. Sometimes barely working is better than not working and I think this is a mantra on the web. But when you do so, you are no longer able to overload your methods anymore. Because of this, I think this feature is EXTREMELY relevant to solving the web problem. Not being able to overload methods anymore is a bad thing since overloaded methods allow to use a class in much more situations than just being able to use it in one single way. You are not able to tell the developer to use integer OR string values but NO arrays, booleans, Objects and so on when calling your method. You could mention it in the comment but when he misunderstands the comment, php doesn't notify him about his error. When using type hinted parameters, php would do so. You are not able to provide strict api's out of the box right now. You will always have to check the types of the passed parameters manually. Your list of if's is quote long, which illustrates what kind of niche problem you are solving. The bulk of all libraries can live quite well without type hints. If you choose to use them, then accept their limitations and add manual overloading via separate functions that cover all reasonable permutations. Or implement this overloading the same way other people handle the lack of named parameters. The addition of type hinting was questionable enough, that they hardly warrant yet another addition just to make them even more useful in a niche case. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Large file support for PHP
On Oct 16, 2007, at 2:44 AM, sean finney wrote: i would suggest that anywhere where one is doing something with a size or offset and not using the posix size_t/off_t types should get such changes. and like i said, i don't see the motivation behind this extra step of returning the size in double form if it's bigger than LONG_MAX. PHP's native integer type is long, how else are you going to relay numbers longer than a long back to the script without rewriting the engine to add additional integer types, which is a massive changeset? i don't think switching from long/int - size_t is a problem in the scope of function internal variables. the only place where you need to worry about this is in headers/structs/function declarations that are exported to the API/ABI. Or just bump our API number(s) and not worry about it, since the module loading code will refuse to load an incompatible module. PHP 5.3 is an ideal point to make this kind of change, as I've already stated. --Wez. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Using OnUpdateUTF8String in PHP 6
With thanks to Sara we looked at OnUpdateUTF8String to access a
php.ini value in OCI8 in PHP 6.
One of our engineers sent me a proposed patch for zend_ini.c in PHP6
to allow OnUpdateUTF8String to work as he thought it should. Any
comments?
Chris
The problems I faced when unicode.semantics=On were:
1) Any OnUpdateUTF8String php.ini variable is seen as NULL in
oci_globals.
2) If the above is resolved, the memory of the variable is wiped out,
by the time we come to execution of the script, after module inits.
3) We still convert to UTF-16 when unicode.semantics=Off.
PS. Patch is attached - if it gets through.
--
Christopher Jones, Oracle
Email: [EMAIL PROTECTED]Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad
--- zend_ini.c 2007-10-02 11:07:32.0 -0700
+++ zend_ini.c.new 2007-10-16 13:20:03.0 -0700
@@ -640,7 +640,8 @@
ZEND_API ZEND_INI_MH(OnUpdateUTF8String) /* {{{ */
{
- UChar **p;
+ UChar **up;
+ char **p;
UChar *ustr = NULL;
int32_t ustr_len, capacity;
UErrorCode status = U_ZERO_ERROR;
@@ -651,30 +652,37 @@
base = (char *) ts_resource(*((int *) mh_arg2));
#endif
+ /* Convert only if unicode semantics is on. Otherwise, same as
OnUpdateString */
+ if (UG(unicode)){
+ /* estimate capacity */
+ capacity = (new_value_length 2) ? ((new_value_length 1) +
(new_value_length 3) + 2) : new_value_length;
+
+ while (1) {
+ ustr = peurealloc(ustr, capacity+1, 1);
+ u_strFromUTF8(ustr, capacity+1, ustr_len, new_value,
new_value_length, status);
+ if (status == U_BUFFER_OVERFLOW_ERROR || status ==
U_STRING_NOT_TERMINATED_WARNING) {
+ capacity = ustr_len;
+ status = U_ZERO_ERROR;
+ } else {
+ break;
+ }
+ }
- /* estimate capacity */
- capacity = (new_value_length 2) ? ((new_value_length 1) +
(new_value_length 3) + 2) : new_value_length;
-
- while (1) {
- ustr = eurealloc(ustr, capacity+1);
- u_strFromUTF8(ustr, capacity, ustr_len, new_value,
new_value_length, status);
- if (status == U_BUFFER_OVERFLOW_ERROR) {
- capacity = ustr_len;
- status = U_ZERO_ERROR;
- } else {
- break;
+ if (U_FAILURE(status)) {
+ zend_error(E_WARNING, Could not convert UTF-8 INI
value to Unicode);
+ efree(ustr);
+ return FAILURE;
}
- }
- if (U_FAILURE(status)) {
- zend_error(E_WARNING, Could not convert UTF-8 INI value to
Unicode);
- efree(ustr);
- return FAILURE;
- }
+ up = (UChar **) (base+(size_t) mh_arg1);
- p = (UChar **) (base+(size_t) mh_arg1);
+ *up = ustr;
+ }
+ else { /* Same as OnUpdateString */
+ p = (char **) (base+(size_t) mh_arg1);
- *p = ustr;
+ *p = new_value;
+ }
return SUCCESS;
}
/* }}} */
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Large file support for PHP
Yes, the patch does that; it turns on LFS in the headers, which promotes the off_t and size_t types that are used by streams to the 64-bit versions. This is the one liner in configure.in. The other larger part of the patch is to make PHP functions capable of returning and accepting numbers that are too big to fit into a long. I think it's better to do it in .h file and not CFLAGS (or both?) so that if somebody includes PHP headers they would always get the same result. This would prevent one from building incompatible module. Is it guaranteed that once you have this define you would always get the same result on all builds (regardless of libc difference, etc.)? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Large file support for PHP
You might have a point there; I'd assumed that CFLAGS made it through to php-config, but it doesn't look like they do. It should be a simple matter to define them in php_config.h instead. --Wez. On Oct 16, 2007, at 6:16 PM, Stanislav Malyshev wrote: Yes, the patch does that; it turns on LFS in the headers, which promotes the off_t and size_t types that are used by streams to the 64-bit versions. This is the one liner in configure.in. The other larger part of the patch is to make PHP functions capable of returning and accepting numbers that are too big to fit into a long. I think it's better to do it in .h file and not CFLAGS (or both?) so that if somebody includes PHP headers they would always get the same result. This would prevent one from building incompatible module. Is it guaranteed that once you have this define you would always get the same result on all builds (regardless of libc difference, etc.)? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Large file support for PHP
yes, this is of course a big deal for some people, esp if you're using proprietary software that's built against the original abi. of course if you're only using OSS extensions, you can simply recompile them against the new api/abi and there's no drawback. That's not only about OSS vs. proprietary - even if you use only OSS extensions, but you do not compile everything from the source on each install (and have many platforms to install on - such as big organization with dozens of servers), you might have trouble. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Method overloading by method signature
suit fully fitted) catch-up. (Hey when has documentation EVER been ahead of the game!?!). Always? Otherwise there would be no need for documentation, if everything was in the code. Some people even start with writing docs and only then implement the actual code. Of course, it is not always the case (and some code, like Zend Engine, is so obvious that no docs are needed anyway ;) but documentation containing more insight and more content than the pure code is almost always the case, especially with properly documented code. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
