Re: [PHP-DEV] ext/filter, add input_get_args, support of scalar or array result

2006-05-02 Thread Rasmus Lerdorf

Pierre wrote:

I put a small example here:
http://pecl.php.net/~pierre/filter_input_get_args_example.phps

and the patch:
http://pecl.php.net/~pierre/patch_filter_input_get_args.txt


I think this looks ok.  I have been trying to come up with a shorter and 
cleaner syntax to specify these things, but so far I haven't come up 
with anything I really like.  The closest I have come is something like 
this:


$args = array(
'product_id'   = 'Enc',
'component'= 'Int:Array:1-10',
'versions' = 'Enc',
'doesnotexist' = 'Int',
'testscalar'   = 'Int:Scalar',
'testarray'= 'Int:Array'
);

But I am not completely happy with the magic shortcuts in the strings 
there.  The above would be equivalent to:


$args = array(
'product_id'= FILTER_SANITIZE_ENCODED,
'component' = array('filter'= FILTER_VALIDATE_INT,
 'flags'= FILTER_FLAG_ARRAY,
 'options'= array(min_range=1, 
max_range=10)

),
'versions'  = FILTER_SANITIZE_ENCODED,
'doesnotexist'  = FILTER_VALIDATE_INT,
'testscalar'= array(
'filter' = FILTER_VALIDATE_INT,
'flags'  = FILTER_FLAG_SCALAR,

),
'testarray'= array(
'filter' = FILTER_VALIDATE_INT,
'flags'  = FILTER_FLAG_ARRAY,
)

);

-Rasmus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] php 5.2.0

2006-05-02 Thread Lukas Smith

Hi,

I updated my phptodo wiki for the next planned release. Ilia also send 
me a bunch of items that I threw on there:

http://oss.backendmedia.com/PhP52

If you want me to be your personal secretary let me know what items you 
are missing from the list, what items should be assigned to specific 
people and finally what items are completed.


regards,
Lukas

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] ext/filter, add input_get_args, support of scalar or array result

2006-05-02 Thread Pierre
Hi Rasmus,

Thanks for the feedback, it is appreciated :-)

On 5/2/06, Rasmus Lerdorf [EMAIL PROTECTED] wrote:
 Pierre wrote:
  I put a small example here:
  http://pecl.php.net/~pierre/filter_input_get_args_example.phps
 
  and the patch:
  http://pecl.php.net/~pierre/patch_filter_input_get_args.txt
 
 I think this looks ok.  I have been trying to come up with a shorter
 and cleaner syntax to specify these things, but so far I haven't come
 up with anything I really like.  The closest I have come is something
 like this:
 
 $args = array(
  'product_id'   = 'Enc',
  'component'= 'Int:Array:1-10',
  'versions' = 'Enc',
  'doesnotexist' = 'Int',
  'testscalar'   = 'Int:Scalar',
  'testarray'= 'Int:Array'
 );
 
 But I am not completely happy with the magic shortcuts in the strings
 there. 

I had the same problem, it is hard to make them shorter and still easy
to remember or as fast as constants. One of my idea was to create a
filter class, both for the functions
and the constants:

FILTER::TO_INT,FILTER::TO_ENCODED
filter::get() (input_get),  filter::data() (filter_data,
filter::isset() (filter_has_variable),...

We gain a few chars and a bit of visibility. The :: separator makes the
real constant easier to read. See an example at the end of this mail:

$args = array(
  'product_id'= FILTER::TO_ENCODED,
  'component' = array('filter'= FILTER::TO_INT,
   'flags' = FILTER::ARRAY,
   'options'   = array(min_range=1,
  max_range=10)
  ),
  'versions'  = FILTER::TO_ENCODED,
  'doesnotexist'  = FILTER::TO_INT,
  'testscalar'= array(
  'filter' = FILTER::TO_INT,
  'flags'  = FILTER::SCALAR,
 
  ),
  'testarray'= array(
  'filter' = FILTER::TO_INT,
  'flags'  =FILTER::ARRAY,
  )
 
);

I will then remove the duplicated code and clean the patch, add some
tests and commit.

What do you think to change input_get to behave like input_get_args?
invalid data uses false and not found NULL.

Cheers,

-- Pierre

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] php-4.4.3

2006-05-02 Thread Dmitry Dartz
Are there any plans on releasing 4.4.3 in foreseeable future?

TIA,
Dmitry.



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



RE: [PHP-DEV] ext/filter, add input_get_args, support of scalar orarray result

2006-05-02 Thread Jared Williams
 

 -Original Message-
 From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED] 
 Sent: 02 May 2006 07:42
 To: [EMAIL PROTECTED]
 Cc: internals@lists.php.net
 Subject: Re: [PHP-DEV] ext/filter, add input_get_args, 
 support of scalar orarray result
 
 Pierre wrote:
  I put a small example here:
  http://pecl.php.net/~pierre/filter_input_get_args_example.phps
  
  and the patch:
  http://pecl.php.net/~pierre/patch_filter_input_get_args.txt
 
 I think this looks ok.  I have been trying to come up with a 
 shorter and cleaner syntax to specify these things, but so 
 far I haven't come up with anything I really like.  The 
 closest I have come is something like
 this:
 
 $args = array(
  'product_id'   = 'Enc',
  'component'= 'Int:Array:1-10',
  'versions' = 'Enc',
  'doesnotexist' = 'Int',
  'testscalar'   = 'Int:Scalar',
  'testarray'= 'Int:Array'
 );

Would a little helper function to create the array be a little neater (and less 
typing :) for the more common complex options?
 
$args = array(
 'component' = somefunc(FILTER_VALIDATE_INT, FILTER_FLAG_ARRAY, 1, 10);
 );

 
 But I am not completely happy with the magic shortcuts in the 
 strings there.  The above would be equivalent to:
 
 $args = array(
  'product_id'= FILTER_SANITIZE_ENCODED,
  'component' = array('filter'= FILTER_VALIDATE_INT,
   'flags'= FILTER_FLAG_ARRAY,
   'options'= array(min_range=1, 
 max_range=10)
  ),
  'versions'  = FILTER_SANITIZE_ENCODED,
  'doesnotexist'  = FILTER_VALIDATE_INT,
  'testscalar'= array(
  'filter' = FILTER_VALIDATE_INT,
  'flags'  = FILTER_FLAG_SCALAR,
 
  ),
  'testarray'= array(
  'filter' = FILTER_VALIDATE_INT,
  'flags'  = FILTER_FLAG_ARRAY,
  )
 
 );

Jared

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] php 5.2.0

2006-05-02 Thread Ilia Alshanetsky
Heh, Lukas preempted by e-mail a bit, but the bottom line is that the  
next release in the 5.X series is going to be 5.2.0. Being a minor  
version release we have a greater amount of freedom then the one we  
normally get for patch level releases and that's exactly what we need  
for some of the changed being planned. Basically for the next week, I  
would like to assemble a list of changes (using Lukas' wiki) that we  
wish to integrate into this release and then make a new branch. Once  
that is the final list will be published and we will start on a 3  
month release cycle, where the 1st month is allotted towards making  
the big changes and the remaining 2 months to get things stable. So,  
if you have changes you'd like to see in 5.2 (don't go too wild  
now ;-) ), reply to this e-mail.



On 2-May-06, at 6:07 AM, Lukas Smith wrote:


Hi,

I updated my phptodo wiki for the next planned release. Ilia also  
send me a bunch of items that I threw on there:

http://oss.backendmedia.com/PhP52

If you want me to be your personal secretary let me know what items  
you are missing from the list, what items should be assigned to  
specific people and finally what items are completed.


regards,
Lukas

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php




Ilia Alshanetsky
Advanced Internet Designs Inc.
[EMAIL PROTECTED]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] Filter, doc updated

2006-05-02 Thread Pierre
Hello,

Until we have a phpdoc entry for pecl filter, I added a page to Lukas'
wiki, it is Derick's initial spec but reflecting the current state:

http://oss.backendmedia.com/PeclFilter

Feel free to fix typos or improve the text.

Cheers,
-- 
Pierre

Did I help you? Please donate
http://blog.thepimp.net/index.php/1998/04/12/57-please-donate

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Filter, doc updated

2006-05-02 Thread ondrej
Quoting Pierre [EMAIL PROTECTED]:

 Until we have a phpdoc entry for pecl filter, I added a page to Lukas'
 wiki, it is Derick's initial spec but reflecting the current state:
 
 http://oss.backendmedia.com/PeclFilter

I'm missing something like INPUT_REQUEST source. In many situations I don't care
about source of value (GET/POST/COOKIE). I'm only need value.

-- 
Ondrej Ivanic
([EMAIL PROTECTED])

-
This mail sent through IMP: http://horde.org/imp/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Filter, doc updated

2006-05-02 Thread Pierre
On Tue,  2 May 2006 15:56:35 +0200
[EMAIL PROTECTED] wrote:

 Quoting Pierre [EMAIL PROTECTED]:
 
  Until we have a phpdoc entry for pecl filter, I added a page to
  Lukas' wiki, it is Derick's initial spec but reflecting the current
  state:
  
  http://oss.backendmedia.com/PeclFilter
 
 I'm missing something like INPUT_REQUEST source. In many situations I
 don't care about source of value (GET/POST/COOKIE). I'm only need
 value.
 

It is planed. The code is already here at least. But I have to test it
and see if it works.

-- 
Pierre

Did I help you? Please donate
http://blog.thepimp.net/index.php/1998/04/12/57-please-donate

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] php 5.2.0

2006-05-02 Thread Andi Gutmans
Any reason why sqlite (pdo  ext/) can't be compiled without the 
bundled sqlite. Requiring the use of the bundled sqlite can cause 
symbol conflicts when another Apache module is linked with the system version?

If there's no reason, anyone who volunteers to fix it?

Thx.

At 03:07 AM 5/2/2006, Lukas Smith wrote:

Hi,

I updated my phptodo wiki for the next planned release. Ilia also 
send me a bunch of items that I threw on there:

http://oss.backendmedia.com/PhP52

If you want me to be your personal secretary let me know what items 
you are missing from the list, what items should be assigned to 
specific people and finally what items are completed.


regards,
Lukas

--
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] php 5.2.0

2006-05-02 Thread Ron Korving
Well, I'm in no position to ask anyone for anything, but... here goes anyway
;)

APC is a good caching mechanism, but is lacking in optimization features,
where for example (to my knowledge anyway) Zend Optimizer is doing a good
job. Since it looks like APC is going to be included in PHP 6 by default,
maybe it's getting more and more interesting to invest time in optimization
algorithms to enhance APC? I think it's probably the one area in which the
most performance gain for users can be achieved.

- Ron


Ilia Alshanetsky [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
 Heh, Lukas preempted by e-mail a bit, but the bottom line is that the
 next release in the 5.X series is going to be 5.2.0. Being a minor
 version release we have a greater amount of freedom then the one we
 normally get for patch level releases and that's exactly what we need
 for some of the changed being planned. Basically for the next week, I
 would like to assemble a list of changes (using Lukas' wiki) that we
 wish to integrate into this release and then make a new branch. Once
 that is the final list will be published and we will start on a 3
 month release cycle, where the 1st month is allotted towards making
 the big changes and the remaining 2 months to get things stable. So,
 if you have changes you'd like to see in 5.2 (don't go too wild
 now ;-) ), reply to this e-mail.


 On 2-May-06, at 6:07 AM, Lukas Smith wrote:

  Hi,
 
  I updated my phptodo wiki for the next planned release. Ilia also
  send me a bunch of items that I threw on there:
  http://oss.backendmedia.com/PhP52
 
  If you want me to be your personal secretary let me know what items
  you are missing from the list, what items should be assigned to
  specific people and finally what items are completed.
 
  regards,
  Lukas
 
  -- 
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
 
 

 Ilia Alshanetsky
 Advanced Internet Designs Inc.
 [EMAIL PROTECTED]

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] php 5.2.0

2006-05-02 Thread Rasmus Lerdorf

Ron Korving wrote:

Well, I'm in no position to ask anyone for anything, but... here goes anyway
;)

APC is a good caching mechanism, but is lacking in optimization features,
where for example (to my knowledge anyway) Zend Optimizer is doing a good
job. Since it looks like APC is going to be included in PHP 6 by default,
maybe it's getting more and more interesting to invest time in optimization
algorithms to enhance APC? I think it's probably the one area in which the
most performance gain for users can be achieved.


Not sure what this has to do with PHP 5.2.0, but yes, improving the 
optimizer has been on the todo for a while.  Volunteers are welcome.


-Rasmus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] php 5.2.0

2006-05-02 Thread Ilia Alshanetsky
While adding an optimizer to APC is definitely a good thing, but  
ultimately APC is an external tool, we want to make the language  
itself to become faster. There are series of things that became a bit  
slower since 4.4, some have been resolved, others are still pending.  
These are the things 5.2 will attempt to address.



On 2-May-06, at 1:44 PM, Ron Korving wrote:

Well, I'm in no position to ask anyone for anything, but... here  
goes anyway

;)

APC is a good caching mechanism, but is lacking in optimization  
features,
where for example (to my knowledge anyway) Zend Optimizer is doing  
a good
job. Since it looks like APC is going to be included in PHP 6 by  
default,
maybe it's getting more and more interesting to invest time in  
optimization
algorithms to enhance APC? I think it's probably the one area in  
which the

most performance gain for users can be achieved.



Ilia Alshanetsky
Advanced Internet Designs Inc.
[EMAIL PROTECTED]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] curl_multi_info_read patch review

2006-05-02 Thread Brian J. France
Some guys at work created this patch and have been running with it  
for a while now.


Could I get a few more eyeballs on this?

http://www.brianfrance.com/software/php/curl_multi_read.patch

Quote from our internal bug:

  The attached patch implements curl_multi_info_read(), as well as  
fixing some memory leak issues and reference problems in the original  
source.


Should I keep it internal or commit it?

Thanks,

Brian

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] Summer of Code

2006-05-02 Thread anatoly techtonik
||*()*|| Hi, Nuno.

 Google is doing their Summer of Code thing again this year.  You can read
 more about it here: http://code.google.com/summerofcode.html

 It doesn't actually mention PHP there yet, but it will soon.  So if you
 are a student and have an interesting idea for a PHP-related project,
 start thinking about your proposal.

 For eligibility see:

   http://code.google.com/summfaq.html#who_is_eligible

 and the rest of the FAQ as well I guess.

 -Rasmus

NL Ah great! :)

NL This year I might participate. I would like to do something in the core or
NL even in the zend engine. I'll think in something.. (I'm also open to
NL suggestions, of course).

NL I would also like to propose a project related with the documentation team,
NL which is very useful to us:
NL  * working on livedocs (rewriting the indexer, improving docbook compat,
NL pear/gtk/smarty docs support, php 6 support, etc..)


Too bad your letter was lost in my usual phpdoc traffic. I wish we
could discuss this this a little bit earlier and review RFC/ with howto/
to analyse the progress so far and plan the future steps for PHPDOC.
This can help to guide sporadic PHPDOC tools development to make it more
popular and clear among those potential ones from millions of PHP addicts,
who is able and willing to help given that bottlenecks and stone blocks are
removed from the steep enough learning curve.


What I would like to see is:
1. Visibility of PHPDOC software architecture and process

  I guess for phpdoc/ howto is a good draft, but lacks some
  pictures.   There can be additional chapter about how the
  docs are born and uploaded and who is involved in the
  process. Clear entrypoint to PHPDOC tools world is also
  must have, because amount of information can be frustating.

2. Issue tracker

  PHP bugtracker is good, well-tested, but not suitable for
  maintaining issues. Issue (in my vision) can not be bogus.
  Issue is a step in more general plan and it need to be
  resolved for the plan to be succeeded. Plan is an idea.
  Ideas can be possible or impossible. Possible ideas depend
  on resources. Impossible ideas are just that - impossible,
  but still contain explanation why (stoneblock, like on
  graveyards). Possible ideas, which depend on external factors
  can be frozen to wait for these factors (blockers) to resolve.
  Ideas can be frozen also if resources are scarce or just
  unavailable. To freeze an idea some current status must be
  written. Usually this means that somebody else can pick up
  the idea, resolve blocker issue and he will have every
  available information to fix it. Ideas are not proposals
  - idea is a more mild variant of requirement and issue within
  idea is a detailed specification of what should be done for
  this idea to be archieved. Idea status can be refactored -
  you can always write a different status to outline steps
  in development, keep duscussion focused. Discussions can be
  filtered accordingly, but you can always dig down levels
  to initial discussions. Input for notes or additions to
  issues can be everything - from emails to SVN/CVS commits,
  quotes and links, but with periodical link/consistency checks
  and perhaps even local copies of necessary information (cache).
  This can be used for gathering requirements and elaboration.
  Everything can be RSS'ed.

2. CVS to SVN, SVN as a Livedocs backend

  I can be a little bit misleaded, but it seems to me that
  SVN can be accessed from web application and we can use
  this ability. First idea is online patch generation, where
  user can edit the page (like in wiki), but instead of
  page text he is presented with XML source and preview
  is basically the a patch, which is after automatically
  assigned to an issue. Patch can be approved and directly
  applied to SVN.
  
3. Livedocs AJAX

  I do not know the status of livedocs and the abilities
  of this system to provide describe, validate and modify
  docbook structure. But if this functionality is suitable, we
  can try to move it into AJAX to provide some WYSIWYG features
  keeping internal XML structure in 1:1 with presentation on a
  visually edited web page.

4. PHP.NET API, Web-Services and visual tools

  Just for the Summer of Code. It would be nice to see PHP core to
  invent some advanced techniques (?PHP4EE) to let PHP technology
  make the step from scripting to modeling applications, to use
  abstraction as a survival instrument in complex projects. phpdoc/
  is such complex project.


  It is a lot of work and it is more research work than actual coding.

a. What would we like to achieve?
b. How this could be achieved?
c. What do we have?
d. What is the current status?


a. Convenient tools to communicate, edit PHPDOC documention,
build it and control the process. Easy for new developers.
b. Time, time and time (given you know what to do and how to)
detailed plan, clear idea, steps (milestones), user feedback,
requirements gathering, strong community support. Perhaps 

Re: [PHP-DEV] php 5.2.0

2006-05-02 Thread Andreas Korthaus

Hi!

Ilia Alshanetsky wrote:
So, if you have 
changes you'd like to see in 5.2 (don't go too wild now ;-) ), reply to 
this e-mail.


Some issues not yet in the wiki, which have been discussed on this list 
some time ago:


1. date extension
with OO interface and classname Date (don't forget about the 
PEAR::Date fun ;-))

For the OO interface, AFAIR most people prefered something like:
http://cvs.php.net/viewcvs.cgi/pecl/date/docs/examples/sample1.php?view=markup
to something like: http://www.zend.com/zend/week/date-timezone.txt

2. late static binding (keyword this?)
When using static classes and inheritance, you can't use parent 
methodes/members today


But perhaps that's something for 6.0...

Another idea for a future PHP version:

pecl_http extension implements some really useful features:
http://dev.iworks.at/ext-http/http-functions.html.gz

Perhaps some day, when it's ready... it could implement the 5 functions 
from ext/http too, and replace that extension without any BC-issues...



best regards
Andreas

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] php 5.2.0

2006-05-02 Thread Pierre
On Tue, 02 May 2006 21:25:41 +0200
[EMAIL PROTECTED] (Andreas Korthaus) wrote:

 But perhaps that's something for 6.0...

That's all php 6.0 yes, maybe not http...

-- Pierre

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] php 5.2.0

2006-05-02 Thread Pierre
On Tue, 02 May 2006 10:22:14 -0700
[EMAIL PROTECTED] (Andi Gutmans) wrote:

 Any reason why sqlite (pdo  ext/) can't be compiled without the 
 bundled sqlite.

You can build using an extern sqlite. However you need 3.2.7, I just
noticed that today. I have nothing against requiring it, but it should
be detected and noticed in the changelog. Also a minor release is
maybe not the right time to bump the required version.

As a sidenote, you also need to install sqlite3 in a standard path.
There is actually no way to tell pdo-sqlite which sqlite to use.


-- 
Pierre

Did I help you? Please donate
http://blog.thepimp.net/index.php/1998/04/12/57-please-donate

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] php 5.2.0

2006-05-02 Thread Ilia Alshanetsky


On 2-May-06, at 3:25 PM, Andreas Korthaus wrote:


Hi!

Ilia Alshanetsky wrote:
So, if you have changes you'd like to see in 5.2 (don't go too  
wild now ;-) ), reply to this e-mail.


Some issues not yet in the wiki, which have been discussed on this  
list some time ago:


1. date extension
with OO interface and classname Date (don't forget about the  
PEAR::Date fun ;-))

For the OO interface, AFAIR most people prefered something like:
http://cvs.php.net/viewcvs.cgi/pecl/date/docs/examples/sample1.php? 
view=markup

to something like: http://www.zend.com/zend/week/date-timezone.txt



That is on the list.


2. late static binding (keyword this?)
When using static classes and inheritance, you can't use parent  
methodes/members today




Too big for PHP 5.2 IMHO


But perhaps that's something for 6.0...

Another idea for a future PHP version:

pecl_http extension implements some really useful features:
http://dev.iworks.at/ext-http/http-functions.html.gz

Perhaps some day, when it's ready... it could implement the 5  
functions from ext/http too, and replace that extension without any  
BC-issues...


I'd prefer to wait with addition of new extensions until PHP 6,  
unless there is a majority consensus that we absolutely must have  
this extension in PHP core.



Ilia Alshanetsky
Advanced Internet Designs Inc.
[EMAIL PROTECTED]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Static properties

2006-05-02 Thread Marcus Boerger
Hello Folks,

  Edin and me discussed the issue a bit more in detail and shared memories
of discussions from the original php 5.0 development. As a conclusion we
came to the idea that we should revive the idea of a 'strict flag' that
decides whether member variables (both static and non static) can be added
on the fly by simply using them or not. This would for example look like
this:

strict class FooBar
{
}
$obj = new FooBar;
$obj-baz = 1;  // E_ERROR (a fatal non recoverable error level)

class MyConfig
{
}
MyConfig::$allow_public_access = 1; // works pretty well

Both of us thought this would be a great solution and should suit everybody
in the php world. Also the possible slowdown would be not measurable since
it is only a single integer check that in some cases won't have and
influence on runtime at all.

Any thoughts? Anybody?

best regards
marcus


Thursday, April 27, 2006, 4:35:39 PM, you wrote:

 Hi Marcus,

 Marcus Boerger wrote:
 There was no endless discussion like we to often do on the list but instead
 it was just something we came to agree upon among those implementing it
 while implementing it.

 In other words there was no public discussion whatsoever ;)

 Well since we're are talking about the future direction of PHP, I guess
 the question deserves some attention. I strongly disagree with this
 approach of making PHP more strict and static. I really liked its
 dynamicity and would not like to see it disappear under the pressure
 from people who think Java or C++ (or any other langauge) are cool. For
 me *PHP* is the cool language.

 I would really like to hear what do PHP group members/core developers
 think about this.

class foo{}; foo::$bar = 1;

 To cut the story short, any feature might have an advantage for somebody but
 also a heavy disadvantage for somebody else. But in the end if we'd agree to
 add this feature we#d also end up in supporting interception of static
 properties which we probably do not want.

 Mike has already demonstrated that the patch to implement this
 particular feature is very simple:
 http://dev.iworks.at/PATCHES/dyn_static.txt

 Edin




Best regards,
 Marcus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] Re: curl_multi_info_read patch review

2006-05-02 Thread Sterling Hughes

please commit it, looks good.

thanks,
sterling

On 5/2/06, Brian J. France [EMAIL PROTECTED] wrote:

Some guys at work created this patch and have been running with it
for a while now.

Could I get a few more eyeballs on this?

http://www.brianfrance.com/software/php/curl_multi_read.patch

Quote from our internal bug:

   The attached patch implements curl_multi_info_read(), as well as
fixing some memory leak issues and reference problems in the original
source.

Should I keep it internal or commit it?

Thanks,

Brian



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] php 5.2.0

2006-05-02 Thread Pierre
On Tue, 2 May 2006 22:21:14 +0200
[EMAIL PROTECTED] (Pierre) wrote:

 On Tue, 02 May 2006 10:22:14 -0700
 [EMAIL PROTECTED] (Andi Gutmans) wrote:
 
  Any reason why sqlite (pdo  ext/) can't be compiled without the 
  bundled sqlite.

While testing, I also confirm that ext/sqlite with --with-sqlite=/usr
is also broken. For some unknown reason, it tries to get files and
definitions from ext/sqlite/libsqlite/src/.

-- 
Pierre

Did I help you? Please donate
http://blog.thepimp.net/index.php/1998/04/12/57-please-donate

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: curl_multi_info_read patch review

2006-05-02 Thread Brian J. France

PHP_5_1 and head or just head?

It could be considered bug fix since curl_multi_info_read was there,  
but not implemented.


Brian


On May 2, 2006, at 4:56 PM, Sterling Hughes wrote:

please commit it, looks good.

thanks,
sterling

On 5/2/06, Brian J. France [EMAIL PROTECTED] wrote:

Some guys at work created this patch and have been running with it
for a while now.

Could I get a few more eyeballs on this?

http://www.brianfrance.com/software/php/curl_multi_read.patch

Quote from our internal bug:

   The attached patch implements curl_multi_info_read(), as well as
fixing some memory leak issues and reference problems in the original
source.

Should I keep it internal or commit it?

Thanks,

Brian



--
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: curl_multi_info_read patch review

2006-05-02 Thread Sterling Hughes

not having tested it, i don't know.  this is certainly a RM question,
but if it doesn't break the compile, it does not look like it has the
potential to damage previously existing infrastructure.

-sterling

On 5/2/06, Brian J. France [EMAIL PROTECTED] wrote:

PHP_5_1 and head or just head?

It could be considered bug fix since curl_multi_info_read was there,
but not implemented.

Brian


On May 2, 2006, at 4:56 PM, Sterling Hughes wrote:
 please commit it, looks good.

 thanks,
 sterling

 On 5/2/06, Brian J. France [EMAIL PROTECTED] wrote:
 Some guys at work created this patch and have been running with it
 for a while now.

 Could I get a few more eyeballs on this?

 http://www.brianfrance.com/software/php/curl_multi_read.patch

 Quote from our internal bug:

The attached patch implements curl_multi_info_read(), as well as
 fixing some memory leak issues and reference problems in the original
 source.

 Should I keep it internal or commit it?

 Thanks,

 Brian


 --
 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] php 5.2.0

2006-05-02 Thread Evert Pot

Hi People,

I'm not sure this is the right place to make a feature request, but here 
goes..


I noticed some upgrades/ideas in the streams system lately.. Is there 
any chance at all this can be migrated to an OOP system?


Here's the kind of think i would really like to see (java does it the 
same way, more or less)


2 base stream interfaces
Writer
Reader

Which are implemented by:
FileWriter
FileReader
SocketWriter
SocketReader
StringWriter
StringReader

The Java IO library uses the decorator pattern to add functionality to 
those base classes:


BufferedReader
BufferedWriter
HTMLFilterWriter

Since we are getting a new filter system, this could also be based on 
this stream system


This would allow be to write new base-classes for transports and make 
use of all the existing filter-classes.
Also, this could be unified with XMLReader and XMLWriter and the SPL 
file classes.


This implementation is just a suggestion (and I really like the 
flexibility of the Java IO system).. I'm just really missing a proper 
unified stream system..


Great work has already been done to centralize systems because of the 
introduction of the Traversable interface and its descendants.. but more 
and more often I find myself rewriting PHP extensions in PHP, because 
there's no unified (abstracted) API..


I'm already pretty far in implementing this in PHP, and I would be more 
than happy to PEAR it (if people are interested).. but I feel like a 
system like this belongs at the core to prevent every new subsystem from 
figuring out a new API...


I hope I made my point, I'll be more than happy to eloborate or help 
writing specs for this system, my C skills are mediocre though..


Oh, and thanks for your great work.. PHP is the reason I can pay my rent 
and I know there's a lot of people like me =)


Evert

Ilia Alshanetsky wrote:
Heh, Lukas preempted by e-mail a bit, but the bottom line is that the 
next release in the 5.X series is going to be 5.2.0. Being a minor 
version release we have a greater amount of freedom then the one we 
normally get for patch level releases and that's exactly what we need 
for some of the changed being planned. Basically for the next week, I 
would like to assemble a list of changes (using Lukas' wiki) that we 
wish to integrate into this release and then make a new branch. Once 
that is the final list will be published and we will start on a 3 
month release cycle, where the 1st month is allotted towards making 
the big changes and the remaining 2 months to get things stable. So, 
if you have changes you'd like to see in 5.2 (don't go too wild now 
;-) ), reply to this e-mail.



On 2-May-06, at 6:07 AM, Lukas Smith wrote:


Hi,

I updated my phptodo wiki for the next planned release. Ilia also 
send me a bunch of items that I threw on there:

http://oss.backendmedia.com/PhP52

If you want me to be your personal secretary let me know what items 
you are missing from the list, what items should be assigned to 
specific people and finally what items are completed.


regards,
Lukas

--PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php




Ilia Alshanetsky
Advanced Internet Designs Inc.
[EMAIL PROTECTED]

--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: curl_multi_info_read patch review

2006-05-02 Thread Ilia Alshanetsky
Apply this to HEAD for now, and once I'll review I'll give a you a go  
ahead for PHP_5_2 branch that will be created. For now we'll just add  
it to our 5.2 wiki TODO list.



On 2-May-06, at 5:29 PM, Brian J. France wrote:


PHP_5_1 and head or just head?

It could be considered bug fix since curl_multi_info_read was  
there, but not implemented.


Ilia Alshanetsky
Advanced Internet Designs Inc.
[EMAIL PROTECTED]

P.S. Sterling, you're alive!

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] php 5.2.0

2006-05-02 Thread Marcus Boerger
Hello Evert,

Wednesday, May 3, 2006, 12:09:17 AM, you wrote:

 Hi People,

 I'm not sure this is the right place to make a feature request, but here 
 goes..

 I noticed some upgrades/ideas in the streams system lately.. Is there 
 any chance at all this can be migrated to an OOP system?

 Here's the kind of think i would really like to see (java does it the 
 same way, more or less)

 2 base stream interfaces
 Writer
 Reader

 Which are implemented by:
 FileWriter
 FileReader
 SocketWriter
 SocketReader
 StringWriter
 StringReader

 The Java IO library uses the decorator pattern to add functionality to 
 those base classes:

 BufferedReader
 BufferedWriter
 HTMLFilterWriter

 Since we are getting a new filter system, this could also be based on 
 this stream system

 This would allow be to write new base-classes for transports and make 
 use of all the existing filter-classes.
 Also, this could be unified with XMLReader and XMLWriter and the SPL 
 file classes.

XMLReader/XMLWriter have nothing to do with our streams implementation
though they can leverage them. In fact they follow libxml2's api which
is inspired by C#'s xmlTextReader. Adding functions to that doesn't make
sense at all they are just wrappers that make the libraries api available
to PHP. SPL could be the start of such a thing but right now in no way is
limited to streams stuff. Again it can leverage streams of course and
that at any level.


 This implementation is just a suggestion (and I really like the 
 flexibility of the Java IO system).. I'm just really missing a proper 
 unified stream system..

Flexibility of the cost that it takes a decend programmer years to
understand what plays together in what sense...definitively the
opposit of php's kiss approach.

 Great work has already been done to centralize systems because of the 
 introduction of the Traversable interface and its descendants.. but more 
 and more often I find myself rewriting PHP extensions in PHP, because 
 there's no unified (abstracted) API..

Traversable is a tag necessary to the engine and does not define any API.
The corresponding API is being defined by the two interfaces Iterator and
IteratorAggregate. None of those has anything to do with reading streams.
All that occurs is that SPL gives you a class (SplFileObject) that
simplifies reading files line by line wchih is based on Iterator, giving
it a semantical meaning.

 I'm already pretty far in implementing this in PHP, and I would be more 
 than happy to PEAR it (if people are interested).. but I feel like a 
 system like this belongs at the core to prevent every new subsystem from 
 figuring out a new API...

If you go with such classes be sure to follow established naming conventions
and do not name them simply 'BufferedReader' or even worse 'Reader'.

 I hope I made my point, I'll be more than happy to eloborate or help 
 writing specs for this system, my C skills are mediocre though..

Streams stuff belongs here. You don't want to wait forever when reading
giles do you? However having a pear like, working set of classes interfaces
would be a nice starting point. So your work would be of help of course.

 Oh, and thanks for your great work.. PHP is the reason I can pay my rent 
 and I know there's a lot of people like me =)

 Evert

 Ilia Alshanetsky wrote:
 Heh, Lukas preempted by e-mail a bit, but the bottom line is that the 
 next release in the 5.X series is going to be 5.2.0. Being a minor 
 version release we have a greater amount of freedom then the one we 
 normally get for patch level releases and that's exactly what we need 
 for some of the changed being planned. Basically for the next week, I 
 would like to assemble a list of changes (using Lukas' wiki) that we 
 wish to integrate into this release and then make a new branch. Once 
 that is the final list will be published and we will start on a 3 
 month release cycle, where the 1st month is allotted towards making 
 the big changes and the remaining 2 months to get things stable. So, 
 if you have changes you'd like to see in 5.2 (don't go too wild now 
 ;-) ), reply to this e-mail.


 On 2-May-06, at 6:07 AM, Lukas Smith wrote:

 Hi,

 I updated my phptodo wiki for the next planned release. Ilia also 
 send me a bunch of items that I threw on there:
 http://oss.backendmedia.com/PhP52

 If you want me to be your personal secretary let me know what items 
 you are missing from the list, what items should be assigned to 
 specific people and finally what items are completed.

 regards,
 Lukas

 --PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php



 Ilia Alshanetsky
 Advanced Internet Designs Inc.
 [EMAIL PROTECTED]

 --PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php





Best regards,
 Marcus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] ext/filter, add input_get_args, support of scalar or array result

2006-05-02 Thread Andrei Zmievski

On May 1, 2006, at 11:42 PM, Rasmus Lerdorf wrote:

I think this looks ok.  I have been trying to come up with a shorter 
and cleaner syntax to specify these things, but so far I haven't come 
up with anything I really like.  The closest I have come is something 
like this:


$args = array(
'product_id'   = 'Enc',
'component'= 'Int:Array:1-10',
'versions' = 'Enc',
'doesnotexist' = 'Int',
'testscalar'   = 'Int:Scalar',
'testarray'= 'Int:Array'
);


You should just take Perl approach and use sigils [1].  :)

$args = array(
'product_id'   = '%',
'component'= 'i[1-10]',
'versions' = '%',
'doesnotexist' = 'i',
'testscalar'   = 'i$',
'testarray'= 'i[]'
);

-Andrei

[1] http://en.wikipedia.org/wiki/Sigil_%28computer_programming%29

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] php 5.2.0

2006-05-02 Thread Evert Pot

Hi Marcus,

Thanks for your quick response. First I need to say I'm not really 
trying to compare this with the PHP streams wrappers.. the streams 
wrappers do a lot more than just streaming bytes, they even know about 
files and directories...


Marcus Boerger wrote:

XMLReader/XMLWriter have nothing to do with our streams implementation
though they can leverage them. In fact they follow libxml2's api which
is inspired by C#'s xmlTextReader. Adding functions to that doesn't make
sense at all they are just wrappers that make the libraries api available
to PHP. SPL could be the start of such a thing but right now in no way is
limited to streams stuff. Again it can leverage streams of course and
that at any level.


  
If XMLReader/XMLWriter would work with this streams API, it would allow 
me to pass it through filters before writing/reading from a base stream 
object.. Because everything implements those interfaces, the 
XMLReader/XMLWriter doesnt have to know exactly what it is being fed 
(either a base-stream or a stream decorated by 1 or more filters)
This implementation is just a suggestion (and I really like the 
flexibility of the Java IO system).. I'm just really missing a proper 
unified stream system..



Flexibility of the cost that it takes a decend programmer years to
understand what plays together in what sense...definitively the
opposit of php's kiss approach.

  
I definitely agree on this one.. the api that a developer would use now 
wouldnt have to change and should not become more complicated.. but 
there are also power users..


The eventual API doenst have to look that difficult.. I'm thinking of 
something like :


$file = new FileReader('filename'); // to read just bytes
$file = new HTMLFilterReader(new FileReader('filename')) to filter the html

Writing to a file would work in the exact same way..

Great work has already been done to centralize systems because of the 
introduction of the Traversable interface and its descendants.. but more 
and more often I find myself rewriting PHP extensions in PHP, because 
there's no unified (abstracted) API..



Traversable is a tag necessary to the engine and does not define any API.
The corresponding API is being defined by the two interfaces Iterator and
IteratorAggregate. None of those has anything to do with reading streams.
All that occurs is that SPL gives you a class (SplFileObject) that
simplifies reading files line by line wchih is based on Iterator, giving
it a semantical meaning.

  
The point i tried to make was, because of traversable and its 
descendants, we now can now do a simple thing like :


if ($var instanceof Traversable) echo('And we know we can iterate over 
this object, regardless of the class..');


in the same manner:

if ($var instanceof Writer) echo('Now we know we can call the write() 
method');
I'm already pretty far in implementing this in PHP, and I would be more 
than happy to PEAR it (if people are interested).. but I feel like a 
system like this belongs at the core to prevent every new subsystem from 
figuring out a new API...



If you go with such classes be sure to follow established naming conventions
and do not name them simply 'BufferedReader' or even worse 'Reader'.

  
I used simple names to easily illustrate what i wanted to do.. Java uses 
the same conventions since Java 1.1.
I hope I made my point, I'll be more than happy to eloborate or help 
writing specs for this system, my C skills are mediocre though..



Streams stuff belongs here. You don't want to wait forever when reading
giles do you? However having a pear like, working set of classes interfaces
would be a nice starting point. So your work would be of help of course.

  
I'll be happy to put it in PEAR, although this doesn't give me the power 
I would love to have.


Thanks again,
Evert

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] php 5.2.0

2006-05-02 Thread Wez Furlong

It should already work out-of-the-box if you pass in the prefix to
your sqlite install.

--Wez.

On 5/2/06, Andi Gutmans [EMAIL PROTECTED] wrote:

Any reason why sqlite (pdo  ext/) can't be compiled without the
bundled sqlite. Requiring the use of the bundled sqlite can cause
symbol conflicts when another Apache module is linked with the system version?
If there's no reason, anyone who volunteers to fix it?

Thx.

At 03:07 AM 5/2/2006, Lukas Smith wrote:
Hi,

I updated my phptodo wiki for the next planned release. Ilia also
send me a bunch of items that I threw on there:
http://oss.backendmedia.com/PhP52

If you want me to be your personal secretary let me know what items
you are missing from the list, what items should be assigned to
specific people and finally what items are completed.

regards,
Lukas

--
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



[PHP-DEV] Re: Filter, doc updated

2006-05-02 Thread vrana
 Until we have a phpdoc entry for pecl filter, I added a page to Lukas'
 wiki, it is Derick's initial spec but reflecting the current state:

We already have phpdoc filter documentation:
http://cvs.php.net/phpdoc/en/reference/filter/

Jakub Vrána

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] Seeking 'coalesce' php internal function

2006-05-02 Thread D. Dante Lorenso

All,

I'm sure this has been asked somewhere, but since I see requests for 
features for 5.2 or 6.0, I'd like to add a simple item to the list 
which would be quite useful to me and would simplify and clean up a lot 
of code out there:


   function coalesce(...)

This works much like in the SQL version of the same.  In SQL, the 
function returns the first non-null argument from an arbitrary list.  In 
our use, it should return the first non-empty value from the list:


Example:

   $x = dante;
   $y = ;
   $z = ;

   $value = coalesce($z, $y, $x); // $value = dante

This function would ideally be built into the language and bypass 
warnings about undefined variables like 'empty' does.  It might be nice 
to have several varieties of this function:


   * return first parameter where empty() is FALSE
   * return first parameter where isset() is TRUE

I don't think something like this can NOT be written in userspace 
because the 'isset' and 'empty' checks need to be run before arguments 
can be passed to a user function or warnings will start flying.  A 
function like this simplifies code which used to look like this:


   if (!empty($_POST[postkey])) {
   $value = $_POST[postkey];
   }
   elseif (!empty($_GET[getkey])) {
   $value = $_POST[getkey];
   }
   elseif (!empty($default_value)) {
   $value = $default_value;
   }
   else {
   $value = hard coded value;
   }

Into this:

   $value = coalesce($_POST[postkey], $_GET[getkey], 
$default_value, hard coded value);


Can this be built and included?

Dante

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php