Re: [PHP-DEV] Named parameters
On 10/15/2010 07:26 PM, G M wrote:
Okay so I am thinking about submitting a patch to PHP that would enable you to
call functions like this:
stuff(1, 2, 'separator' = 'br', 'clean' = true);
and define them like this:
/**
* function to do stuff
* @param integer $a
* @param integer $b
* @param string $separator
* Optional, you can override the separator
* @param boolean $clean
* Optional, if true then things are done more cleanly
* @param integer $cool
* Optional. Overrides the default coolness level of 7.
*/
function stuff($a, $b)
{
var_export(func_get_args());
}
Why not change the parser to accept also this:
function stuff($a, $b, optional($separator = 1, $clean = false))
{
}
so that the call
stuff(1, 2, 'separator' = 'br', 'clean' = true)
will output
array(1, 2, 'separator' = 'br', 'clean' = true)
see the consistency? :)
The way I plan to do this is by changing the parser to notice arguments passed
like 'a' = 'b' at the end of the argument list, and pass a hidden array
variable on the stack, so when func_get_args() is called, it will merge this array
on top of what func_get_args would return. I also want to make another function,
func_extract_args which will basically extract the optional arguments, so I can
more easily refer to them as $separator, $clean, etc.
What do you guys think of this? Would it be useful to you? I really hope for
this feature to make it into PHP 6, so I might sit down and code it myself, to
show it can be done.
The reason I really want this to make it into PHP 6 is because I noticed that
function parameter lists just grow with time, and they provide a poor mechanism
for designing nice interfaces. For example I'd hate to write this:
stuff(1, 2, null, 'br', true, null)
as it provides no clue as to what the values are for, and also there are lots of extra
null values I had to pass just so I can specify some optional values. And if
the function had defaults like this:
stuff($a, $b, $c = null, $separator = \n, $clean = false, $cool = 7, $more =
array())
then that would be even worse, as I'd have to re-type the non-null, and if they
ever changed, I'd be out of luck.
All this is solved in a way that extends the array( ) syntax to function
calling (well, almost ... I think it would be cleaner to put all optional
arguments at the end of the argument list, as opposed to interspersing them).
What do you guys think? Would this be useful to you? I personally would use it
all the time and wonder how PHP was without it, but perhaps other people
couldn't care less? Maybe it has some negative side effects that I haven't
thought ot?
Greg
-- Mathieu Suen
Re: [PHP-DEV] inheritance check too strict?
Title: Document sans nom
I consider having type in the declaration of a method a bad idea and
this thread just prove it.
You can also read this:
http://gbracha.blogspot.com/2009/09/systemic-overload.html
On 08/19/2010 10:32 AM, Johannes Schlüter wrote:
On Thu, 2010-08-19 at 01:13 -0700, Stas Malyshev wrote:
Hi!
I was under the impression that, in order for inheritance to provide
proper polymorphism, overridden methods should share the parent's method
signature, although they can have additional optional arguments.
Your impression is wrong. Overriden method should have _compatible_
signature - i.e. accept any argument set that parent object accepted.
Nothing requires it to have the same signature.
Let|s take a look at making it one step more complex:
class A {
public function foo(Foo $a = null) {}
}
class B extends A {
public function foo() {}
}
class C extends B {
public function foo(Bar $a = null) {}
}
Here B::foo() is compatible with A:foo() and as the parameter is
optional C::foo() is compatible with B::foo(). But C::foo() is no more
compatible with A::foo().
So I consider the message good and correct.
johannes
--
• Mathieu
Suen | It Team | www.easyflirt.com
• mathieu
[dot] suen [at] easyflirt [dot] com
• EasyFlirt - Park
Nord, Les Pléiades, 74370 - Metz-Tessy - FRANCE
• Pensez à
l'environnement, n'imprimez cet e-mail qu'en cas de réelle nécessité
Re: [PHP-DEV] Indexing an array
On 08/06/2010 04:42 PM, Gustavo Lopes wrote: On Fri, 06 Aug 2010 15:33:18 +0100, mathieu.suen mathieu.s...@easyflirt.com wrote: Hi, For now you can only index an array using a scalar type or a string. Is there some rfc or work going on to enlarge the possibility so that it is possible to have some other object like: - closure - object - etc. I think the problem with that is how you are going to generate the hash of arbitrary objects in order to store them in the hash table. It's not like all PHP objects have a hashCode() method. IMHO It should. So the only plausible option would be to attribute the same hash to all and the test all for equality on an insertion with a new key or in the worst case scenario for updates and reads. Since php is not referentially transparent I would rather use identity unless object can redefine equality. -- Mathieu Suen
Re: [PHP-DEV] Indexing an array
On 08/06/2010 04:44 PM, Richard Quadling wrote:
On 6 August 2010 15:33, mathieu.suenmathieu.s...@easyflirt.com wrote:
Hi,
For now you can only index an array using a scalar type or a string.
Is there some rfc or work going on to enlarge the possibility so that it is
possible to have some other object like:
- closure
- object
- etc.
Thanks
-- Mathieu Suen
If an object implements a __toString() magic method, then it can work ...
?php
class randomizer {
public function __toString() {
return (string)mt_rand();
}
}
$randomizer = new randomizer;
$array = array (
$randomizer = 'First',
$randomizer = 'Second',
$randomizer = 'Third',
$randomizer = 'Fourth',
);
print_r($array);
?
outputs ...
Array
(
[1365443950] = First
[1235256771] = Second
[520059180] = Third
[486985268] = Fourth
)
Well that is not the expected behavior since if you call array_keys you
won't get the object.
--Mathieu Suen
Re: [PHP-DEV] Indexing an array
On 08/06/2010 07:46 PM, Stas Malyshev wrote: Hi! For now you can only index an array using a scalar type or a string. Is there some rfc or work going on to enlarge the possibility so that it is possible to have some other object like: I think SplObjectStorage implements most common use-case for such behavior, do you have any other one that is not covered there and can't be done by __toString()? Yes but what I don't like with the Spl is that it does not work with the array_* function and the sort function. -- Mathieu Suen
[PHP-DEV] Indexing an array
Hi, For now you can only index an array using a scalar type or a string. Is there some rfc or work going on to enlarge the possibility so that it is possible to have some other object like: - closure - object - etc. Thanks -- Mathieu Suen
Re: [PHP-DEV] Remove variable function and method calls
On 07/23/2010 10:20 AM, Reindl Harald wrote: Would you like to know what is really confusing? mysql_escape_string mysql_real_escape_string So if you have nothing to do try to cleanup this hint: mysql_real_escape_string never should have existed this way and should be dprecated for some relaeses until finally mysql_escape_string does what the user expects Is there a [wiki] page to put all of what need to be clean? -- Mathieu Suen
Re: [PHP-DEV] Suggestion: echo function(var)[0];
Hi
Why not something more generic.
Someone could think of a ValueNode.
Then it could be use for object, array, any primitive type ...
I will take the ValueNode as a non terminal grammar node.
So first we could do that:
ValueNode-method();
ValueNode::sMethod();
ValueNode[];
foo(ValueNode);
echo ValueNode;
$e = ValueNode;
...
And a ValueNode could be define as:
ValueNode :
NewStatement
| FunctionCall
| PrimitiveValue
| '(' ValueNode ')'
| ...;
This would allow all this syntax:
(new A())-foo();
foo(new A());
foo-bar()[1];
foo()[5];
and many others.
On 06/04/2010 03:19 AM, Kalle Sommer Nielsen wrote:
Hi Tig
2010/6/4 Tigtigger...@gmail.com:
Would be at all possible to implement this kind of shortcut?
Its called array-dereferencing and it was proposed countless times,
including by myself. There is an RFC for this[1] and it was planned on
the old PHP6 todo at the PDT[2].
[1] http://wiki.php.net/rfc/functionarraydereferencing
[2] http://wiki.php.net/summits/pdmnotesmay09#php_6 (see point #13)
--Mathieu Suen
Re: [PHP-DEV] Suggestion: echo function(var)[0];
On 06/04/2010 10:00 AM, Richard Quadling wrote:
On 4 June 2010 08:18, mathieu.suenmathieu.s...@easyflirt.com wrote:
Hi
Why not something more generic.
Someone could think of a ValueNode.
Then it could be use for object, array, any primitive type ...
I will take the ValueNode as a non terminal grammar node.
So first we could do that:
ValueNode-method();
ValueNode::sMethod();
ValueNode[];
foo(ValueNode);
echo ValueNode;
$e = ValueNode;
...
And a ValueNode could be define as:
ValueNode :
NewStatement
| FunctionCall
| PrimitiveValue
| '(' ValueNode ')'
| ...;
This would allow all this syntax:
(new A())-foo();
foo(new A());
foo-bar()[1];
foo()[5];
and many others.
On 06/04/2010 03:19 AM, Kalle Sommer Nielsen wrote:
Hi Tig
2010/6/4 Tigtigger...@gmail.com:
Would be at all possible to implement this kind of shortcut?
Its called array-dereferencing and it was proposed countless times,
including by myself. There is an RFC for this[1] and it was planned on
the old PHP6 todo at the PDT[2].
[1] http://wiki.php.net/rfc/functionarraydereferencing
[2] http://wiki.php.net/summits/pdmnotesmay09#php_6 (see point #13)
--Mathieu Suen
Not an expert in this area, but does this mechanism limit you to using
single dimensional arrays?
Of course not as soon as you add array access to a ValueNode
ValueNode
..
| ArrayAccess
...;
This is very simple and it can refactor greatly the parser.
-- Mathieu Suen
Re: [PHP-DEV] Interface and abstract method
Ok so there is no real meaning behind the abstract.
Thanks
On 05/18/2010 05:55 PM, Tjerk Anne Meesters wrote:
Normally, PHP won't allow access types for interface methods, but the
reflection for SPL is defined inside the C code:
static const zend_function_entry spl_funcs_OuterIterator[] = {
SPL_ABSTRACT_ME(OuterIterator, getInnerIterator,
arginfo_recursive_it_void)
{NULL, NULL, NULL}
};
IMO the SPL_ME should be used instead, but I wouldn't be bothered about it ;-)
On Tue, May 18, 2010 at 11:12 PM, mathieu.suen
mathieu.s...@easyflirt.com wrote:
Hi,
In the SPL there is some interface that have abstract method:
*Countable* {
/* Methods */
abstract public int counthttp://www.php.net/manual/en/countable.count.php
( void )
}
While some interface have none abstract method.
*OuterIterator* extends Iterator
http://www.php.net/manual/en/class.iterator.php {
/* Methods */
public Iterator getInnerIterator
http://www.php.net/manual/en/outeriterator.getchildren.php ( void )
..snip..
}
Does abstract keyword have a semantic?
Thanks
--Mathieu suen
-- Mathieu Suen
[PHP-DEV] Interface and abstract method
Hi,
In the SPL there is some interface that have abstract method:
*Countable* {
/* Methods */
abstract public int count
http://www.php.net/manual/en/countable.count.php ( void )
}
While some interface have none abstract method.
*OuterIterator* extends Iterator
http://www.php.net/manual/en/class.iterator.php {
/* Methods */
public Iterator getInnerIterator
http://www.php.net/manual/en/outeriterator.getchildren.php ( void )
..snip..
}
Does abstract keyword have a semantic?
Thanks
--Mathieu suen
Re: [PHP-DEV] Re: Closure local return
On 05/03/2010 05:42 PM, Christian Schneider wrote:
mathieu.suen wrote:
May be it could be interesting to have a syntax for returning from the
define scope.
For example.
$findedElment = $myList-selectIfAbsent($fooo, function(){
return 'No item founded'; //Retrun from the define scope
})
//Do somthing with $findedElment
I think you actually misunderstand the difference in
http://en.wikipedia.org/wiki/Closure_%28computer_science%29#Differences_in_semantics
The way I read if the difference is wether it returns from the closure
function or the surrounding function *calling* it. Not the *defining* scope.
And no, it doesn't make sense in the PHP context IMHO.
You need to give me more argument on that point.
- Chris
-- Mathieu Suen
Re: [PHP-DEV] Re: Closure local return
On 05/03/2010 06:03 PM, Etienne Kneuss wrote:
On Mon, May 3, 2010 at 5:54 PM, mathieu.suenmathieu.s...@easyflirt.com wrote:
I think you actually misunderstand the difference in
http://en.wikipedia.org/wiki/Closure_%28computer_science%29#Differences_in_semantics
The way I read if the difference is wether it returns from the closure
function or the surrounding function *calling* it. Not the *defining*
scope.
And no, it doesn't make sense in the PHP context IMHO.
- Chris
returns from the closure function
To go were?
I had maintain a smalltalk compiler.
I did not misunderstand the difference.
The Common Lisp implementation is the more explicit one.
For exemple:
(defun eval-l1 (fct) (funcall fct))
(defun bar (x) (eval-l1 #'(lambda () (return-from bar 45)))
x)
(bar 23) - 45
When funcall is apply you do not return from eval-l1. You return from bar.
Which is the defining scope of the lanbda.
So
?php
$a = function() { return; }
$a();
echo end;
?
would it be an infinite loop? would it print end?
what about:
?php
function foo($c) {
bar($c);
echo f;
}
function bar($c) {
$c();
echo b;
}
$c = function() { return; }
foo($c);
what would it print? f? fb ? nothing?
This is an interesting question.
It depend on whether you consider your lanbda as a continuation.
The other safe possibility is to generate an error when you evaluate a
lambda
were the context has escape which is the case in your example.
But a would not change the semantic of return just chose an other keyword.
$c = function() { return-from-def-scope; }
Please, if you want to propose design changes, make a decent proposal
first, add some examples, not simply what if PHP didvague.
No big deal, I don't want to make any proposition, I am just asking.
I am not using PHP as a language for fun.
Best,
-- Mathieu Suen
-- Mathieu Suen
Re: [PHP-DEV] Re: Closure local return
On 05/03/2010 11:34 PM, Tjerk Anne Meesters wrote:
On Mon, May 3, 2010 at 11:42 PM, Christian Schneider
cschn...@cschneid.com wrote:
mathieu.suen wrote:
May be it could be interesting to have a syntax for returning from the
define scope.
For example.
$findedElment = $myList-selectIfAbsent($fooo, function(){
return 'No item founded'; //Retrun from the define scope
})
//Do somthing with $findedElment
I think you actually misunderstand the difference in
http://en.wikipedia.org/wiki/Closure_%28computer_science%29#Differences_in_semantics
The way I read if the difference is wether it returns from the closure
function or the surrounding function *calling* it. Not the *defining* scope.
Mathieu is right in that it would return from the defining scope, but
it's important to note that when the closure is called the function
that defined the closure is still on the stack.
Consider the following example:
function f() { return function() { return; } }
$c = f();
$c();
If the semantics of Smalltalk were to apply, this would give an error,
because it's impossible to return from f() when the closure is being
called.
And no, it doesn't make sense in the PHP context IMHO.
I second that ;-) In terms of clarity I find that the ECMAScript
implementation is much clearer.
Of course ECMAScript has the same semantic than PHP. :)
(for this particular point, I don't mean for the rest)
May be one could fink of a different syntax:
function() { return-from-def-scope; }
And that would also remove the ambiguity in your example:
function f() { return function() { return-from-def-scope; } }
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
-- Mathieu Suen
[PHP-DEV] Closure local return
Hi,
The statement 'return' in a closure is now returning from the scope that
evaluate the closure (evaluation scope).
It could have been in an other way.
It could mean return from the scope were the closure is create (define
scope).
May be it could be interesting to have a syntax for returning from the
define scope.
For example.
$findedElment = $myList-selectIfAbsent($fooo, function(){
return 'No item founded'; //Retrun from the define scope
})
//Do somthing with $findedElment
So I am asking if there has been some discussion on it or if it could
be added?
Thanks
--Mathieu Suen
Re: [PHP-DEV] Closure local return
Of course I am.
take a look at:
http://en.wikipedia.org/wiki/Closure_%28computer_science%29
Section: Differences in semantics
On 05/03/2010 03:27 PM, Jille Timmermans wrote:
Are you serious?
Op 3-5-2010 15:01, mathieu.suen schreef:
Hi,
The statement 'return' in a closure is now returning from the scope that
evaluate the closure (evaluation scope).
It could have been in an other way.
It could mean return from the scope were the closure is create (define
scope).
May be it could be interesting to have a syntax for returning from the
define scope.
For example.
$findedElment = $myList-selectIfAbsent($fooo, function(){
return 'No item founded'; //Retrun from the define scope
})
//Do somthing with $findedElment
So I am asking if there has been some discussion on it or if it could be
added?
Thanks
--Mathieu Suen
--
• *Mathieu Suen* | It Team | www.easyflirt.com
• mathieu [dot] suen [at] easyflirt [dot] com
mathieu%20[dot]%20suen%20[at]%20easyflirt%20[dot]%20com
• EasyFlirt - Park Nord, Les Pléiades, 74370 - Metz-Tessy - FRANCE
• Pensez à l'environnement, n'imprimez cet e-mail qu'en cas de réelle
nécessité
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Closure local return
I think you actually misunderstand the difference in http://en.wikipedia.org/wiki/Closure_%28computer_science%29#Differences_in_semantics The way I read if the difference is wether it returns from the closure function or the surrounding function *calling* it. Not the *defining* scope. And no, it doesn't make sense in the PHP context IMHO. - Chris returns from the closure function To go were? I had maintain a smalltalk compiler. I did not misunderstand the difference. The Common Lisp implementation is the more explicit one. For exemple: (defun eval-l1 (fct) (funcall fct)) (defun bar (x) (eval-l1 #'(lambda () (return-from bar 45))) x) (bar 23) - 45 When funcall is apply you do not return from eval-l1. You return from bar. Which is the defining scope of the lanbda. -- Mathieu Suen
Re: [PHP-DEV] Obscure token name
Johannes Schlüter wrote: On Mon, 2010-04-26 at 16:32 +0200, mathieu.suen wrote: I am wondering why is the token name so incomprehensible ? Like T_PAAMAYIM_NEKUDOTAYIM... I don't mind if we change the name in the error message. Seems to be an issue for some ... but I think you have to look it (quickly) up the first time you stumble over it and then remember it so it shouldn't be a tooo big issue. If you fear typing it: The tokenizer extension already provides T_DOUBLE_COLON as synonym :-) php $t=token_get_all(?::); // Token 0: ? Token 1: :: php var_dump($t[1][0] == T_DOUBLE_COLON $t[1][0] == T_PAAMAYIM_NEKUDOTAYIM); bool(true) johannes The question is that I want to understand error messages. I can google it but that is not a good way of doing things. Stefan got the right answer: Better parser errors --Mathieu Suen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Obscure token name
Steven Van Poeck wrote: Folks, can't you just accept that T_PAAMAYIM_NEKUDOTAYIM is intended to make you smile? There's nothing to see here, please move along. - Martin +1 Don' t you read what I say? So to be clear: I don't car the name of the token. I care not understanding the parser error. = (enhance) Better parser error is a possible solution -- Mathieu Suen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Obscure token name
Hannes Magnusson wrote: On Mon, Apr 26, 2010 at 16:32, mathieu.suen mathieu.s...@easyflirt.com wrote: Hi, I am wondering why is the token name so incomprehensible ? Like T_PAAMAYIM_NEKUDOTAYIM... Paamayim Nekudotayim would, at first, seem like a strange choice for naming a double-colon. However, while writing the Zend Engine 0.5 (which powers PHP 3), that's what the Zend team decided to call it. It actually does mean double-colon - in Hebrew! http://php.net/manual/en/language.oop5.paamayim-nekudotayim.php -Hannes Then T_DOUBLE_COLON would have been perfectly clear. -- Mathieu Suen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Obscure token name
Stefan Marr wrote: On 27 Apr 2010, at 08:50, mathieu.suen wrote: Then T_DOUBLE_COLON would have been perfectly clear. Honestly, token names in error messages is so '80s. Instead of fixing internal details, form the users point of view it might be better to not expose token names at all, but have meaningful parser errors. Best regards Stefan +1 -- Mathieu Suen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Obscure token name
OMG More than 100 token I am pretty sure that more than 50% are syntactic sugar. Davey Shafik wrote: From the manual: T_PAAMAYIM_NEKUDOTAYIM :: ::. Also defined as T_DOUBLE_COLON. http://php.net/manual/en/tokens.php T_PAAMAYIM_NEKUDOTAYIM is hardly un-google-able. - Davey On Apr 27, 2010, at 2:50 AM, mathieu.suen wrote: Hannes Magnusson wrote: On Mon, Apr 26, 2010 at 16:32, mathieu.suen mathieu.s...@easyflirt.com wrote: Hi, I am wondering why is the token name so incomprehensible ? Like T_PAAMAYIM_NEKUDOTAYIM... Paamayim Nekudotayim would, at first, seem like a strange choice for naming a double-colon. However, while writing the Zend Engine 0.5 (which powers PHP 3), that's what the Zend team decided to call it. It actually does mean double-colon - in Hebrew! http://php.net/manual/en/language.oop5.paamayim-nekudotayim.php -Hannes Then T_DOUBLE_COLON would have been perfectly clear. -- Mathieu Suen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Mathieu Suen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Obscure token name
Hi, I am wondering why is the token name so incomprehensible ? Like T_PAAMAYIM_NEKUDOTAYIM... -- Mathieu Suen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Debugging a PHP Extension via GDB
One quick but ugly way is to add it in assembler in your C file: __asm__(int3); or something like this. Sebastian Kurfürst wrote: Hi Derick, Try just break objectmonitor.c:80. Thanks, just tried that, but same issue: (gdb) break objectmonitor.c:80 No source file named objectmonitor.c. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (objectmonitor.c:80) pending. (gdb) run index.php -- and does not stop on breakpoint. Greets, Sebastian -- Mathieu Suen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] What about static/self was: (Re: [PHP-DEV] Closures and $this)
Hi, Also $this have been wildly discuss here, but the same discussion can be apply to static/self. self might be simple to figure out how to bind within a closure. It can be bind to the name of the class where the closure is define. static is a more tricky one but it should be the same thing than $this. Is there a RFC about it? Thanks Stanislav Malyshev wrote: Hi! I see that still nothing happens with closures and $this, and it sounds like the overall feeling was that we still want $this in closures work, and most are inclined to A here: http://marc.info/?l=php-internalsm=126090656804423w=2 or some version of it. So, can anybody provide any reason not to resurrect $this in closures in trunk? If not, I intend to do it next week (unless somebody is already working on it - don't want to step on anybody's toes :). -- Mathieu Suen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Closure improvements in next version ?
There is also the improvement on the scope of $this: *http://tinyurl.com/ybqyskx* Frederic Hardy wrote: Hello ! In bug report http://bugs.php.net/bug.php?id=51326, johannes say that the next major version of PHP (5.4 / 6.0) will have better oo support for closure. Is there any RFC about that available ? And where are the patches ? Best regards, Fred. -- Mathieu Suen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Assign array with __get
Auke van Slooten wrote:
Stanislav Malyshev wrote:
Hi!
IMHO __get is not consistent at the first place.
on possible example:
It is perfectly consistent. You just need to read what it actually does:
http://www.php.net/manual/en/language.oop5.overloading.php#language.oop5.overloading.members
instead of imagining what it could do.
Hi,
not the same issue, but slightly related, __call() seems to me a bit
inconsistent with __get(). I'm not sure if this is the right thread to
ask this in, if not, I'll be happy to take this somewhere else :)
__get is called when accessing any inaccessible property, either when
not set or when it is private/protected. But __call() only gets called
when the method is not set, not for private methods. In that case you
get a Fatal error. e.g:
?php
class foo {
protected $foo = 'bar';
function __get($name) {
return 'getting '.$name.\n;
}
private function bar() {
echo 'private bar';
}
function __call($name, $params) {
echo 'calling '.$name.\n;
}
}
$foo = new foo();
echo $foo-foo;
$foo-bar();
?
Results in:
getting foo
Fatal error: Call to private method foo::bar() from context '' in
/home/auke/public_html/test/get.php on line 23
I wouldn't mind this if this is how it supposed to work, but the
documentation uses the same terminology for __get and __call:
__get() is utilized for reading data from inaccessible properties.
and
__call() is triggered when invoking inaccessible methods in an object
context.
In addition the page
http://www.php.net/manual/en/language.oop5.visibility.php
goes into some detail about when methods are visible and when not,
making no distinction between methods and properties in regard to
visibility, and this page is specifically linked from the page about
overloading, as explaining when __call() should be called:
The overloading methods are invoked when interacting with properties
or methods that have not been declared or are not visible in the
current scope. The rest of this section will use the terms
inaccessible properties and inaccessible methods to refer to this
combination of declaration and visibility.
So it seems to me that the above code should not have produced a fatal
error if the documentation is right... or am I misreading something?
regards,
Auke van Slooten
Muze
IMHO it worth a new thread
-- Mathieu Suen
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Assign array with __get
Stanislav Malyshev wrote: Hi! IMHO __get is not consistent at the first place. on possible example: It is perfectly consistent. You just need to read what it actually does: http://www.php.net/manual/en/language.oop5.overloading.php#language.oop5.overloading.members instead of imagining what it could do. It is not because it is written somewhere in the documentation that it make sense. This kind of operation is the kind you want to do with a meta-level, not the base level. You could even use mirror and design a security layer: http://gbracha.blogspot.com/2010/03/through-looking-glass-darkly.html I don' assume __get should work in a or b way. So to clarify IMHO it should not exist at all! -- Mathieu Suen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Assign array with __get
Stanislav Malyshev wrote:
Hi!
So what you're saying is that it is *consistent* with regard to the
implementation of methods/functions, i.e. __get behaves as an
ordinary method.
Yes, it does.
IMHO __get is not consistent at the first place.
on possible example:
class A
{
protected $foo;
public function __get($name)
{
echo 'GET';
}
public function test()
{
return $this-foo;
}
}
$a = new A;
$a-foo;
$a-test();
-- Mathieu Suen
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] horizontal reuse: traits vs. grafts
Stefan Marr wrote:
On 25 Mar 2010, at 21:30, Stefan Marr wrote:
On 25 Mar 2010, at 16:37, Lukas Kahwe Smith wrote:
Hi,
this was just brought up on IRC. my understanding is that traits have no
concept of properties, but grafts do (all hidden internally). correct?
Right, the Traits proposal as it is at the moment, avoids the explicit
discussion of state.
This is not a restriction per se, but could limit the composability of traits.
To ensure composibility, you would have to resort to abstract methods which are
implemented by the composing class.
Maybe I should clarify that.
Currently the semantics is implicitly the following:
class Base{
var $a;
}
trait T1 {
var $a;
var $b;
}
trait T2 {
var $a;
var $c;
}
class Composite extends Base {
use T1, T2;
}
and Composite would have the instance variables $a, $b, $c.
The problem would be of course that Base, T1, and T2 could use $a for
completely different things.
Simple, but at the cost of composability/safety.
But for most practical cases that should be 'good enough'. As already
mentioned, if you want stronger guarantees, state accessor methods can be used.
However, I think this implication is not discussed in the RFC, and works just
because PHP can create the fields dynamically. Thus, I used 'var' here in the
example, instead of defining a semantics and handling for public, private,
protected.
Best regards
Stefan
Variable has been discuss in *http://tinyurl.com/y9t7nd9
--Mathieu Suen
*
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] horizontal reuse: traits vs. grafts
Stefan Marr wrote: On 26 Mar 2010, at 10:26, mathieu.suen wrote: Variable has been discuss in *http://tinyurl.com/y9t7nd9 Right, and related to that we have freezable traits http://scg.unibe.ch/scgbib?_k=NNRwidu5query=freezable+traitsdisplay=abstract Which influenced this RFC for PHP: http://wiki.php.net/rfc/nonbreakabletraits And there are traits based on lexical nesting, which does not seem to be applicable to PHP at all: http://scg.unibe.ch/scgbib?_k=J-wbMltVquery=tom+cutsem+bergel However, it still comes with a relatively high complexity, and a lot new concepts... The last time we had a lengthy discussion on this, and the conclusion was, people are afraid of this additional complexity. That was my reason to design grafts. Best regards Stefan Right I didn't like freezable traits as there are over-complicate for almost nothing. I don't see any relevant example for using the freeze operator. And the unfreeze is even more obscure. -- Mathieu Suen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Assign array with __get
Etienne Kneuss wrote:
On Thu, Mar 18, 2010 at 5:47 PM, mathieu.suen
mathieu.s...@easyflirt.com wrote:
Peter Lind wrote:
On the contrary, it's quite obvious what's going on. In both examples
__get() returns an array as PHP would normally do it (i.e. NOT by
reference) which means that if you try to modify that you'll end up
modifying nothing much. However, in your second example, the point at
which you call __get() indirectly comes before the assign to the zork
array - hence, the $this-zork['blah'] = 'blah'; no longer indirectly
calls __get as object::$zork now exists.
In other words, this is down to you confusing passing a variable by
reference and passing it by value: PHP normally passes arrays by
value, so when __get() returns an array, you're working on a copy of
the array you returned. As someone noted earlier, you can easily
change the behaviour of __get to return variables by reference, should
you want to. However, I personally wouldn't want this to be default
behaviour as that would make debugging apps much more annoying -
things should be consistent, even if consistency at times confuse
people.
Regards
Peter
The sementic of
$this-zork
Should be the same as
$this-__get('zork')
$this-zork is only the same as $this-__get(zork) if zork is
undefined, this is perfectly normal and expected.
I would be very interested if someone already try to implement a meta
circular interpreter.
So in that respect it is not consistent.
But anywhere I don't care if it change or not.
Look at Scheme, Lisp and Smalltalk language.
This is what I call consistent language.
-- Mathieu Suen
-- Mathieu Suen
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Assign array with __get
Right I could work around the issue with the return by reference without
any problem.
I am still thinking that if you try to write a meta-circular interpreter
you gonna work very hard
to make this subtleties worked. And according to Shriram Krishnamurthi
in his textbook PLAI:
a truly powerful language is one that makes it easy to write its
meta-circular interpreter.
-- Mathieu Suen
Ionut G. Stan wrote:
I guess what Mathieu is trying to say is that this:
class Foo
{
public $bar = array();
}
$foo = new Foo;
$foo-bar[3] = 1;
var_dump($foo);
...is inconsistent with this:
class Foo
{
public function __get($property)
{
if (! isset($this-$property)) {
$this-$property = array();
}
return $this-$property;
}
}
$foo = new Foo;
$foo-bar[3] = 1;
var_dump($foo);
...or even this:
class Foo
{
private $bar = array();
public function __get($property)
{
return $this-$property;
}
}
$foo = new Foo;
$foo-bar[3] = 1;
var_dump($foo);
Now, I'm not really sure this is that bad, as there may be use cases
where one would like to return different values every time __get is
called. And, as I wrote in a previous email, there are ways to work
around this inconsistency by using return by reference, so everybody
can be happy. I think.
On 3/19/10 4:56 AM, Etienne Kneuss wrote:
On Thu, Mar 18, 2010 at 5:47 PM, mathieu.suen
mathieu.s...@easyflirt.com wrote:
Peter Lind wrote:
On the contrary, it's quite obvious what's going on. In both examples
__get() returns an array as PHP would normally do it (i.e. NOT by
reference) which means that if you try to modify that you'll end up
modifying nothing much. However, in your second example, the point at
which you call __get() indirectly comes before the assign to the zork
array - hence, the $this-zork['blah'] = 'blah'; no longer indirectly
calls __get as object::$zork now exists.
In other words, this is down to you confusing passing a variable by
reference and passing it by value: PHP normally passes arrays by
value, so when __get() returns an array, you're working on a copy of
the array you returned. As someone noted earlier, you can easily
change the behaviour of __get to return variables by reference, should
you want to. However, I personally wouldn't want this to be default
behaviour as that would make debugging apps much more annoying -
things should be consistent, even if consistency at times confuse
people.
Regards
Peter
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Assign array with __get
Etienne Kneuss wrote:
Hello,
On Wed, Mar 17, 2010 at 3:40 PM, mathieu.suen
mathieu.s...@easyflirt.com wrote:
Ionut G. Stan wrote:
Hi,
This is interesting and it appears the following change makes the snippet
work as expected:
public function __get($name);
I think is that the $this-anArray['bar'] = 4;
Generate the following bytcode:
0 FETCH_OBJ_W $0 'anArray'
1 ZEND_ASSIGN_DIM $0, 'bar'
Will the folloing :
echo $this-anArray;
$this-anArray['bar'];
0 FETCH_OBJ_R $0 'anArray'
1 ECHO
...
IMHO I think that the complexity of the VM is way to hight.
That is something I am strongly agree with Gilad Bracha on adding new
feature into a language:
What exactly would you like it do? You've two options:
1) __get, define the property, and then __set?
2) __get returns a ref that is modified
The second option is taken by PHP.
In your case you return a value, not a reference.
I think there is a lot to say why is not working but just look at those
2 execution:
1st
class A
{
public function __get($name)
{
$this-$name = array();
return $this-$name;
}
public function test()
{
$this-_zork;
$this-_zork['bar'] = 67;
}
}
$a = new A;
$a-test();
var_dump($a);
2nd
class A
{
public function __get($name)
{
$this-$name = array();
return $this-$name;
}
public function test()
{
$this-_zork['bar'] = 67;
}
}
$a = new A;
$a-test();
var_dump($a);
Adding something that don't have side effect make the side effect
work (more or less)
You almost have to know how the VM is implemented in other to know what
is going on.
Nothing is obvious.
Look at the last paragraph:
http://gbracha.blogspot.com/2009/09/systemic-overload.html
On 3/17/10 3:55 PM, mathieu.suen wrote:
Hi,
I came across a strange behavior when using the magic method __get and
some instance variable that should be an array.
Consider the following example:
class A
{
public function __get($name)
{
$this-$name = array();
return $this-$name;
}
public function test()
{
$this-_zork['bar'] = 67;
}
}
$a = new A;
$a-test();
var_dump($a);
So could someone explain me what is the semantic of the above statements?
Thanks
-- Mathieu Suen
--Mathieu Suen
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
-- Mathieu Suen
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Assign array with __get
Peter Lind wrote:
On the contrary, it's quite obvious what's going on. In both examples
__get() returns an array as PHP would normally do it (i.e. NOT by
reference) which means that if you try to modify that you'll end up
modifying nothing much. However, in your second example, the point at
which you call __get() indirectly comes before the assign to the zork
array - hence, the $this-zork['blah'] = 'blah'; no longer indirectly
calls __get as object::$zork now exists.
In other words, this is down to you confusing passing a variable by
reference and passing it by value: PHP normally passes arrays by
value, so when __get() returns an array, you're working on a copy of
the array you returned. As someone noted earlier, you can easily
change the behaviour of __get to return variables by reference, should
you want to. However, I personally wouldn't want this to be default
behaviour as that would make debugging apps much more annoying -
things should be consistent, even if consistency at times confuse
people.
Regards
Peter
The sementic of
$this-zork
Should be the same as
$this-__get('zork')
So in that respect it is not consistent.
But anywhere I don't care if it change or not.
Look at Scheme, Lisp and Smalltalk language.
This is what I call consistent language.
-- Mathieu Suen
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Assign array with __get
Hi,
I came across a strange behavior when using the magic method __get and
some instance variable that should be an array.
Consider the following example:
class A
{
public function __get($name)
{
$this-$name = array();
return $this-$name;
}
public function test()
{
$this-_zork['bar'] = 67;
}
}
$a = new A;
$a-test();
var_dump($a);
So could someone explain me what is the semantic of the above statements?
Thanks
-- Mathieu Suen
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Assign array with __get
Ionut G. Stan wrote:
Hi,
This is interesting and it appears the following change makes the
snippet work as expected:
public function __get($name);
I think is that the $this-anArray['bar'] = 4;
Generate the following bytcode:
0 FETCH_OBJ_W $0 'anArray'
1 ZEND_ASSIGN_DIM $0, 'bar'
Will the folloing :
echo $this-anArray;
$this-anArray['bar'];
0 FETCH_OBJ_R $0 'anArray'
1 ECHO
...
IMHO I think that the complexity of the VM is way to hight.
That is something I am strongly agree with Gilad Bracha on adding new
feature into a language:
Look at the last paragraph:
http://gbracha.blogspot.com/2009/09/systemic-overload.html
On 3/17/10 3:55 PM, mathieu.suen wrote:
Hi,
I came across a strange behavior when using the magic method __get and
some instance variable that should be an array.
Consider the following example:
class A
{
public function __get($name)
{
$this-$name = array();
return $this-$name;
}
public function test()
{
$this-_zork['bar'] = 67;
}
}
$a = new A;
$a-test();
var_dump($a);
So could someone explain me what is the semantic of the above
statements?
Thanks
-- Mathieu Suen
--Mathieu Suen
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Closure/lambda semantic comparaison
Hi,
I am proposing a comparison between PHP closure with lisp one.
First thing to compare is how scope are capture:
Suppose I want to create a function that add.
The common idiom to do it in lisp is:
(defun adder (x) #'(lambda (y) (+ x y)))
Then if I want the add3 method you can do:
(setf (symbol-function 'add3) (adder 3))
(add3 4) = 7
Now let reproduce that in php:
$adder = function ($x) {return function ($y) use($x) {return $y + $x;};};
$add3 = $adder(3);
echo $add3(4); = 7
Every thing is fine but let change the adder into a counter :
In lisp you could do:
(let ((sum 0))
(defun counter () (setf sum (1+ sum
(counter) = 1
(counter) = 2
(counter) = 3 ...
In other to have the same behavior in PHP you first need to transform
the let into a lambda which make no difference in lisp:
(funcall #'(lambda (sum) (defun counter () (setf sum (1+ sum 0)
Now we are ready to do it in PHP.
$createCounter = function ($sum) { return function () use ($sum) {return
++$sum;};};
$counter = $createCounter(0);
$counter(); = 1
$counter(); = 1
$counter(); = 1
...
So that's not the expected behavior.
In oder to have the expected behavior you need to add in front of $sum.
But is kind of evil since it mimics dynamic scoping:
$array = array(1, 2, 3);
foreach($array as $pos)
{
$adders[] = function ($x) use ($pos) { return $pos+ $x;};
}
foreach($adders as $addIt)
{
echo $addIt(5);
}
Thanks for your attention
-- Mathieu Suen
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Closure/lambda semantic comparaison
Etienne Kneuss wrote:
Hello,
On Mon, Mar 1, 2010 at 1:33 PM, mathieu.suen mathieu.s...@easyflirt.com wrote:
Hi,
I am proposing a comparison between PHP closure with lisp one.
First thing to compare is how scope are capture:
Suppose I want to create a function that add.
The common idiom to do it in lisp is:
(defun adder (x) #'(lambda (y) (+ x y)))
Then if I want the add3 method you can do:
(setf (symbol-function 'add3) (adder 3))
(add3 4) = 7
Now let reproduce that in php:
$adder = function ($x) {return function ($y) use($x) {return $y + $x;};};
$add3 = $adder(3);
echo $add3(4); = 7
Every thing is fine but let change the adder into a counter :
In lisp you could do:
(let ((sum 0))
(defun counter () (setf sum (1+ sum
(counter) = 1
(counter) = 2
(counter) = 3 ...
In other to have the same behavior in PHP you first need to transform the
let into a lambda which make no difference in lisp:
(funcall #'(lambda (sum) (defun counter () (setf sum (1+ sum 0)
Now we are ready to do it in PHP.
$createCounter = function ($sum) { return function () use ($sum) {return
++$sum;};};
$counter = $createCounter(0);
$counter(); = 1
$counter(); = 1
$counter(); = 1
...
So that's not the expected behavior.
In oder to have the expected behavior you need to add in front of $sum.
But is kind of evil since it mimics dynamic scoping:
$array = array(1, 2, 3);
foreach($array as $pos)
{
$adders[] = function ($x) use ($pos) { return $pos+ $x;};
}
foreach($adders as $addIt)
{
echo $addIt(5);
}
use($var) will import by copy, so you won't have the behavior you
expect. If you want to keep a value in a function between calls, you
can use static $sum = 0;.
You call it import by copy. I would rather say a mix-up of concept
between value and variable.
Thanks for your attention
-- Mathieu Suen
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
-- Mathieu Suen
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On closures and lamdba
Stanislav Malyshev wrote: Hi! My question is not so much about implementation it is about language. I have noticed quite a few times now that PHP developers use the word closure when I would prefer lambda. Everybody on the internet knows that Wikipedia is the ultimate source of knowledge, and it says: In computer science, a closure is a first-class function with free variables that are bound in the lexical environment. Such a function is said to be closed over its free variables. I think this describes what PHP is doing. However, in the PHP manual as well as on this list, you seem to be saying closure === anonymous function (which is what I'd rather see called lambda). This is not entirely correct, you are right. There's a difference between anonymous function and closure, though in practice in PHP anonymous functions are closures (though some of them are rather trivial ones with no variables to close over) and that's now the only way to do closure in PHP (i.e. you can't have non-anonymous closure function). I would rather say that PHP have both. Closure is just a subset of lanbda. You say that a lambda is a closure whenever the lambda capture variable from its outer scope. You even have a special syntactic form to declare a lambda to be a closure, the keyword use. -- Mathieu -- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP continuations
Sebastian Bergmann wrote: Am 08.02.2010 14:38, schrieb mathieu.suen: I am wondering if there is some effort for having continuation in php. Or is there already some construction for continuation? There is http://phpcontinuation.sourceforge.net/ which I never got around to actually try. Yet an other smalltalker :) On of the first implementation of continuation was in lisp thought. Phaux seem more promising -- Mathieu Suen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP continuations
Hi, I am wondering if there is some effort for having continuation in php. Or is there already some construction for continuation? Thanks - Mathieu Suen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Iterable object can't return object in key
Hi, Whenever you implement the Iterator interface the key method should only return a scalar. Is there any particular reason for this restriction. IMHO I don't see any. I also don't see why you can't index an array with object but it smells something going wrong underneath. Thanks - Mathieu Suen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP continuations
troels knak-nielsen wrote: On Mon, Feb 8, 2010 at 2:38 PM, mathieu.suen mathieu.s...@easyflirt.com wrote: Hi, I am wondering if there is some effort for having continuation in php. Or is there already some construction for continuation? phaux (http://code.google.com/p/phaux/) is an attempt at creating a continuation-based framework for php. It's handled on the framework level, rather than language level, but you might find it interesting. Cool I haven't take a deep look at it but a smalltalk guy behind seems promising :) Thanks -- Mathieu Suen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] About optimization
Hi, I would like to know why the opcode is not optimized. Even for some very simple optimization like constant folding. For exemple: line # op fetch ext return operands --- 60 0 ADD ~0 5, 7 1 ECHO ~0 which is echo 5+7; -- Mathieu Suen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About optimization
Sebastian Bergmann wrote:
Am 13.01.2010 12:18, schrieb mathieu.suen:
I would like to know why the opcode is not optimized.
Because any optimization, even very simple ones, impose a performance
penalty in the default execution model of PHP which does not use a
bytecode cache.
For simple optimization I don't think so. Take the simple example:
function foo()
{
$a = 45;
return $a;
}
Here if you don't optimize you are creating a variable. So you put
pressure on the gc and the memory.
Best would be some benchmark.
By the way why there is no native bytecode cache ?
Only when the bytecode is not regenerated for each execution does it
make sense to invest for time for the then one-time compilation.
Sorry I don't understand what do you mean?
-- Mathieu Suen
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Inconsistency redesign
Hi, I came across this: echo sizeof(array()); echo sizeof(); $a = ; var_dump( empty($a)); $a = array(); var_dump(empty($a)); So funny! How something can have a size greater than 0 but still be empty? I think PHP is reinventing the inconsistency word. But then let assume that empty is just making a cast in array. $a = ; empty($a) //true empty((array)$a) //false Ok so empty is big ugly switch case on type. empty(0); //true empty(45); //false Wooow reinventing emptiness on number -- Mathieu Suen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistency redesign
Etienne Kneuss wrote: Hello, On Wed, Jan 13, 2010 at 2:36 PM, mathieu.suen mathieu.s...@easyflirt.com wrote: Hi, I came across this: echo sizeof(array()); echo sizeof(); $a = ; php.net/count: If var is not an array or an object with implemented Countable interface, 1 will be returned. There is one exception, if var is NULL, 0 will be returned. The behavior might be documenting but it does not mean that's a good thing. I don't see the point of allowing sizeof on a var that is not an array or object that implement countable. var_dump( empty($a)); $a = array(); var_dump(empty($a)); php.net/empty empty($var) is basically an !isset($var) || !$var it's not related to count in anyway. So funny! How something can have a size greater than 0 but still be empty? I think PHP is reinventing the inconsistency word. I think such comments are pretty useless. Try coming with a viable solution as a patch instead. But then let assume that empty is just making a cast in array. If you assume wrong, you can derive all kind of madness. $a = ; empty($a) //true empty((array)$a) //false Ok so empty is big ugly switch case on type. No, it's a boolean check, with type juggling involed, see above. Ho yes but type juggling is pretty mush a big switch case empty(0); //true empty(45); //false Wooow reinventing emptiness on number -- Mathieu Suen -- 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
