[PHP-DEV] Complete traits redesign for 5.5

2012-12-18 Thread Dmitry Stogov
Hi,

I'm going to take a deep look into trait implementation and provide a
better solution for 5.5.
The current implementation is really wired and makes a lot of troubles for
maintenance and each new fix, makes new troubles :(
I'm really sorry, I didn't pay enough attention to treats before 5.4
release :(

The new solution may significantly change implementation and even behavior
in some cases (e.g https://bugs.php.net/bug.php?id=62069).

I'm going to work on it with top priority during last few days and then
send a patch.
Any ideas are welcome...

Thanks. Dmitry.


Re: [PHP-DEV] Complete traits redesign for 5.5

2012-12-18 Thread Stefan Marr
Hi Dmitry:

On 18 Dec 2012, at 12:37, Dmitry Stogov wrote:

 I'm going to take a deep look into trait implementation and provide a
 better solution for 5.5.
 The current implementation is really wired and makes a lot of troubles for
 maintenance and each new fix, makes new troubles :(
Sorry, that's mostly me lacking understanding of the PHP internals.
And there are many wired corner cases that have to be covered.

 I'm going to work on it with top priority during last few days and then
 send a patch.

Thanks for looking into it.
I'll be able to test things over christmas.

Best regards
Stefan


-- 
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525


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



[PHP-DEV] Extension for str_replace / preg_replace with arrays

2012-12-18 Thread Stefan Neufeind
Hi,

inside a framework-/scripting-project we've lately discussed
string-replacements with arrays.

Currently PHP supports either replacing one string by another or
replacing first element from one array with first from another array.

What I'd like to propose is for str_replace and preg_replace to introduce:
* a functionality to replace one string with strings from an array
* to (optionally) allow for rolling replacements (1,2,3, 1,2,3, ...)
* to (optionally) allow to skip strings already replaced
  (that means not to accidentially double-replace strings)

This would allow to do things like

$content = str_replace('li',
  array('li class=A', 'li class=B', 'li class=C'),
  $content);

optionally starting over from A again. (Current default is to stop when
there are no more elements to replace with).


Would such a change/extension find support?


Kind regards,
 Stefan Neufeind

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



Re: [PHP-DEV] Extension for str_replace / preg_replace with arrays

2012-12-18 Thread Leigh
Both str_replace and preg_replace already support some array based
replacements, I think adding more options to these functions specifically
would just lead to confusion.

What you're proposing can already be achieved quite easily with
preg_replace_callback and passing your array/options into the anonymous
function with `use`, I'd personally welcome a str_replace_callback
counterpart.


On 18 December 2012 12:08, Stefan Neufeind neufe...@php.net wrote:

 Hi,

 inside a framework-/scripting-project we've lately discussed
 string-replacements with arrays.

 Currently PHP supports either replacing one string by another or
 replacing first element from one array with first from another array.

 What I'd like to propose is for str_replace and preg_replace to introduce:
 * a functionality to replace one string with strings from an array
 * to (optionally) allow for rolling replacements (1,2,3, 1,2,3, ...)
 * to (optionally) allow to skip strings already replaced
   (that means not to accidentially double-replace strings)

 This would allow to do things like

 $content = str_replace('li',
   array('li class=A', 'li class=B', 'li class=C'),
   $content);

 optionally starting over from A again. (Current default is to stop when
 there are no more elements to replace with).


 Would such a change/extension find support?


 Kind regards,
  Stefan Neufeind

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




Re: [PHP-DEV] Complete traits redesign for 5.5

2012-12-18 Thread Leigh
Hi Dmitry

On 18 December 2012 11:37, Dmitry Stogov dmi...@zend.com wrote:

 The new solution may significantly change implementation and even behavior
 in some cases (e.g https://bugs.php.net/bug.php?id=62069).


If you have any idea, do you know what the implications of your changes are
on APC?

We're preparing for 5.5 and we still don't have a stable tag of APC for
5.4 yet.

I'd hate to see us in the same situation with 5.5, where people simply will
not upgrade because APC needs massive amounts of work to get it back to a
stable state.


Re: [PHP-DEV] Extension for str_replace / preg_replace with arrays

2012-12-18 Thread Stefan Neufeind
Hi,

On 12/18/2012 01:16 PM, Leigh wrote:
 Both str_replace and preg_replace already support some array based
 replacements, I think adding more options to these functions
 specifically would just lead to confusion.

Well, yes and no. Currently you have to supply either one string to
replace with one other or you have to supply arrays for each of them.
And this wouldn't allow to replace the second, third etc. occurence
different.

Since we already have functionality for replacing with arrays in place,
I wondered if giving it one string to replace and then an array to
choose the replacement from (rotating) would be an option. Currently
that's unsupported (either two strings or two arrays).

 What you're proposing can already be achieved quite easily with
 preg_replace_callback and passing your array/options into the anonymous
 function with `use`, I'd personally welcome a str_replace_callback
 counterpart.

I think you could use a callback-function but would need to add quite a
few more lines to initialise your array first, do a next() on the
array inside the callback-function and (how would you pass it that
array?) and still would have to handle starting from beginning of the
array again once you reach the end etc.


Kind regards,
 Stefan

 On 18 December 2012 12:08, Stefan Neufeind neufe...@php.net
 mailto:neufe...@php.net wrote:
 
 Hi,
 
 inside a framework-/scripting-project we've lately discussed
 string-replacements with arrays.
 
 Currently PHP supports either replacing one string by another or
 replacing first element from one array with first from another array.
 
 What I'd like to propose is for str_replace and preg_replace to
 introduce:
 * a functionality to replace one string with strings from an array
 * to (optionally) allow for rolling replacements (1,2,3, 1,2,3, ...)
 * to (optionally) allow to skip strings already replaced
   (that means not to accidentially double-replace strings)
 
 This would allow to do things like
 
 $content = str_replace('li',
   array('li class=A', 'li class=B', 'li class=C'),
   $content);
 
 optionally starting over from A again. (Current default is to stop when
 there are no more elements to replace with).
 
 
 Would such a change/extension find support?
 
 
 Kind regards,
  Stefan Neufeind

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



Re: [PHP-DEV] Extension for str_replace / preg_replace with arrays

2012-12-18 Thread Leigh
On 18 December 2012 13:24, Stefan Neufeind neufe...@php.net wrote:

 Since we already have functionality for replacing with arrays in place,
 I wondered if giving it one string to replace and then an array to
 choose the replacement from (rotating) would be an option. Currently
 that's unsupported (either two strings or two arrays).


It's certainly possible to implement, but personally it feels like odd
behaviour. I don't know what other people think about it.


 I think you could use a callback-function but would need to add quite a
 few more lines to initialise your array first, do a next() on the
 array inside the callback-function and (how would you pass it that
 array?) and still would have to handle starting from beginning of the
 array again once you reach the end etc.


You pass the array using use. You could do it something like this:

$replacements = array(
'one', 'two', 'three'
);

$result = preg_replace_callback(
'/word/',
function($matches) use ($replacements) {
$current = current($replacements);
next($replacements) || reset($replacements);
return $current;
},
'word word word word word'
);

var_dump($result);

Output:

string(21) one two three one two


[PHP-DEV] How about implementing more data structures (ie Map, Set)

2012-12-18 Thread Victor Berchet

Dear all:

I would like to get your feedback on implementing some more data 
structure in the PHP core.


Things like Set, Map could be really helpful.

A Set would be an unordered collection with no duplicate elements (same 
as in Python)


$setA = new Set();
$setA-append('a');
$setA-append('a');

$setB = new Set();
$setB-append('b');

$setA == $setB;

// A set can hold objects
$set-append($object);

A Map would be an associative array that can hold objects (same as 
Python dictionaries)


$map= new Map();

$map[$setA] = 'Hello, world!';
echo $maps[$setB]; // Hello, world !

I can not really help with the implementation, however I could help 
defining the API, creating a test suite and docs should this idea be 
accepted.


Note: I had to implement this in PHP while working on Automaton, it's 
tedious and inefficient.


Thanks for your feedback,
Victor





Re: [PHP-DEV] How about implementing more data structures (ie Map, Set)

2012-12-18 Thread William Fitch

On Dec 18, 2012, at 9:43 AM, Victor Berchet vic...@suumit.com wrote:

 Dear all:
 
 I would like to get your feedback on implementing some more data structure in 
 the PHP core.
 
 Things like Set, Map could be really helpful.
 
 A Set would be an unordered collection with no duplicate elements (same as in 
 Python)
 
 $setA = new Set();
 $setA-append('a');
 $setA-append('a');
 
 $setB = new Set();
 $setB-append('b');
 
 $setA == $setB;
 
 // A set can hold objects
 $set-append($object);
 
 A Map would be an associative array that can hold objects (same as Python 
 dictionaries)
 
 $map= new Map();
 
 $map[$setA] = 'Hello, world!';
 echo $maps[$setB]; // Hello, world !

Most of what you're looking for can be accomplished by implementing ArrayAccess 
in your own classes, or using the ArrayObject generically like so:

php  $obj = new ArrayObject(array());
php  $obj-append('some string');
php  $obj-append(new ArrayObject(array()));
php  var_dump($obj[1]);
class ArrayObject#4 (0) {
}
php  var_dump($obj[0]);
string(11) some string

For the duplicate issue you're referring to, you'd need to implement your own 
methods for removing (e.g. array_unique).

 
 I can not really help with the implementation, however I could help defining 
 the API, creating a test suite and docs should this idea be accepted.
 
 Note: I had to implement this in PHP while working on Automaton, it's tedious 
 and inefficient.
 
 Thanks for your feedback,
 Victor
 
 
 


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



Re: [PHP-DEV] How about implementing more data structures (ie Map, Set)

2012-12-18 Thread jpauli
On Tue, Dec 18, 2012 at 3:43 PM, Victor Berchet vic...@suumit.com wrote:

 Dear all:

 I would like to get your feedback on implementing some more data structure
 in the PHP core.

 Things like Set, Map could be really helpful.

 A Set would be an unordered collection with no duplicate elements (same as
 in Python)

 $setA = new Set();
 $setA-append('a');
 $setA-append('a');

 $setB = new Set();
 $setB-append('b');

 $setA == $setB;

 // A set can hold objects
 $set-append($object);

 A Map would be an associative array that can hold objects (same as Python
 dictionaries)

 $map= new Map();

 $map[$setA] = 'Hello, world!';
 echo $maps[$setB]; // Hello, world !

 I can not really help with the implementation, however I could help
 defining the API, creating a test suite and docs should this idea be
 accepted.

 Note: I had to implement this in PHP while working on Automaton, it's
 tedious and inefficient.

 Thanks for your feedback,
 Victor



Cool !

I recall some people have already talked about that in the past, have you
read about this ?
So, the process is always the same : wait for ppl feedback, write an RFC,
create patches, testdebug, call for vote, etc.. :-)

Julien.P


Re: [PHP-DEV] How about implementing more data structures (ie Map, Set)

2012-12-18 Thread Ángel González
On 18/12/12 15:43, Victor Berchet wrote:
 Dear all:

 I would like to get your feedback on implementing some more data
 structure in the PHP core.
(...)

I think this could be summarised as allow objects as keys for arrays.
Which would give the Map behavior.
Implementing Set from that is straightforward.


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



Re: [PHP-DEV] How about implementing more data structures (ie Map, Set)

2012-12-18 Thread Anthony Ferrara
Guys,

PHP arrays are a great one-size-fits-all data structure. But like all
one-size-fits-all anything, jack-of-all-trades usually means master of
none.

There are definitely benefits to using specific data structures if
implemented correctly under the hood.

A good example of this is a Queue. Implemented properly using a
Singly-Linked-List or Doubly-Linked-List, inserts are O(1), peeks are O(1)
and removals are O(1). Compare that to an array based
queue implementation where inserts are O(1) and peeks are O(1) but removals
are O(n)... (or inserts and removals are reversed).

For low volume logic, the array can substitute for more custom data
structures quite easily. But for needs with more data (or more
transactions), there's no replacement for a proper data structure...



To the original question:

I would love to see not just more data structures, but better designed ones
in core.

For example, with SPLStack http://php.net/manual/en/class.splstack.php
1. Why the heck does it have unshift() as well as push()? A stack is a
One-way-in, one-way-out data structure, why are both exposed?
2. Why the heck does it implement ArrayAccess? Again, completely defeats
the point of a stack
3. Why does it *extend* DLL? A Stack can be implemented with a DLL, but it
is *not* a DLL. Huge difference...

Now, there was some discussion by some of us about re-doing the entire spl
data structures a while ago. This git repo (PHP) is the evolution of that
idea. https://github.com/morrisonlevi/Ardent

Now it's not written with the explicit intent of replacing SPL. It's
written in an attempt to try to get the data structures designed right.
Then, it may be ported to PECL, and then finally may be proposed to core.


As far as MAP, we already have one:
http://php.net/manual/en/class.splobjectstorage.php

My $0.02 at least,

Anthony


On Tue, Dec 18, 2012 at 1:09 PM, Ángel González keis...@gmail.com wrote:

 On 18/12/12 15:43, Victor Berchet wrote:
  Dear all:
 
  I would like to get your feedback on implementing some more data
  structure in the PHP core.
 (...)

 I think this could be summarised as allow objects as keys for arrays.
 Which would give the Map behavior.
 Implementing Set from that is straightforward.


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




Re: [PHP-DEV] How about implementing more data structures (ie Map, Set)

2012-12-18 Thread Victor Berchet
I am happy to see some interest in this discussion, I'll try to give 
more details in the coming days.


To clarify, my first example should be:

$setA = new Set();
$setA-append('a');
$setA-append('a');

$setB = new Set();
$setB-append('a'); // 'a' instead of 'b'

$setA == $setB;

Cheers,
Victor

On 12/18/2012 07:32 PM, Anthony Ferrara wrote:

Guys,

PHP arrays are a great one-size-fits-all data structure. But like all 
one-size-fits-all anything, jack-of-all-trades usually means master 
of none.


There are definitely benefits to using specific data structures if 
implemented correctly under the hood.


A good example of this is a Queue. Implemented properly using a 
Singly-Linked-List or Doubly-Linked-List, inserts are O(1), peeks are 
O(1) and removals are O(1). Compare that to an array based 
queue implementation where inserts are O(1) and peeks are O(1) but 
removals are O(n)... (or inserts and removals are reversed).


For low volume logic, the array can substitute for more custom data 
structures quite easily. But for needs with more data (or more 
transactions), there's no replacement for a proper data structure...




To the original question:

I would love to see not just more data structures, but better designed 
ones in core.


For example, with SPLStack http://php.net/manual/en/class.splstack.php
1. Why the heck does it have unshift() as well as push()? A stack is a 
One-way-in, one-way-out data structure, why are both exposed?
2. Why the heck does it implement ArrayAccess? Again, completely 
defeats the point of a stack
3. Why does it *extend* DLL? A Stack can be implemented with a DLL, 
but it is *not* a DLL. Huge difference...


Now, there was some discussion by some of us about re-doing the entire 
spl data structures a while ago. This git repo (PHP) is the evolution 
of that idea. https://github.com/morrisonlevi/Ardent


Now it's not written with the explicit intent of replacing SPL. It's 
written in an attempt to try to get the data structures designed 
right. Then, it may be ported to PECL, and then finally may be 
proposed to core.



As far as MAP, we already have one: 
http://php.net/manual/en/class.splobjectstorage.php
If you give a closer look to my example, you will notice a difference: 
$map[$setA] and $map[$setB] point to the same storage which I think is 
not possible with SPLObjectStorage.


My $0.02 at least,

Anthony





Re: [PHP-DEV] How about implementing more data structures (ie Map, Set)

2012-12-18 Thread Anthony Ferrara
Victor,


If you give a closer look to my example, you will notice a difference:
 $map[$setA] and $map[$setB] point to the same storage which I think is not
 possible with SPLObjectStorage.


Well, how could you do that? Without implementing object comparison methods
at least (which is outside the scope of this discussion)? I could see a
type-specific map which knows how to compare the classes, but in general
you'd need to defer comparison to the objects themselves (so $obj1 == $obj2
would fire $obj1-compareTo($obj2) === 0)...

Unless I've got something confused...


Re: [PHP-DEV] How about implementing more data structures (ie Map, Set)

2012-12-18 Thread Victor Berchet


On 12/18/2012 07:46 PM, Anthony Ferrara wrote:

Victor,


If you give a closer look to my example, you will notice a
difference: $map[$setA] and $map[$setB] point to the same storage
which I think is not possible with SPLObjectStorage.

Well, how could you do that? Without implementing object comparison 
methods at least (which is outside the scope of this discussion)? I 
could see a type-specific map which knows how to compare the classes, 
but in general you'd need to defer comparison to the objects 
themselves (so $obj1 == $obj2 would fire $obj1-compareTo($obj2) === 0)...


Unless I've got something confused...
Well let's say that object comparison methods (interface) is part of the 
details that I owe to this thread.


Re: [PHP-DEV] Complete traits redesign for 5.5

2012-12-18 Thread Stas Malyshev
Hi!

 I'm going to take a deep look into trait implementation and provide a
 better solution for 5.5.
 The current implementation is really wired and makes a lot of troubles for
 maintenance and each new fix, makes new troubles :(
 I'm really sorry, I didn't pay enough attention to treats before 5.4
 release :(
 
 The new solution may significantly change implementation and even behavior
 in some cases (e.g https://bugs.php.net/bug.php?id=62069).

Thanks for looking into it! Could you write some description of what
functionality changes are needed and why? An RFC would be helpful, so we
have a definite reference and instead of going through all bug comments
and risking missing something.

BTW, could you after that take a look at bug #63462? It's kind of weird,
and part of it with protected seems to be a bug (same property name is
used both mangled and unmangled when using guards) but I'm not sure yet
what to do with it. I may have time to look into it on the weekend, but
would appreciate second opinion.

Thanks,
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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



[PHP-DEV] Changes in libcurl for CURLOPT_SSL_VERIFYHOST in 7.28.1

2012-12-18 Thread Pierrick Charron
Hi all,

About 2 month ago, we had a discussion on this list about the fact
that CURLOPT_SSL_VERIFYHOST was most of the time used with a Boolean
value (true) instead of int values (0,1 or 2). This bad usage was
leading to some security issues. The result of this discussion was to
trigger a notice if someone tried to set the CURLOPT_SSL_VERIFYHOST to
true (boolean), and was committed to = 5.4

On November 20th, Daniel (the author of libcurl) released cURL 7.28.1
which no longer support the 1 value for CURLOPT_SSL_VERIFYHOST. This
change introduced some bugs as #63795 (you'll find the cause of the
bug in the comments).

To fix this bug, and to minimize as much as possible the impact of
this change, I'm proposing to do the following changes in the libcurl
extension for future releases :

When using libcurl  7.28.1, if someone try to set
CURLOPT_SSL_VERIFYHOST to 1 (or true), set the value to 1, but trigger
a notice to inform that this value is deprecated.

When using libcurl = 7.28.1 if someone try to set
CURLOPT_SSL_VERIFYHOST to 1 (or true), set CURLOPT_SSL_VERIFYHOST to
2, trigger a notice to inform the user that this value is no longer
supported as of libcurl 7.28.1 but keep returning true.

Also, as stated by Remy in bug #63795, when PHP is built with
curl-wrappers, the context option curl_verify_ssl_host sets
CURLOPT_SSL_VERIFYHOST to 1. I would like to modify this code to set
CURLOPT_SSL_VERIFYHOST to 2. Since curl-wrappers is still marked as
experimental I don't think this will cause a lot of troubles.

If you have any comment, please do, otherwise, I'll commit those
changes on Friday to all branches (including 5.3).

Thanks
Pierrick

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



Re: [PHP-DEV] Complete traits redesign for 5.5

2012-12-18 Thread Dmitry Stogov
Hi,

opcode caches support is one of the problem we have with current
implementation.
5.4.10 seems just can't work with any cache at all.
Of course, I'll care about it, and may give suggestions for necessary APC
changes.

Thanks. Dmitry.

On Tue, Dec 18, 2012 at 5:03 PM, Leigh lei...@gmail.com wrote:


 Hi Dmitry

 On 18 December 2012 11:37, Dmitry Stogov dmi...@zend.com wrote:

 The new solution may significantly change implementation and even behavior
 in some cases (e.g https://bugs.php.net/bug.php?id=62069).


 If you have any idea, do you know what the implications of your changes
 are on APC?

 We're preparing for 5.5 and we still don't have a stable tag of APC for
 5.4 yet.

 I'd hate to see us in the same situation with 5.5, where people simply
 will not upgrade because APC needs massive amounts of work to get it back
 to a stable state.



Re: [PHP-DEV] Complete traits redesign for 5.5

2012-12-18 Thread Dmitry Stogov
Hi Stas,

On Wed, Dec 19, 2012 at 1:25 AM, Stas Malyshev smalys...@sugarcrm.comwrote:

 Hi!

  I'm going to take a deep look into trait implementation and provide a
  better solution for 5.5.
  The current implementation is really wired and makes a lot of troubles
 for
  maintenance and each new fix, makes new troubles :(
  I'm really sorry, I didn't pay enough attention to treats before 5.4
  release :(
 
  The new solution may significantly change implementation and even
 behavior
  in some cases (e.g https://bugs.php.net/bug.php?id=62069).

 Thanks for looking into it! Could you write some description of what
 functionality changes are needed and why? An RFC would be helpful, so we
 have a definite reference and instead of going through all bug comments
 and risking missing something.


For now I don't know exactly, what is going to be changed, but it must be
mainly implementation.
I'll try to summarize the required changes, when I know myself.


 BTW, could you after that take a look at bug #63462? It's kind of weird,
 and part of it with protected seems to be a bug (same property name is
 used both mangled and unmangled when using guards) but I'm not sure yet
 what to do with it. I may have time to look into it on the weekend, but
 would appreciate second opinion.


Sure. Assigned to myself.

Thanks. Dmitry.


 Thanks,
 --
 Stanislav Malyshev, Software Architect
 SugarCRM: http://www.sugarcrm.com/
 (408)454-6900 ext. 227