[PHP-DEV] Re: Passing error codes through to PDOException
Joey Smith wrote: Maybe I'm up in the night, but I've just opened 50728 because I discovered that all the PDO drivers had a hardcoded 0 where I would expect to see the driver-specific error - a user reported this in ##PHP on Freenode and I take a stab at writing the patches that would let the individual drivers pass their error code on to the user. They're attached to the bug as comments (the first against the tip of 5.3.2 [svn #293440] and the second against HEAD [svn #293440]) - but I'm also attaching them as udiffs to this email. If there's a reason that the PDOExceptions don't contain their driver-specific error codes, feel free to ignore this. Patch looks good, Ilia put it in - thanks and as Richard said, feel free to send more PDO patches, someone with time/desire to actually do the work is always appreciated ;) Elizabeth M Smith -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] any solution about array_walk with pass-by-reference UseData?
In Online Document say's:
Users may not change the array itself from the callback function. e.g.
Add/delete elements, unset elements, etc. If the array that
array_walk() is applied to is changed, the behavior of this function
is undefined, and unpredictable.
So I'm use Use Optional param( [, mixed $userdata ])
here is my code
$return=array();
$disable_full=array('a','b','c');
$disable_start=array('_','!','HTTP'/*,'ddd','ddd','ddd','ddd','ddd'*/);
$check_array=array(a=1,_POST='c',HTTP=f,ddd=array('fefe'));
array_walk($check_array,'walk_fun_with_foreach',$return);
print_r($return);
function walk_fun_with_foreach($source,$key,$return){
global $disable_full,$disable_start;
//var_dump($key);
if(is_array($source)){
array_walk($source,'walk_fun_with_foreach',$return);
}else{
if(in_array(strval($key),$disable_full)){
//exit;
return;
}else{
foreach($disable_start as $key1 = $value){
if(strpos($key,$value)===0){
//echo $key;
return;
}
}
}
//echo $key;
$return[$key]=$source;
}
}
==
it's print :
Array ( [0] = fefe )
but in version php5.2.x and higher version,display Warning message:
Warning: Call-time pass-by-reference has been deprecated in
If I'm change
array_walk($check_array,'walk_fun_with_foreach',$return);
to
array_walk($check_array,'walk_fun_with_foreach',$return);
and
declare function like
function walk_fun_with_foreach($source,$key,$return)
no Warning Display
But result is not my needed.
Anyone has solution about is?I'm don't like use foreach for
instead,beacuse of some preformance reason.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 5.3 release schedule and other bits
Hello, At Debian we are planning to include PHP 5.3 in Squeeze, the next stable release. As such, I would like to know for example when we could expect 5.3.2 and 5.3.3 to be released. On a slightly different topic, I'd like to express that I would like to improve the communication between us (the package maintainers) and you (the upstream developers). As a first step I'll be trying to forward most of our patches so that there's a minor divergence. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 release schedule and other bits
On Tue, 12 Jan 2010, Raphael Geissert wrote: At Debian we are planning to include PHP 5.3 in Squeeze, the next stable release. As such, I would like to know for example when we could expect 5.3.2 and 5.3.3 to be released. 5.3.2 is on the way, but not sure when exactly it will be released. On a slightly different topic, I'd like to express that I would like to improve the communication between us (the package maintainers) and you (the upstream developers). As a first step I'll be trying to forward most of our patches so that there's a minor divergence. Awesome, does that also mean you'd be willing to listen in case we might think some patches are a bad idea? regards, Derick -- http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org twitter: @derickr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __toString(), __toArray()
Hello,
On Mon, Jan 11, 2010 at 8:32 PM, mm w 0xcafef...@gmail.com wrote:
cast is not needed in PHP
i 'd rather be more interesting in
class Obj {
function __catch($data, $type) {
//$type [ static_method, method, get_property, set_property]
if (observed $type == set_property somevalueIsObserved) {
$observer-notify(somevalue::valueWillChanged);
$this-somevalue = $data['somevalue'];
$observer-notify(somevalue::valueDidChanged);
} else {
continue__call();
}
}
}
What? ...
Etienne Kneuss wrote:
This is where operator over-loading would be useful however perhaps only
explicit casts would make sense here.
I beleive adding a __cast(string $type) would be a useful feature for
me, very often I have a toArray method defined. I agree with you that
due to unexpected edge cases with operator precedence and general type
juggling that __cast should only be called on explicit (cast).
I.E.:
class Int { public function __cast($type) { return 'int' == $type ? 15 : 0; } }
$r = new Int;
var_dump($r + 1); // 2
var_dump((int) $r + 1); // 16
var_dump((bool) $r + 1); // 1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] any solution about array_walk with pass-by-reference UseData?
This might be better served by taking it to php-general, because I don't
think you need to pin your question so hard to the behaviour of
array_walk(). Here's a quick example of (if I understood your question
correctly) how you might solve it using array_udiff_uassoc and 5.3's new
'closure' syntax (not required for this, but I do so enjoy using them!)
?php
$return=array();
$disable_full=array('a','b','c');
$disable_start=array('_','!','HTTP'/*,'ddd','ddd','ddd','ddd','ddd'*/);
$check_array=array(a=1,_POST='c',HTTP=f,ddd=array('fefe'));
function buildFilter($keys, $starts_with) {
return function ($a, $b) use ($keys, $starts_with) {
if (in_array($a, $keys)) return 0;
foreach($starts_with as $value) if (strpos($a, $value)===0) return 0;
return 1;
};
}
$foo = buildFilter($disable_full, $disable_start);
var_dump(array_udiff_uassoc($check_array, $disable_full, $disable_start,
function () { return 0; }, $foo));
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 release schedule and other bits
Derick Rethans wrote: On Tue, 12 Jan 2010, Raphael Geissert wrote: At Debian we are planning to include PHP 5.3 in Squeeze, the next stable release. As such, I would like to know for example when we could expect 5.3.2 and 5.3.3 to be released. 5.3.2 is on the way, but not sure when exactly it will be released. Yes, I've seen the RCs. Hope it doesn't take long. On a slightly different topic, I'd like to express that I would like to improve the communication between us (the package maintainers) and you (the upstream developers). As a first step I'll be trying to forward most of our patches so that there's a minor divergence. Awesome, does that also mean you'd be willing to listen in case we might think some patches are a bad idea? Yes, I'm willing to discuss patches. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Throwing an E_DEPRECATED for short_open_tag
Hi again, Disclaimer: although discussions about this topic tend to be heated (and hated) this is not the usual short_open_tag thread. Please refrain from talking about other previous proposals and whether short_open_tag should be dropped or not. As mentioned on my other post, at Debian we are planning to include 5.3 in Squeeze. Given that the development and production php.ini files both turn short_open_tag by default but many applications shipped by Debian itself still require it to be enabled, we have decided to _enable_ it again on the .ini files. However, we would like to contribute in the quest to make applications stop using short_open_tag. To do so, we have decided to throw an E_DEPRECATED warning when an application makes use of short_open_tag. The current implementation can be found at [1]. How does this sound? [1] http://git.debian.org/?p=pkg- php/php.git;a=blob;f=debian/patches/deprecate_short_open_tag;h=57a79c6215afdc8654c6d18e791a9b7c8f5e373b Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Throwing an E_DEPRECATED for short_open_tag
Raphael Geissert wrote: However, we would like to contribute in the quest to make applications stop using short_open_tag. To do so, we have decided to throw an E_DEPRECATED warning when an application makes use of short_open_tag. The current implementation can be found at [1]. How does this sound? We have no plans to deprecate the short open tag. So throwing an E_DEPRECATED would not be appropriate. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __toString(), __toArray()
don't worry it's only for people who are working with MVC and
RootObject structure, there is too much magics already and __cast is
not needed at all,
as we cannot monkey patch to add an observer on itself, a nice
solution should have a catchable object so __catch any calls
function __catch($data, $type) {
if (method == $type) {
if (data[selector] = 'setValue' observedValueForKeyPath) {
$this-_setValue(($data['arg']);
return;
}
}
continue_natural_call();
}
we could imagine to have a root-object-built-in-class that is
naturally observable, or a root classObject at all, anyway it's only
something for people who are doing OO programming,
so don't worry
On Tue, Jan 12, 2010 at 2:40 PM, Chris Stockton
chrisstockto...@gmail.com wrote:
Hello,
On Mon, Jan 11, 2010 at 8:32 PM, mm w 0xcafef...@gmail.com wrote:
cast is not needed in PHP
i 'd rather be more interesting in
class Obj {
function __catch($data, $type) {
//$type [ static_method, method, get_property, set_property]
if (observed $type == set_property somevalueIsObserved) {
$observer-notify(somevalue::valueWillChanged);
$this-somevalue = $data['somevalue'];
$observer-notify(somevalue::valueDidChanged);
} else {
continue__call();
}
}
}
What? ...
Etienne Kneuss wrote:
This is where operator over-loading would be useful however perhaps only
explicit casts would make sense here.
I beleive adding a __cast(string $type) would be a useful feature for
me, very often I have a toArray method defined. I agree with you that
due to unexpected edge cases with operator precedence and general type
juggling that __cast should only be called on explicit (cast).
I.E.:
class Int { public function __cast($type) { return 'int' == $type ? 15 : 0; }
}
$r = new Int;
var_dump($r + 1); // 2
var_dump((int) $r + 1); // 16
var_dump((bool) $r + 1); // 1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __toString(), __toArray()
How does this have *anything* to do with the discussion at hand?
On Tue, Jan 12, 2010 at 9:09 PM, mm w 0xcafef...@gmail.com wrote:
don't worry it's only for people who are working with MVC and
RootObject structure, there is too much magics already and __cast is
not needed at all,
as we cannot monkey patch to add an observer on itself, a nice
solution should have a catchable object so __catch any calls
function __catch($data, $type) {
if (method == $type) {
if (data[selector] = 'setValue' observedValueForKeyPath) {
$this-_setValue(($data['arg']);
return;
}
}
continue_natural_call();
}
we could imagine to have a root-object-built-in-class that is
naturally observable, or a root classObject at all, anyway it's only
something for people who are doing OO programming,
so don't worry
On Tue, Jan 12, 2010 at 2:40 PM, Chris Stockton
chrisstockto...@gmail.com wrote:
Hello,
On Mon, Jan 11, 2010 at 8:32 PM, mm w 0xcafef...@gmail.com wrote:
cast is not needed in PHP
i 'd rather be more interesting in
class Obj {
function __catch($data, $type) {
//$type [ static_method, method, get_property, set_property]
if (observed $type == set_property somevalueIsObserved) {
$observer-notify(somevalue::valueWillChanged);
$this-somevalue = $data['somevalue'];
$observer-notify(somevalue::valueDidChanged);
} else {
continue__call();
}
}
}
What? ...
Etienne Kneuss wrote:
This is where operator over-loading would be useful however perhaps only
explicit casts would make sense here.
I beleive adding a __cast(string $type) would be a useful feature for
me, very often I have a toArray method defined. I agree with you that
due to unexpected edge cases with operator precedence and general type
juggling that __cast should only be called on explicit (cast).
I.E.:
class Int { public function __cast($type) { return 'int' == $type ? 15 : 0;
} }
$r = new Int;
var_dump($r + 1); // 2
var_dump((int) $r + 1); // 16
var_dump((bool) $r + 1); // 1
--
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] __toString(), __toArray()
the multiplication of magic, the pointed point, need to read more carefully
On Tue, Jan 12, 2010 at 6:10 PM, Eddie Drapkin oorza...@gmail.com wrote:
How does this have *anything* to do with the discussion at hand?
On Tue, Jan 12, 2010 at 9:09 PM, mm w 0xcafef...@gmail.com wrote:
don't worry it's only for people who are working with MVC and
RootObject structure, there is too much magics already and __cast is
not needed at all,
as we cannot monkey patch to add an observer on itself, a nice
solution should have a catchable object so __catch any calls
function __catch($data, $type) {
if (method == $type) {
if (data[selector] = 'setValue' observedValueForKeyPath) {
$this-_setValue(($data['arg']);
return;
}
}
continue_natural_call();
}
we could imagine to have a root-object-built-in-class that is
naturally observable, or a root classObject at all, anyway it's only
something for people who are doing OO programming,
so don't worry
On Tue, Jan 12, 2010 at 2:40 PM, Chris Stockton
chrisstockto...@gmail.com wrote:
Hello,
On Mon, Jan 11, 2010 at 8:32 PM, mm w 0xcafef...@gmail.com wrote:
cast is not needed in PHP
i 'd rather be more interesting in
class Obj {
function __catch($data, $type) {
//$type [ static_method, method, get_property, set_property]
if (observed $type == set_property somevalueIsObserved) {
$observer-notify(somevalue::valueWillChanged);
$this-somevalue = $data['somevalue'];
$observer-notify(somevalue::valueDidChanged);
} else {
continue__call();
}
}
}
What? ...
Etienne Kneuss wrote:
This is where operator over-loading would be useful however perhaps only
explicit casts would make sense here.
I beleive adding a __cast(string $type) would be a useful feature for
me, very often I have a toArray method defined. I agree with you that
due to unexpected edge cases with operator precedence and general type
juggling that __cast should only be called on explicit (cast).
I.E.:
class Int { public function __cast($type) { return 'int' == $type ? 15 : 0;
} }
$r = new Int;
var_dump($r + 1); // 2
var_dump((int) $r + 1); // 16
var_dump((bool) $r + 1); // 1
--
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] __toString(), __toArray()
What you're proposing is just forcing __call, _callStatic, __get and
__set into a single method, which does nothing to reduce the amount of
magic, only obfuscate it. And it certainly offers no alternative to
__cast, at least not that I can see.
On Tue, Jan 12, 2010 at 9:11 PM, mm w 0xcafef...@gmail.com wrote:
the multiplication of magic, the pointed point, need to read more carefully
On Tue, Jan 12, 2010 at 6:10 PM, Eddie Drapkin oorza...@gmail.com wrote:
How does this have *anything* to do with the discussion at hand?
On Tue, Jan 12, 2010 at 9:09 PM, mm w 0xcafef...@gmail.com wrote:
don't worry it's only for people who are working with MVC and
RootObject structure, there is too much magics already and __cast is
not needed at all,
as we cannot monkey patch to add an observer on itself, a nice
solution should have a catchable object so __catch any calls
function __catch($data, $type) {
if (method == $type) {
if (data[selector] = 'setValue' observedValueForKeyPath) {
$this-_setValue(($data['arg']);
return;
}
}
continue_natural_call();
}
we could imagine to have a root-object-built-in-class that is
naturally observable, or a root classObject at all, anyway it's only
something for people who are doing OO programming,
so don't worry
On Tue, Jan 12, 2010 at 2:40 PM, Chris Stockton
chrisstockto...@gmail.com wrote:
Hello,
On Mon, Jan 11, 2010 at 8:32 PM, mm w 0xcafef...@gmail.com wrote:
cast is not needed in PHP
i 'd rather be more interesting in
class Obj {
function __catch($data, $type) {
//$type [ static_method, method, get_property, set_property]
if (observed $type == set_property somevalueIsObserved)
{
$observer-notify(somevalue::valueWillChanged);
$this-somevalue = $data['somevalue'];
$observer-notify(somevalue::valueDidChanged);
} else {
continue__call();
}
}
}
What? ...
Etienne Kneuss wrote:
This is where operator over-loading would be useful however perhaps only
explicit casts would make sense here.
I beleive adding a __cast(string $type) would be a useful feature for
me, very often I have a toArray method defined. I agree with you that
due to unexpected edge cases with operator precedence and general type
juggling that __cast should only be called on explicit (cast).
I.E.:
class Int { public function __cast($type) { return 'int' == $type ? 15 :
0; } }
$r = new Int;
var_dump($r + 1); // 2
var_dump((int) $r + 1); // 16
var_dump((bool) $r + 1); // 1
--
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] __toString(), __toArray()
I am not forcing anything, it's already there, that's definitely a
more useful magic, if people would add a new one, __cast is not
critical, catchable objects are __catch even if exists, so my point I
'd rather see useful requests than a unseful one e.g __cast
from my perspective __toString and __toArray , __callStatic should be
removed __callStatic is definitly a mistake.
On Tue, Jan 12, 2010 at 6:29 PM, Eddie Drapkin oorza...@gmail.com wrote:
What you're proposing is just forcing __call, _callStatic, __get and
__set into a single method, which does nothing to reduce the amount of
magic, only obfuscate it. And it certainly offers no alternative to
__cast, at least not that I can see.
On Tue, Jan 12, 2010 at 9:11 PM, mm w 0xcafef...@gmail.com wrote:
the multiplication of magic, the pointed point, need to read more carefully
On Tue, Jan 12, 2010 at 6:10 PM, Eddie Drapkin oorza...@gmail.com wrote:
How does this have *anything* to do with the discussion at hand?
On Tue, Jan 12, 2010 at 9:09 PM, mm w 0xcafef...@gmail.com wrote:
don't worry it's only for people who are working with MVC and
RootObject structure, there is too much magics already and __cast is
not needed at all,
as we cannot monkey patch to add an observer on itself, a nice
solution should have a catchable object so __catch any calls
function __catch($data, $type) {
if (method == $type) {
if (data[selector] = 'setValue' observedValueForKeyPath) {
$this-_setValue(($data['arg']);
return;
}
}
continue_natural_call();
}
we could imagine to have a root-object-built-in-class that is
naturally observable, or a root classObject at all, anyway it's only
something for people who are doing OO programming,
so don't worry
On Tue, Jan 12, 2010 at 2:40 PM, Chris Stockton
chrisstockto...@gmail.com wrote:
Hello,
On Mon, Jan 11, 2010 at 8:32 PM, mm w 0xcafef...@gmail.com wrote:
cast is not needed in PHP
i 'd rather be more interesting in
class Obj {
function __catch($data, $type) {
//$type [ static_method, method, get_property, set_property]
if (observed $type == set_property
somevalueIsObserved) {
$observer-notify(somevalue::valueWillChanged);
$this-somevalue = $data['somevalue'];
$observer-notify(somevalue::valueDidChanged);
} else {
continue__call();
}
}
}
What? ...
Etienne Kneuss wrote:
This is where operator over-loading would be useful however perhaps only
explicit casts would make sense here.
I beleive adding a __cast(string $type) would be a useful feature for
me, very often I have a toArray method defined. I agree with you that
due to unexpected edge cases with operator precedence and general type
juggling that __cast should only be called on explicit (cast).
I.E.:
class Int { public function __cast($type) { return 'int' == $type ? 15 :
0; } }
$r = new Int;
var_dump($r + 1); // 2
var_dump((int) $r + 1); // 16
var_dump((bool) $r + 1); // 1
--
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] __toString(), __toArray()
Eddie Drapkin wrote:
What you're proposing is just forcing __call, _callStatic, __get and
__set into a single method, which does nothing to reduce the amount of
magic, only obfuscate it. And it certainly offers no alternative to
__cast, at least not that I can see.
I agree, moving all magic to a single function doesn't help the
situation at all, it simply complicates it.
All this talk of too many magic functions is a little comical, its all
trying to overcome operator overloading type functionality in other
languages.
__get()/__set() would be equivalent to getters/setters supported by the
c# language
__toString(), __toArray() would be equivalent to operator String() in
c++ ( if I remember correctly )
I would definitely love to be able to, at the very least, cast an object
to an array but I figured a more general purpose __cast() would be most
beneficial to all.
I think the ambiguity question for some functions accepting mixed as a
parameter type could be solved in aforementioned ways.
On Tue, Jan 12, 2010 at 9:11 PM, mm w 0xcafef...@gmail.com wrote:
the multiplication of magic, the pointed point, need to read more carefully
On Tue, Jan 12, 2010 at 6:10 PM, Eddie Drapkin oorza...@gmail.com wrote:
How does this have *anything* to do with the discussion at hand?
On Tue, Jan 12, 2010 at 9:09 PM, mm w 0xcafef...@gmail.com wrote:
don't worry it's only for people who are working with MVC and
RootObject structure, there is too much magics already and __cast is
not needed at all,
as we cannot monkey patch to add an observer on itself, a nice
solution should have a catchable object so __catch any calls
function __catch($data, $type) {
if (method == $type) {
if (data[selector] = 'setValue' observedValueForKeyPath) {
$this-_setValue(($data['arg']);
return;
}
}
continue_natural_call();
}
we could imagine to have a root-object-built-in-class that is
naturally observable, or a root classObject at all, anyway it's only
something for people who are doing OO programming,
so don't worry
On Tue, Jan 12, 2010 at 2:40 PM, Chris Stockton
chrisstockto...@gmail.com wrote:
Hello,
On Mon, Jan 11, 2010 at 8:32 PM, mm w 0xcafef...@gmail.com wrote:
cast is not needed in PHP
i 'd rather be more interesting in
class Obj {
function __catch($data, $type) {
//$type [ static_method, method, get_property, set_property]
if (observed $type == set_property somevalueIsObserved) {
$observer-notify(somevalue::valueWillChanged);
$this-somevalue = $data['somevalue'];
$observer-notify(somevalue::valueDidChanged);
} else {
continue__call();
}
}
}
What? ...
Etienne Kneuss wrote:
This is where operator over-loading would be useful however perhaps only
explicit casts would make sense here.
I beleive adding a __cast(string $type) would be a useful feature for
me, very often I have a toArray method defined. I agree with you that
due to unexpected edge cases with operator precedence and general type
juggling that __cast should only be called on explicit (cast).
I.E.:
class Int { public function __cast($type) { return 'int' == $type ? 15 : 0; } }
$r = new Int;
var_dump($r + 1); // 2
var_dump((int) $r + 1); // 16
var_dump((bool) $r + 1); // 1
--
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] any solution about array_walk with pass-by-referenceUseData?
Joey Smith wrote:
This might be better served by taking it to php-general, because I don't
think you need to pin your question so hard to the behaviour of
array_walk(). Here's a quick example of (if I understood your question
correctly) how you might solve it using array_udiff_uassoc and 5.3's new
'closure' syntax (not required for this, but I do so enjoy using them!)
They are such an excellent addition to the language
?php
$return=array();
$disable_full=array('a','b','c');
$disable_start=array('_','!','HTTP'/*,'ddd','ddd','ddd','ddd','ddd'*/);
$check_array=array(a=1,_POST='c',HTTP=f,ddd=array('fefe'));
function buildFilter($keys, $starts_with) {
return function ($a, $b) use ($keys, $starts_with) {
if (in_array($a, $keys)) return 0;
foreach($starts_with as $value) if (strpos($a, $value)===0) return 0;
return 1;
};
}
$foo = buildFilter($disable_full, $disable_start);
var_dump(array_udiff_uassoc($check_array, $disable_full, $disable_start,
function () { return 0; }, $foo));
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __toString(), __toArray()
I don't move any magics,I am worried about your knowledge of php,
there's people to give you money ? weird, set get call are only call
when something doesn't exist catch or catch-able concept is to be able
to catch any existing calls no the dynamic ones.
On Tue, Jan 12, 2010 at 6:59 PM, Clint Priest cpri...@warpmail.net wrote:
Eddie Drapkin wrote:
What you're proposing is just forcing __call, _callStatic, __get and
__set into a single method, which does nothing to reduce the amount of
magic, only obfuscate it. And it certainly offers no alternative to
__cast, at least not that I can see.
I agree, moving all magic to a single function doesn't help the situation at
all, it simply complicates it.
All this talk of too many magic functions is a little comical, its all
trying to overcome operator overloading type functionality in other
languages.
__get()/__set() would be equivalent to getters/setters supported by the c#
language
__toString(), __toArray() would be equivalent to operator String() in c++ (
if I remember correctly )
I would definitely love to be able to, at the very least, cast an object to
an array but I figured a more general purpose __cast() would be most
beneficial to all.
I think the ambiguity question for some functions accepting mixed as a
parameter type could be solved in aforementioned ways.
On Tue, Jan 12, 2010 at 9:11 PM, mm w 0xcafef...@gmail.com wrote:
the multiplication of magic, the pointed point, need to read more
carefully
On Tue, Jan 12, 2010 at 6:10 PM, Eddie Drapkin oorza...@gmail.com
wrote:
How does this have *anything* to do with the discussion at hand?
On Tue, Jan 12, 2010 at 9:09 PM, mm w 0xcafef...@gmail.com wrote:
don't worry it's only for people who are working with MVC and
RootObject structure, there is too much magics already and __cast is
not needed at all,
as we cannot monkey patch to add an observer on itself, a nice
solution should have a catchable object so __catch any calls
function __catch($data, $type) {
if (method == $type) {
if (data[selector] = 'setValue' observedValueForKeyPath) {
$this-_setValue(($data['arg']);
return;
}
}
continue_natural_call();
}
we could imagine to have a root-object-built-in-class that is
naturally observable, or a root classObject at all, anyway it's only
something for people who are doing OO programming,
so don't worry
On Tue, Jan 12, 2010 at 2:40 PM, Chris Stockton
chrisstockto...@gmail.com wrote:
Hello,
On Mon, Jan 11, 2010 at 8:32 PM, mm w 0xcafef...@gmail.com wrote:
cast is not needed in PHP
i 'd rather be more interesting in
class Obj {
function __catch($data, $type) {
//$type [ static_method, method, get_property,
set_property]
if (observed $type == set_property
somevalueIsObserved) {
$observer-notify(somevalue::valueWillChanged);
$this-somevalue = $data['somevalue'];
$observer-notify(somevalue::valueDidChanged);
} else {
continue__call();
}
}
}
What? ...
Etienne Kneuss wrote:
This is where operator over-loading would be useful however perhaps
only
explicit casts would make sense here.
I beleive adding a __cast(string $type) would be a useful feature for
me, very often I have a toArray method defined. I agree with you that
due to unexpected edge cases with operator precedence and general type
juggling that __cast should only be called on explicit (cast).
I.E.:
class Int { public function __cast($type) { return 'int' == $type ? 15
: 0; } }
$r = new Int;
var_dump($r + 1); // 2
var_dump((int) $r + 1); // 16
var_dump((bool) $r + 1); // 1
--
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] __toString(), __toArray()
I don't move any magics, I'm worried your knowledge of social skills? Theirs people be your friends? Weird On Jan 12, 2010 9:10 PM, mm w 0xcafef...@gmail.com wrote: I don't move any magics,I am worried about your knowledge of php, there's people to give you money ? weird, set get call are only call when something doesn't exist catch or catch-able concept is to be able to catch any existing calls no the dynamic ones. On Tue, Jan 12, 2010 at 6:59 PM, Clint Priest cpri...@warpmail.net wrote: Eddie Drapkin wr... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub...
Re: [PHP-DEV] __toString(), __toArray()
:-D, without any magic, I am sorry if I hurt you I though you were tougher than a cookie, don't worry about my friends I have plenty on face-cooked, but for God Sake I am still eating alone at noon 8-) On Tue, Jan 12, 2010 at 9:50 PM, Chris Stockton chrisstockto...@gmail.com wrote: I don't move any magics, I'm worried your knowledge of social skills? Theirs people be your friends? Weird On Jan 12, 2010 9:10 PM, mm w 0xcafef...@gmail.com wrote: I don't move any magics,I am worried about your knowledge of php, there's people to give you money ? weird, set get call are only call when something doesn't exist catch or catch-able concept is to be able to catch any existing calls no the dynamic ones. On Tue, Jan 12, 2010 at 6:59 PM, Clint Priest cpri...@warpmail.net wrote: Eddie Drapkin wr... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
