Re: [PHP-DEV] New VM architecture
On Wed, 20 Oct 2004, Andi Gutmans wrote: I have barely received feedback about the new VM architecture so I'm planning to apply the new way of doing it on Friday. I personally prefer the auto-generation over the macro based way, mainly as it should be easier to debug. I played with it a bit, but not enough to see if this is going to break Xdebug again ;-) I think I did not see any things related to zend_use_old_vm or like that... but then again I didn't really look hard. Will check it out today. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [sqlite] PHP5 SQLite3
On Wed, 20 Oct 2004, Andi Gutmans wrote: I definitely think it's starting to become time to talk about what's going to be in PHP 5.1. I see the main features I would like to see in 5.1 as: a) PDO support for most popular DBs. Maybe you can give a status report of where PDO is today and how much work it still requires? If it requires a lot of work maybe more people can join the effort. Also is there an online phpDoc of each DB API one can look at? I've looked at the source code and at the functionality and it's pretty good but I'll definitely try and look deeper as we get closer to 5.1. b) New VM architecture, some other core engine changes which have happened since 5.0.x. c) Polish some left overs in the OO model from 5.0.x, mainly the access modifiers (if/when they are allowed to be used). For example, in interfaces they shouldn't be used. Probably some error handling and bug reports which still require attention. d) Finalize the few tiny new features request on the language level from 5.1. e) Good internationalization support. See my seperate note about this that I'll send to the list in a bit. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ./configure, PHP, SuSE and the AMD64
On Wed, Oct 13, 2004 at 05:12:22PM +0200, Sascha Schumann wrote: On Wed, 13 Oct 2004, Joe Orton wrote: So other than vague slurs on OS sanity, are there objections to committing my --with-libdir patch to HEAD? I will look at it later. Have you had a chance to look at it, Sascha? joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] suggestion: empty() with infinite parameters like isset()
I'm not really anxcious to have an anyempty() function, but I do think empty() should behalve like an allempty() just like isset() behaves like an areallset(). I guess the weirdness is in the fact that isset() will give a positive reply when something exists, while empty() gives a negative reply when something exists. I guess this creates the confusion and would make the allempty() functionality less likely to be used often. I guess people will want to check more often if all their vars are set, and therefor an or situation instead of and would be more suitable, because then you could do: if (empty($var1, $var2, $var3)) echo there's an empty var; I'd personally prefer the and situation, but it's a fact that this would make it far less useful than the or. So I can see the confusion and the reason to just stick with 1 parameter. I guess there should just be a function like isset() which returns !empty(). Maybe it should be called isval() or something. Then it could be used for several vars without confusion: if (!isval($var1, $var2, $var3)) return there's an empty var; This would make sense to everybody I think, because like isset() it would be an and situation. Ron Jevon Wright [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] How about anyempty($var1, $var2, $var3, ...) ? Jevon - Original Message - From: Ron Korving [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 21, 2004 12:21 AM Subject: Re: [PHP-DEV] suggestion: empty() with infinite parameters like isset() Maybe it was a bad example. Writing data missing I was thinking that at least one variable should be set. Ron Derick Rethans [EMAIL PROTECTED] schreef in bericht news:[EMAIL PROTECTED] On Wed, 20 Oct 2004, Ron Korving wrote: Okay, I don't wanna make remarks that may have already been made earlier, but I think it should be all should be empty, because it works exactly the same for isset(), and apparently, a decision was made to give isset() that feature. Right, but then your example would already no longer have worked: if (empty($var1, $var2, $var3)) echo data missing; so there is no point in adding it like that. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] suggestion: empty() with infinite parameters like isset()
You're right, the only right way would be to introduce a new function like the isval() I suggested in my reply to Jevon. Ron Andi Gutmans [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] There is a big difference between isset() and empty() and it was discussed a lot in the past. You'll see both sides to the coin after reading the archives. It's really a problem make a call on this one. Andi At 01:13 PM 10/20/2004 +0200, Ron Korving wrote: Okay, I don't wanna make remarks that may have already been made earlier, but I think it should be all should be empty, because it works exactly the same for isset(), and apparently, a decision was made to give isset() that feature. Ron Derick Rethans [EMAIL PROTECTED] schreef in bericht news:[EMAIL PROTECTED] On Wed, 20 Oct 2004, Ron Korving wrote: I think it would be a good idea to apply the idea of infinite parameters that's been used with isset(), so one can test multiple variables: if (empty($var1, $var2, $var3)) echo data missing; We discussed this before and we didn't want to agree if it should behave like each one should be empty or all should be empty. So we will not add it. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] suggestion: empty() with infinite parameters like isset()
if(any_empty($var1, $var2, $var3)) return there's an empty var;
if(!any_empty($var1, $var2, $var3)) return there's no empty vars;
if (all_set($var1, $var2, $var3)) return all vars are set;
if (!all_set($var1, $var2, $var3)) return there's an unset var;
but how would you find out which var's, if any, are empty or not set?
otherwise, would seem not very useful...
if(!all_set($var1, $var2, $var3)){
if(!isset($var1)){
echo 'it was 1';
}
if(!isset($var2)){
echo 'it was 2';
}
if(!isset($var3)){
echo 'it was 3';
}
}
On Thu, October 21, 2004 9:13 am, Ron Korving said:
I'm not really anxcious to have an anyempty() function, but I do think
empty() should behalve like an allempty() just like isset() behaves like
an
areallset(). I guess the weirdness is in the fact that isset() will give
a
positive reply when something exists, while empty() gives a negative reply
when something exists. I guess this creates the confusion and would make
the
allempty() functionality less likely to be used often. I guess people will
want to check more often if all their vars are set, and therefor an or
situation instead of and would be more suitable, because then you could
do: if (empty($var1, $var2, $var3)) echo there's an empty var;
I'd personally prefer the and situation, but it's a fact that this would
make it far less useful than the or. So I can see the confusion and the
reason to just stick with 1 parameter.
I guess there should just be a function like isset() which returns
!empty().
Maybe it should be called isval() or something. Then it could be used for
several vars without confusion:
if (!isval($var1, $var2, $var3)) return there's an empty var;
This would make sense to everybody I think, because like isset() it would
be
an and situation.
Ron
Jevon Wright [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
How about anyempty($var1, $var2, $var3, ...) ?
Jevon
- Original Message -
From: Ron Korving [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, October 21, 2004 12:21 AM
Subject: Re: [PHP-DEV] suggestion: empty() with infinite parameters like
isset()
Maybe it was a bad example. Writing data missing I was thinking that
at
least one variable should be set.
Ron
Derick Rethans [EMAIL PROTECTED] schreef in bericht
news:[EMAIL PROTECTED]
On Wed, 20 Oct 2004, Ron Korving wrote:
Okay, I don't wanna make remarks that may have already been made
earlier,
but I think it should be all should be empty, because it works
exactly
the
same for isset(), and apparently, a decision was made to give
isset()
that
feature.
Right, but then your example would already no longer have worked:
if (empty($var1, $var2, $var3)) echo data missing;
so there is no point in adding it like that.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
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: [sqlite] PHP5 SQLite3
Andi Gutmans wrote:
At 01:29 PM 10/20/2004 +0100, Wez Furlong wrote:
PDO is something that quite a few of us want to see as the recommended
database API for PHP 5.1. We haven't laid any definite plans for the
5.1 feature list yet (it's probably a good time for us to start
thinking about that here on internals@) so there is not yet an
official line on PDO or SQLite 3.
Hi Wez,
I definitely think it's starting to become time to talk about what's
going to be in PHP 5.1. I see the main features I would like to see in
5.1 as:
a) PDO support for most popular DBs. Maybe you can give a status report
of where PDO is today and how much work it still requires? If it
requires a lot of work maybe more people can join the effort. Also is
there an online phpDoc of each DB API one can look at? I've looked at
the source code and at the functionality and it's pretty good but I'll
definitely try and look deeper as we get closer to 5.1.
b) New VM architecture, some other core engine changes which have
happened since 5.0.x.
c) Polish some left overs in the OO model from 5.0.x, mainly the access
modifiers (if/when they are allowed to be used). For example, in
interfaces they shouldn't be used. Probably some error handling and bug
reports which still require attention.
d) Finalize the few tiny new features request on the language level from
5.1.
e) I agree with Derick, internationalization support is a good one
f) if at all possible, It would be very good if the exception signature
could be modified to accept another exception object as a third
parameter. Why?
try {
// blah
} catch (SubException $e) {
throw new ParentException('message', CODE, $e);
}
.
class ParentException extends Exception
{
function __toString()
{
$current = parent::__toString();
if ($arr = $this-getCauses()) {
$current .= \nThis exception caused by:\n
foreach ($arr as $e) {
$current .= $e-__toString();
}
}
return $current;
}
}
This will allow chaining of exceptions, as they can be designed to do
already, but in a simple, standardized way. It would not need to affect
uncaught exceptions, but __toString() could take advantage of
getCauses() to spit out this information.
see pear-core/PEAR/Exception.php for userland example. I'd like to
remove as much logic from this class as humanly possible, and
concentrate its efforts on display of information only.
If this sounds like a worthy effort, should I open a feature request?
Thanks,
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] suggestion: empty() with infinite parameters like isset()
On Thu, 21 Oct 2004, David Vance wrote: but how would you find out which var's, if any, are empty or not set? otherwise, would seem not very useful... Right, please take this discussion off-list as we have had it in the past and came to the conclusion that there is no way to do this in a sane way. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [sqlite] PHP5 SQLite3
I think this is something which belongs to user-land. I don't see a reason
not to implement it in that way.
Andi
At 11:04 AM 10/21/2004 -0400, Greg Beaver wrote:
f) if at all possible, It would be very good if the exception signature
could be modified to accept another exception object as a third
parameter. Why?
try {
// blah
} catch (SubException $e) {
throw new ParentException('message', CODE, $e);
}
.
class ParentException extends Exception
{
function __toString()
{
$current = parent::__toString();
if ($arr = $this-getCauses()) {
$current .= \nThis exception caused by:\n
foreach ($arr as $e) {
$current .= $e-__toString();
}
}
return $current;
}
}
This will allow chaining of exceptions, as they can be designed to do
already, but in a simple, standardized way. It would not need to affect
uncaught exceptions, but __toString() could take advantage of getCauses()
to spit out this information.
see pear-core/PEAR/Exception.php for userland example. I'd like to remove
as much logic from this class as humanly possible, and concentrate its
efforts on display of information only.
If this sounds like a worthy effort, should I open a feature request?
Thanks,
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug fix for #29770, but for PHP 4.3.9
If anybody cares, here is fix for this bug under 4.3.9: http://leya.mindnever.org/~mr_w/php-popen.patch.gz PS, didn't have time to look at PHP 5 yet, but I suppose this fix could work also with minor tweaks. -- Vladimir Zidar, Programmer MindNever Foodstuff TRDG. Head Office Branch Tel: +381-63-550161, +385-98-9574261 http://www.mindnever.org, icq: 15414204, mail: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [sqlite] PHP5 SQLite3
Probably covered by your engine point: please get __toString() to work
properly with string concatenation and casting :)
Thanks,
Jevon
- Original Message -
From: Andi Gutmans [EMAIL PROTECTED]
To: Greg Beaver [EMAIL PROTECTED]
Cc: internals [EMAIL PROTECTED]
Sent: Friday, October 22, 2004 5:55 AM
Subject: Re: [PHP-DEV] Re: [sqlite] PHP5 SQLite3
I think this is something which belongs to user-land. I don't see a reason
not to implement it in that way.
Andi
At 11:04 AM 10/21/2004 -0400, Greg Beaver wrote:
f) if at all possible, It would be very good if the exception signature
could be modified to accept another exception object as a third
parameter. Why?
try {
// blah
} catch (SubException $e) {
throw new ParentException('message', CODE, $e);
}
.
class ParentException extends Exception
{
function __toString()
{
$current = parent::__toString();
if ($arr = $this-getCauses()) {
$current .= \nThis exception caused by:\n
foreach ($arr as $e) {
$current .= $e-__toString();
}
}
return $current;
}
}
This will allow chaining of exceptions, as they can be designed to do
already, but in a simple, standardized way. It would not need to affect
uncaught exceptions, but __toString() could take advantage of getCauses()
to spit out this information.
see pear-core/PEAR/Exception.php for userland example. I'd like to
remove
as much logic from this class as humanly possible, and concentrate its
efforts on display of information only.
If this sounds like a worthy effort, should I open a feature request?
Thanks,
Greg
--
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] PHP 5.1 roadmap
a) PDO support for most popular DBs. Maybe you can give a status report of where PDO is today and how much work it still requires? If it requires a lot of work maybe more people can join the effort. Also is there an online phpDoc of each DB API one can look at? I've looked at the source code and at the functionality and it's pretty good but I'll definitely try and look deeper as we get closer to 5.1. Feature-wise, it's missing scrollable (eg: random access) cursors and Marcus' iterators (sorry Marcus). We also discussed a change in the error codes to match the standard SQLSTATE codes found in ODBC. There could be a couple of other bits and pieces that I've forgotten for the moment, but nothing major. None of these are particularly huge tasks; a couple of days good hacking will have them wrapped up. Aside from that, PDO is very usable for the most common data access patterns that you are likely to use in PHP. Driver wise, we have a nice collection. The only major driver that we are missing is mysql 4.x (we have 3.x). Documentation-wise, a couple of people I spoke to in Toronto offered to write some docs for PDO, but I haven't heard any news on this yet. b) New VM architecture, some other core engine changes which have happened since 5.0.x. c) Polish some left overs in the OO model from 5.0.x, mainly the access modifiers (if/when they are allowed to be used). For example, in interfaces they shouldn't be used. Probably some error handling and bug reports which still require attention. d) Finalize the few tiny new features request on the language level from 5.1. - int64_t support in zvals... or some other way of natively handling larger integers without having to dip into floats. I'd prefer the former; this is something that is getting more important now that we have more and more extensions that use 64bit values; mostly database extensions, but also large file support could do with a 64bit type. - large file support in streams. Been discussing this with Edin and Stig recently; the changes are not major, although we would really benefit from a 64bit type for the stat() related functions. This next one is likely to be controversial, but I think we should give it some thought: - unicode support for strings. Tricky topic this one. It would be nice to have some kind of engine level support, but I can't think of a nice way to do it that won't break existing scripts. Instead, it would be nice if we had some kind of String class (would be nice to use that as the class name...) that used the overloading features of the engine to make it smell like a regular string. It would be aware of, at least, the most common charset encodings (and perhaps be able to load in tables for others at runtime) and have methods to concatentate, split, index by character position (not byte position) etc. etc. and handle differences in character encodings transparently. This can be developed as a PECL extension for now, but once it matures it would be very nice to see it in the default distribution. I believe that Derick is working on code for transliteration (that just went into PECL CVS) that could also be folded into this. Another tricky topic (implementation wise; the serializer code is nasty): - a better serialization interface for objects. It would be *very* nice if we had a more flexible API to cater for the serialization interfaces found in COM, Java, .Net, Corba etc. While we're at it, maybe we can fix the really poor performance issue I mentioned a while back; it was massively faster to var_export() and eval() a large array than it was to serialize() and deserialize() it. Depending on the status of PDO it'd be good to have some timeframe for RC1 just so that we have some soft date to work towards. I move to USA in a week, so the next 2 weeks are going to be a bit busy for me, but I should have a bit more hacking time after the move; PDO should be wrapped up really soon. --Wez. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1 roadmap
Aside from that, PDO is very usable for the most common data access patterns that you are likely to use in PHP. Driver wise, we have a nice collection. The only major driver that we are missing is mysql 4.x (we have 3.x). The FBSQL driver is almost done, and when that happens Iøll start on MSSQL/TDS. - Frank -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
