Re: [PHP-DEV] Trying to find out where the memory went
I wrote about ZendMM some time ago (http://julien-pauli.developpez.com/tutoriels/php/internals/zend-memory-manager/) , that's in french language ;-) To shorten the conversation a little bit, I would suggest to trace the memory with valgrind/massif. That's not too hard if you know what you do, if not, then it can take some time. Basically, Johannes gave some good hints; but memory management is a hard task to compute and deal with, I suggest you dont try to figure out how many memory it "would" take, as the computation is really too hard to be accurate. Only memory debuggers will show you exactly what happens. BTW, there might be a little leak inside token_get_all() as it doesn't seem to free memory it allocated. Not very easy to find as it plays with lex scanner. Julien.P 2011/6/8 Johannes Schlüter : > On Tue, 2011-06-07 at 21:03 +0200, David Zülke wrote: >> 144 (not 114!) bytes is for an integer; I'm not quite sure what the >> overheads are for arrays, which token_get_all() produces in >> abundance :) An empty array seems to occupy 312 bytes of memory. >> >> Also, strings have memory allocated in 8 byte increments as far as I >> know, so "1" eats up 8 bytes, and "12345678901234567" will consume 24 >> bytes for the raw text, not 17. > > I'm too lazy to do the actual math (well best would be to do > sizeof(zval), sizeof(HashTable), sizeof(Bucket) on your system) and > there are few things to consider: > > * The sizes are different from 32 bit and 64bit; with 64bit > there's a difference between Windows and Unix/Linux (on Win a > long will still be 32 bit, but pointers 64 bit, on Linux/Unix > both are 64bit) > * On some architectures memory segments have to be aligned in some > way which might waste memory > * As David mentioned HashTables (Arrays) are more complex. > * token_get_all() returns an array of (string | array of (long, > string, long) ) > * A long takes sizeof(zval) > * A string takes sizeof(zval)+strlen()+1 > * and array is a HashTable + space for buckets, this includes > place for some not used elements > * Each element inside the HT needs additional space for a Bucket > with some meta data > * While running your script you also keep the complete script file > in memory. You also keep some temporary parser data in memory > while the resulting array is being filled. > > In the end it's not fully trivial to gather the size needed. And I'm > sure my list is missing lts of things. > > http://schlueters.de/blog/archives/142-HashTables.html has an short > introduction to HashTables. Skipping many of the details. > > johannes > >> David >> >> >> On 07.06.2011, at 20:26, Mike van Riel wrote: >> >> > Am i then also correct to assume that the output of >> > memory_get_peak_usage is used for determining the memory_limit? >> > >> > Also: after correcting with your new information (zval = 114 bytes >> > instead of 68) I still have a rather large offset: >> > >> > 640952+2165950+114+(276697*114)+(276697*3*114)+2165950 = 131146798 = >> > 125M >> > >> > (not trying to be picky here; I just don't understand) >> > >> > _If_ my calculations are correct then a zval should be approx 216 bytes >> > (excluding string contents): >> > >> > ((24400-640952-2165950-2165950) / 4) / 276697 = 215.9647B >> > >> > Mike >> > >> > On Tue, 2011-06-07 at 19:50 +0200, David Zülke wrote: >> >> memory_get_peak_usage() is the maximum amount of memory used by the VM of >> >> PHP (but not by some extensions for instance) up until the point where >> >> that function is called. So the actual memory usage may be even higher >> >> IIRC. But yeah, you're basically right. I've explained in another message >> >> why it might be so much more than you expected (zval overhead, basically) >> >> >> >> David >> > >> > >> > >> > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
We have the situation in the docs that parameters declared as arrays do not follow the typehinting rules, but parameters as class names do. Re-using the callback from the docs could get confusing when extensions start to typehint on it, but not the core.. I think there is a subtle difference between a callback, and a callable. In javascript for example, callback is something that is executed on certain events "onsuccess" is the typical example. There is nothing that says the callable parameter gets executed as a part of an event, and I think the default usecase would be to execute it right away (f.e. filtering data). I think I would prefer callable, but I could live with either. -Hannes On Tue, Jun 7, 2011 at 23:41, Matthew Weier O'Phinney wrote: > On 2011-06-07, dukeofgaming wrote: >> --0016e68ee3e4bc4b0e04a525bac6 >> Content-Type: text/plain; charset=ISO-8859-1 >> Content-Transfer-Encoding: quoted-printable >> >> +1 for "callable", it is really more consistent. > > I was actually agreeing With David and Stas that "callback" was more > consistent, and casting my vote for that. > >> On Tue, Jun 7, 2011 at 3:44 PM, Matthew Weier O'Phinney < >> weierophin...@php.net> wrote: >> >> > On 2011-06-07, David Z=FClke wrote: >> > > On 07.06.2011, at 22:31, Stas Malyshev wrote: >> > > > > callback is callable, the opposite could not be true. a string >> > > > > --or a closure-- is callable, but the string is not a callback >> > > > >> > > According to our docs, which were out there for years, it is. One of >> > > the main and widespread complaints about PHP is the lack of any system >> > > in naming, design and documentation, it is sad to see how many people >> > > want to make it worse instead of making it better >> > > >> > > +1. I'm thinking it should be "callback", or the docs should be >> > > adjusted. "callable" arguably does make more sense, but either way, it >> > > needs to be consistent, that's what matters most. >> > >> > Agreed, here. "callback" is the usage throughout the documentation to >> > refer to anything that passes is_callable(). > > -- > Matthew Weier O'Phinney > Project Lead | matt...@zend.com > Zend Framework | http://framework.zend.com/ > PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc > > -- > 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] Callable type
2011/6/8 Johannes Schlüter :
> On Tue, 2011-06-07 at 12:12 -0700, Stas Malyshev wrote:
>> Hi!
>>
>> > https://wiki.php.net/rfc/callable
>>
>> It is good there's an RFC. However it seems to lack code examples. I
>> understand it may be obvious to the proposers how it looks like, but
>> it'd be nice to have the actual example there as it is done nearly
>> everywhere else.
>
> The RFC is missing information about what happens in codebases which
> already have a "callable" type declared. Will that be prevented or will
> they hit a runtime error? ("callable expected, callable type found")
You mean an interface/class with that name?
The error would be 'expected instanceof callable, string/array/closure recieved.
gettype("strpos") will still return a string, not callable.
A callable wouldn't be fully featured type.
> What about default values? Will
> function foo(callback $cb = 'strpos') { }
> be valid?
No default values, other then NULL allowed.
Otherwise we would need to support array("classname", "methodname")
too, and then people would want default array values for array
typehinting etc etc etc.
> The information on reflection is limited. what shall
> Reflection::Parameter::getTypehint() return? Will that method allow to
> differ between a class type and this "magic"?
There is no such method anymore :)
>
> What about ARGINFO? Will internal functions be able to define this type
> via ARGINFO? How will this be reported in `php --rf function`?
I didn't include arginfo in the patch, but good point. It should
probably be included.
As Felipe pointed out, ext/reflection hasn't been updated.
It should return [ callable $foobar ], just like with any other typehint
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
2011/6/8 Hannes Magnusson : > We have the situation in the docs that parameters declared as arrays > do not follow the typehinting rules, but parameters as class names do. > Re-using the callback from the docs could get confusing when > extensions start to typehint on it, but not the core.. > > I think there is a subtle difference between a callback, and a callable. > In javascript for example, callback is something that is executed on > certain events "onsuccess" is the typical example. > There is nothing that says the callable parameter gets executed as a > part of an event, and I think the default usecase would be to execute > it right away (f.e. filtering data). > > I think I would prefer callable, but I could live with either. > Wikipedia defines callback as "a reference to executable code, or a piece of executable code, that is passed as an argument to other code". So there's no "event" meaning put by default, it's just very often seen callback's usage in javascript. I just like "callback" term more :) -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
On Wed, 2011-06-08 at 10:38 +0200, Hannes Magnusson wrote:
> 2011/6/8 Johannes Schlüter :
> > On Tue, 2011-06-07 at 12:12 -0700, Stas Malyshev wrote:
> >> Hi!
> >>
> >> > https://wiki.php.net/rfc/callable
> >>
> >> It is good there's an RFC. However it seems to lack code examples. I
> >> understand it may be obvious to the proposers how it looks like, but
> >> it'd be nice to have the actual example there as it is done nearly
> >> everywhere else.
> >
> > The RFC is missing information about what happens in codebases which
> > already have a "callable" type declared. Will that be prevented or will
> > they hit a runtime error? ("callable expected, callable type found")
>
> You mean an interface/class with that name?
> The error would be 'expected instanceof callable, string/array/closure
> recieved.
>
> gettype("strpos") will still return a string, not callable.
>
> A callable wouldn't be fully featured type.
Which means that
class callable { }
function f(callable $c) { }
f(new callable);
will be allowed by the parser but have a "strange" result? (This isn't
the case w/ array type hints as array is a parser token and can't be
used as class name (from userland at least))
If this feature is accepted we should have a good behavior there. I'm
not sure whether the right solution is to disallow naming classes
"callable" (or "callback" or whatever the name will be in the end)
Funny thing: Google Codesearch gives me one application defining an
class Callable. In that specific case the above thing would work:
http://google.com/codesearch/p?hl=en#vA7-IQSCKhE/trunk/php/framework/project/App/util/Callable.php&q=lang:php%20%22class%20callable%22&sa=N&cd=9&ct=rc
Sidenote: Looking for "class callback" gives me more false positives,
but also a few places where that classname is being used:
http://google.com/codesearch/p?hl=en#lYWaFFstwm4/tests/cases/libs/model/models.php&q=lang:php%20%22class%20callback%22&sa=N&cd=11&ct=rc
http://google.com/codesearch/p?hl=en#PbKZfG2CZcc/trunk/phpQuery/phpQuery/Callback.php&q=lang:php%20%22class%20callback%22&sa=N&cd=12&ct=rc&l=29
http://google.com/codesearch/p?hl=en#f6tUYQTbHns/trunk/framework/activerecord/lib/CallBack.php&q=lang:php%20%22class%20callback%22&sa=N&cd=21&ct=rc
...
> > What about default values? Will
> >function foo(callback $cb = 'strpos') { }
> > be valid?
>
> No default values, other then NULL allowed.
> Otherwise we would need to support array("classname", "methodname")
> too, and then people would want default array values for array
> typehinting etc etc etc.
Ok. I assume NULL as default value would be allowed, though. This would
be consistent for the language and allow such things:
function foo(callback $cb = NULL) {
if (!$cb) {
$cb = function() { /* .. default implementation */
}
}
> > The information on reflection is limited. what shall
> > Reflection::Parameter::getTypehint() return? Will that method allow to
> > differ between a class type and this "magic"?
>
> There is no such method anymore :)
Good point. While I'd see that as defect, independently from scalar and
other type hints ;-)
> > What about ARGINFO? Will internal functions be able to define this type
> > via ARGINFO? How will this be reported in `php --rf function`?
>
> I didn't include arginfo in the patch, but good point. It should
> probably be included.
> As Felipe pointed out, ext/reflection hasn't been updated.
> It should return [ callable $foobar ], just like with any other typehint
That is fine.
Having the behavior cleared I wonder how useful it is in practical
terms. A class type hint guarantees me I can do a specific call to
methods defined in the class/interface. The proposed type hint tells me
I can call it in some way. It won't ensure that the signature is
compatible with what I expect.
function foo(callable $cb) {
$cb();
}
foo("strpos"); // This one in fact is illegal but won't be prevented
But maybe this doesn't matter as type hints purely serve documentation
(as E_RECOVERABLE are useless unless we make them Exceptions ...) while
even for documentation purpose more information is needed.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
2011/6/8 Johannes Schlüter :
> On Wed, 2011-06-08 at 10:38 +0200, Hannes Magnusson wrote:
>> 2011/6/8 Johannes Schlüter :
>> > On Tue, 2011-06-07 at 12:12 -0700, Stas Malyshev wrote:
>> >> Hi!
>> >>
>> >> > https://wiki.php.net/rfc/callable
>> >>
>> >> It is good there's an RFC. However it seems to lack code examples. I
>> >> understand it may be obvious to the proposers how it looks like, but
>> >> it'd be nice to have the actual example there as it is done nearly
>> >> everywhere else.
>> >
>> > The RFC is missing information about what happens in codebases which
>> > already have a "callable" type declared. Will that be prevented or will
>> > they hit a runtime error? ("callable expected, callable type found")
>>
>> You mean an interface/class with that name?
>> The error would be 'expected instanceof callable, string/array/closure
>> recieved.
>>
>> gettype("strpos") will still return a string, not callable.
>>
>> A callable wouldn't be fully featured type.
>
> Which means that
> class callable { }
No. 'callable' is a parser token.
>> > What about default values? Will
>> > function foo(callback $cb = 'strpos') { }
>> > be valid?
>>
>> No default values, other then NULL allowed.
>> Otherwise we would need to support array("classname", "methodname")
>> too, and then people would want default array values for array
>> typehinting etc etc etc.
>
> Ok. I assume NULL as default value would be allowed, though. This would
> be consistent for the language and allow such things:
>
> function foo(callback $cb = NULL) {
> if (!$cb) {
> $cb = function() { /* .. default implementation */
> }
>
> }
Etienne pointed out that default values for arrays can actually contain values..
I actually had no idea.
I suppose we then need to support default values for an array callable.
But yes, a callable can have the default value of null, following the
rules of class hinting.
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
On 8 June 2011 09:47, Alexey Shein wrote:
> 2011/6/8 Hannes Magnusson :
>> We have the situation in the docs that parameters declared as arrays
>> do not follow the typehinting rules, but parameters as class names do.
>> Re-using the callback from the docs could get confusing when
>> extensions start to typehint on it, but not the core..
>>
>> I think there is a subtle difference between a callback, and a callable.
>> In javascript for example, callback is something that is executed on
>> certain events "onsuccess" is the typical example.
>> There is nothing that says the callable parameter gets executed as a
>> part of an event, and I think the default usecase would be to execute
>> it right away (f.e. filtering data).
>>
>> I think I would prefer callable, but I could live with either.
>>
>
> Wikipedia defines callback as "a reference to executable code, or a
> piece of executable code, that is passed as an argument to other
> code". So there's no "event" meaning put by default, it's just very
> often seen callback's usage in javascript.
> I just like "callback" term more :)
An interesting issue here.
Closures, classes with an __invoke method and strings containing
existing function names all pass is_callable() and can be called using
().
But, array('class', 'method') also passes is_callable, but isn't a callback.
http://pastebin.com/Yb5nJ8DB
outputs ...
object is callable
Invoked : Wed, 08 Jun 2011 11:24:09 +0100
object is callable
Closure : Wed, 08 Jun 2011 11:24:09 +0100
string is callable
Wed, 08 Jun 2011 11:24:09 +0100
array is callable
Handling Array via call_user_func
Func array : Wed, 08 Jun 2011 11:24:09 +0100
So, callable and callbacks are 2 different things.
Callable
1 - closures.
2 - classes with an __invoke method.
3 - strings to an existing function.
4 - array('class', 'method')
Callbacks
Only 1, 2 and 3 from the above list.
If you try to use $funcarray(), you get the following fatal error ...
Fatal error: Function name must be a string
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
On Wed, 2011-06-08 at 12:17 +0200, Hannes Magnusson wrote:
> >> A callable wouldn't be fully featured type.
> >
> > Which means that
> > class callable { }
>
> No. 'callable' is a parser token.
Which has larger implications. This break code where people use callable
as constant, property, function or method name.
This seems to hit symfony and a few others.
http://google.com/codesearch?hl=en&lr=&q=lang%3Aphp+%22-%3Ecallable%
22&sbtn=Search
(yes breaking stuff can be fine, but we should at least be aware of
it ;-) )
> > Ok. I assume NULL as default value would be allowed, though. This would
> > be consistent for the language and allow such things:
> >
> > function foo(callback $cb = NULL) {
> >if (!$cb) {
> >$cb = function() { /* .. default implementation */
> >}
> >
> > }
>
> Etienne pointed out that default values for arrays can actually contain
> values..
> I actually had no idea.
>
> I suppose we then need to support default values for an array callable.
As I pointed out on IRC I'm not sure that's good, unless we want
closures as defaults, too. Which we probably won't like.
> But yes, a callable can have the default value of null, following the
> rules of class hinting.
Good.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
On Wed, Jun 8, 2011 at 12:27, Richard Quadling wrote:
> On 8 June 2011 09:47, Alexey Shein wrote:
>> 2011/6/8 Hannes Magnusson :
>>> We have the situation in the docs that parameters declared as arrays
>>> do not follow the typehinting rules, but parameters as class names do.
>>> Re-using the callback from the docs could get confusing when
>>> extensions start to typehint on it, but not the core..
>>>
>>> I think there is a subtle difference between a callback, and a callable.
>>> In javascript for example, callback is something that is executed on
>>> certain events "onsuccess" is the typical example.
>>> There is nothing that says the callable parameter gets executed as a
>>> part of an event, and I think the default usecase would be to execute
>>> it right away (f.e. filtering data).
>>>
>>> I think I would prefer callable, but I could live with either.
>>>
>>
>> Wikipedia defines callback as "a reference to executable code, or a
>> piece of executable code, that is passed as an argument to other
>> code". So there's no "event" meaning put by default, it's just very
>> often seen callback's usage in javascript.
>> I just like "callback" term more :)
>
> An interesting issue here.
>
> Closures, classes with an __invoke method and strings containing
> existing function names all pass is_callable() and can be called using
> ().
>
> But, array('class', 'method') also passes is_callable, but isn't a callback.
It is after Felipes recent commit introducing $array();
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
On Wed, 2011-06-08 at 11:27 +0100, Richard Quadling wrote:
> If you try to use $funcarray(), you get the following fatal error ...
>
> Fatal error: Function name must be a string
This is fixed. See thread
From: Felipe Pena
To: internals
Subject:[PHP-DEV] $arr = array('Hello', 'world'); $arr();
Date: Sun, 5 Jun 2011 12:52:45 -0300 (06/ 5/11 05:52:45 PM)
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
2011/6/8 Johannes Schlüter :
> On Wed, 2011-06-08 at 11:27 +0100, Richard Quadling wrote:
>> If you try to use $funcarray(), you get the following fatal error ...
>>
>> Fatal error: Function name must be a string
>
> This is fixed. See thread
>
> From: Felipe Pena
> To: internals
> Subject: [PHP-DEV] $arr = array('Hello', 'world'); $arr();
> Date: Sun, 5 Jun 2011 12:52:45 -0300 (06/ 5/11 05:52:45 PM)
>
> johannes
>
>
Thank you.
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: $arr = array('Hello', 'world'); $arr();
Hi,
Hi all,
Reading our bug tracker I noticed a good feature request [1] from
2009 which
points to an interesting feature that I think makes sense for us,
since we
are now working with $f() using objects and strings, and the
array('class',
'method') is an old known for call_user_func()-like functions.
So, I wrote a patch [2] that allow such behavior to be consistent
with
arrays. See some examples:
class Hello {
public function world($x) {
echo "Hello, $x\n"; return $this;
}
}
$f = array('Hello','world');
var_dump($f('you'));
$f = array(new Hello, 'foo');
$f();
All such calls match with the call_user_func() behavior related to
magic
methods, static & non-static methods.
The array to be a valid callback should be a 2-element array, and it
must be
for the first element object/string and for the second string only.
(just
like our zend_is_callable() check and opcodes related to init call)
Any thoughts?
what happens if I use this code.
class Foo {
public $bar;
public function __construct() {
$this->bar = array($this, 'baz');
$this->bar();
}
public function bar() {
echo 'bar';
}
public function baz() {
echo 'baz';
}
}
new Foo();
What is the output of this snippet?
Are there the same rules as for closures?
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: $arr = array('Hello', 'world'); $arr();
Hi,
2011/6/8 Christian Kaps
> Hi,
>
>
> Hi all,
>> Reading our bug tracker I noticed a good feature request [1] from 2009
>> which
>> points to an interesting feature that I think makes sense for us, since we
>> are now working with $f() using objects and strings, and the
>> array('class',
>> 'method') is an old known for call_user_func()-like functions.
>>
>> So, I wrote a patch [2] that allow such behavior to be consistent with
>> arrays. See some examples:
>>
>> class Hello {
>> public function world($x) {
>> echo "Hello, $x\n"; return $this;
>> }
>> }
>>
>> $f = array('Hello','world');
>> var_dump($f('you'));
>>
>> $f = array(new Hello, 'foo');
>> $f();
>>
>> All such calls match with the call_user_func() behavior related to magic
>> methods, static & non-static methods.
>>
>> The array to be a valid callback should be a 2-element array, and it must
>> be
>> for the first element object/string and for the second string only. (just
>> like our zend_is_callable() check and opcodes related to init call)
>>
>> Any thoughts?
>>
>>
>
> what happens if I use this code.
>
> class Foo {
>
> public $bar;
>
> public function __construct() {
>
> $this->bar = array($this, 'baz');
> $this->bar();
> }
>
> public function bar() {
> echo 'bar';
> }
>
> public function baz() {
> echo 'baz';
> }
> }
>
> new Foo();
>
> What is the output of this snippet?
>
> Are there the same rules as for closures?
>
> Christian
>
>
Yes, the same rules.
--
Regards,
Felipe Pena
Re: [PHP-DEV] Re: $arr = array('Hello', 'world'); $arr();
On Wed, 8 Jun 2011 08:57:48 -0300, Felipe Pena wrote:
Hi,
2011/6/8 Christian Kaps
Hi,
what happens if I use this code.
class Foo {
public $bar;
public function __construct() {
$this->bar = array($this, 'baz');
$this->bar();
}
public function bar() {
echo 'bar';
}
public function baz() {
echo 'baz';
}
}
new Foo();
What is the output of this snippet?
Are there the same rules as for closures?
Christian
Yes, the same rules.
Hi,
I think for the sake of consistency it should be possible to use the
following code.
class Bar {
public function __construct($dispatcher) {
$dispatcher->addEventListener('onUpdate', $this->onUpdate);
}
public function onUpdate() {}
}
If a property $onUpdate exists then it will be ignored. The same rules
as for Closures or for array callbacks.
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Bundling "modern" extensions
> Please don't forget that it's possible to host your database apart from your > main code. Mongolab[1] While this is technically true, and as much as I love MongoDb, for all practical purposes this isn't really useful. The latency on these sorts of connections is generally totally unacceptable. Also, I'm inclined to agree that bundling won't have a large effect on whether hosts include certain modules; in my experience they seem to be fairly aggressive about culling modules that they don't like, or don't think will be useful. John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: $arr = array('Hello', 'world'); $arr();
2011/6/8 Christian Kaps
> On Wed, 8 Jun 2011 08:57:48 -0300, Felipe Pena wrote:
>
>> Hi,
>>
>> 2011/6/8 Christian Kaps
>>
>> Hi,
>>>
>>>
>>> what happens if I use this code.
>>>
>>> class Foo {
>>>
>>> public $bar;
>>>
>>> public function __construct() {
>>>
>>> $this->bar = array($this, 'baz');
>>> $this->bar();
>>> }
>>>
>>> public function bar() {
>>> echo 'bar';
>>> }
>>>
>>> public function baz() {
>>> echo 'baz';
>>> }
>>> }
>>>
>>> new Foo();
>>>
>>> What is the output of this snippet?
>>>
>>> Are there the same rules as for closures?
>>>
>>> Christian
>>>
>>>
>>> Yes, the same rules.
>>
>
> Hi,
>
> I think for the sake of consistency it should be possible to use the
> following code.
>
> class Bar {
>
>public function __construct($dispatcher) {
>
>$dispatcher->addEventListener('onUpdate', $this->onUpdate);
>}
>
>public function onUpdate() {}
> }
>
> If a property $onUpdate exists then it will be ignored. The same rules as
> for Closures or for array callbacks.
>
>
> Christian
>
>
>
>
It works in the same way:
class foo {
public function __construct() {
$this->bar = function () { return 1; };
// $this->bar(); // error
$x = $this->bar;
$x(); // ok
$this->bar = array($this, 'baz');
// $this->bar(); // error
$x = $this->bar;
$x(); // ok
}
public function baz() {
echo 'baz';
}
}
--
Regards,
Felipe Pena
Re: [PHP-DEV] Callable type
> No default values, other then NULL allowed.
> Otherwise we would need to support array("classname", "methodname")
> too, and then people would want default array values for array
> typehinting etc etc etc.
Unless I mis-read what you said, we already have default array values
for array type-hinting:
function foo(array $array = array('bar', 'baz')) {
var_dump($array);
}
foo();
foo(array());
Works perfectly for me on 5.3.6...
2011/6/8 Hannes Magnusson :
> 2011/6/8 Johannes Schlüter :
>> On Tue, 2011-06-07 at 12:12 -0700, Stas Malyshev wrote:
>>> Hi!
>>>
>>> > https://wiki.php.net/rfc/callable
>>>
>>> It is good there's an RFC. However it seems to lack code examples. I
>>> understand it may be obvious to the proposers how it looks like, but
>>> it'd be nice to have the actual example there as it is done nearly
>>> everywhere else.
>>
>> The RFC is missing information about what happens in codebases which
>> already have a "callable" type declared. Will that be prevented or will
>> they hit a runtime error? ("callable expected, callable type found")
>
> You mean an interface/class with that name?
> The error would be 'expected instanceof callable, string/array/closure
> recieved.
>
> gettype("strpos") will still return a string, not callable.
>
> A callable wouldn't be fully featured type.
>
>> What about default values? Will
>> function foo(callback $cb = 'strpos') { }
>> be valid?
>
> No default values, other then NULL allowed.
> Otherwise we would need to support array("classname", "methodname")
> too, and then people would want default array values for array
> typehinting etc etc etc.
>
>
>
>> The information on reflection is limited. what shall
>> Reflection::Parameter::getTypehint() return? Will that method allow to
>> differ between a class type and this "magic"?
>
> There is no such method anymore :)
>
>
>>
>> What about ARGINFO? Will internal functions be able to define this type
>> via ARGINFO? How will this be reported in `php --rf function`?
>
> I didn't include arginfo in the patch, but good point. It should
> probably be included.
> As Felipe pointed out, ext/reflection hasn't been updated.
> It should return [ callable $foobar ], just like with any other typehint
>
> -Hannes
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: $arr = array('Hello', 'world'); $arr();
On Wed, Jun 8, 2011 at 2:46 PM, Felipe Pena wrote:
> class foo {
> public function __construct() {
> $this->bar = function () { return 1; };
> // $this->bar(); // error
> $x = $this->bar;
> $x(); // ok
>
> $this->bar = array($this, 'baz');
> // $this->bar(); // error
> $x = $this->bar;
> $x(); // ok
> }
> public function baz() {
> echo 'baz';
> }
> }
What he meant was passing an existing method as a callback if you
don't invoke it, i.e. passing "$this->bar" instead of array($this,
"bar"). I don't know how hard it'd be to achieve, but it sounds pretty
awesome to me.
Cheers
--
Jordi Boggiano
@seldaek :: http://seld.be/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: $arr = array('Hello', 'world'); $arr();
On Wed, 8 Jun 2011 09:46:26 -0300, Felipe Pena wrote:
It works in the same way:
class foo {
public function __construct() {
$this->bar = function () { return 1; };
// $this->bar(); // error
$x = $this->bar;
$x(); // ok
$this->bar = array($this, 'baz');
// $this->bar(); // error
$x = $this->bar;
$x(); // ok
}
public function baz() {
echo 'baz';
}
}
OK, my mistake. I thought a property which holds a closure can be
called directly.
Thanks for clarification.
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: $arr = array('Hello', 'world'); $arr();
On Wed, 8 Jun 2011 15:39:59 +0200, Jordi Boggiano wrote:
On Wed, Jun 8, 2011 at 2:46 PM, Felipe Pena
wrote:
class foo {
public function __construct() {
$this->bar = function () { return 1; };
// $this->bar(); // error
$x = $this->bar;
$x(); // ok
$this->bar = array($this, 'baz');
// $this->bar(); // error
$x = $this->bar;
$x(); // ok
}
public function baz() {
echo 'baz';
}
}
What he meant was passing an existing method as a callback if you
don't invoke it, i.e. passing "$this->bar" instead of array($this,
"bar"). I don't know how hard it'd be to achieve, but it sounds
pretty
awesome to me.
Cheers
Yep, just what I meant.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
Martin Scotta On Wed, Jun 8, 2011 at 5:47 AM, Alexey Shein wrote: > 2011/6/8 Hannes Magnusson : > > We have the situation in the docs that parameters declared as arrays > > do not follow the typehinting rules, but parameters as class names do. > > Re-using the callback from the docs could get confusing when > > extensions start to typehint on it, but not the core.. > > > > I think there is a subtle difference between a callback, and a callable. > > In javascript for example, callback is something that is executed on > > certain events "onsuccess" is the typical example. > > There is nothing that says the callable parameter gets executed as a > > part of an event, and I think the default usecase would be to execute > > it right away (f.e. filtering data). > > > > I think I would prefer callable, but I could live with either. > > > > Wikipedia defines callback as "a reference to executable code, or a > piece of executable code, that is passed as an argument to other > code". So there's no "event" meaning put by default, it's just very > often seen callback's usage in javascript. > I just like "callback" term more :) > so 'strpos' is not a reference nor a piece of executable code, it's just the name of a function, which is callable, although we can argue if the function name could be seen as a reference to the code > > > -- > Regards, > Shein Alexey > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] Callable type
Martin Scotta
On Wed, Jun 8, 2011 at 10:31 AM, Anthony Ferrara wrote:
> > No default values, other then NULL allowed.
> > Otherwise we would need to support array("classname", "methodname")
> > too, and then people would want default array values for array
> > typehinting etc etc etc.
>
> Unless I mis-read what you said, we already have default array values
> for array type-hinting:
>
> function foo(array $array = array('bar', 'baz')) {
>var_dump($array);
> }
>
> foo();
>
> foo(array());
>
> Works perfectly for me on 5.3.6...
>
it works since long time ago
>
> 2011/6/8 Hannes Magnusson :
> > 2011/6/8 Johannes Schlüter :
> >> On Tue, 2011-06-07 at 12:12 -0700, Stas Malyshev wrote:
> >>> Hi!
> >>>
> >>> > https://wiki.php.net/rfc/callable
> >>>
> >>> It is good there's an RFC. However it seems to lack code examples. I
> >>> understand it may be obvious to the proposers how it looks like, but
> >>> it'd be nice to have the actual example there as it is done nearly
> >>> everywhere else.
> >>
> >> The RFC is missing information about what happens in codebases which
> >> already have a "callable" type declared. Will that be prevented or will
> >> they hit a runtime error? ("callable expected, callable type found")
> >
> > You mean an interface/class with that name?
> > The error would be 'expected instanceof callable, string/array/closure
> recieved.
> >
> > gettype("strpos") will still return a string, not callable.
> >
> > A callable wouldn't be fully featured type.
> >
> >> What about default values? Will
> >>function foo(callback $cb = 'strpos') { }
> >> be valid?
> >
> > No default values, other then NULL allowed.
> > Otherwise we would need to support array("classname", "methodname")
> > too, and then people would want default array values for array
> > typehinting etc etc etc.
> >
> >
> >
> >> The information on reflection is limited. what shall
> >> Reflection::Parameter::getTypehint() return? Will that method allow to
> >> differ between a class type and this "magic"?
> >
> > There is no such method anymore :)
> >
> >
> >>
> >> What about ARGINFO? Will internal functions be able to define this type
> >> via ARGINFO? How will this be reported in `php --rf function`?
> >
> > I didn't include arginfo in the patch, but good point. It should
> > probably be included.
> > As Felipe pointed out, ext/reflection hasn't been updated.
> > It should return [ callable $foobar ], just like with any other typehint
> >
> > -Hannes
> >
> > --
> > 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] Callable type
He means
function foo(callback derp = array('MyClass', 'ohai')) { ... }
David
On 08.06.2011, at 15:31, Anthony Ferrara wrote:
>> No default values, other then NULL allowed.
>> Otherwise we would need to support array("classname", "methodname")
>> too, and then people would want default array values for array
>> typehinting etc etc etc.
>
> Unless I mis-read what you said, we already have default array values
> for array type-hinting:
>
> function foo(array $array = array('bar', 'baz')) {
> var_dump($array);
> }
>
> foo();
>
> foo(array());
>
> Works perfectly for me on 5.3.6...
>
> 2011/6/8 Hannes Magnusson :
>> 2011/6/8 Johannes Schlüter :
>>> On Tue, 2011-06-07 at 12:12 -0700, Stas Malyshev wrote:
Hi!
> https://wiki.php.net/rfc/callable
It is good there's an RFC. However it seems to lack code examples. I
understand it may be obvious to the proposers how it looks like, but
it'd be nice to have the actual example there as it is done nearly
everywhere else.
>>>
>>> The RFC is missing information about what happens in codebases which
>>> already have a "callable" type declared. Will that be prevented or will
>>> they hit a runtime error? ("callable expected, callable type found")
>>
>> You mean an interface/class with that name?
>> The error would be 'expected instanceof callable, string/array/closure
>> recieved.
>>
>> gettype("strpos") will still return a string, not callable.
>>
>> A callable wouldn't be fully featured type.
>>
>>> What about default values? Will
>>>function foo(callback $cb = 'strpos') { }
>>> be valid?
>>
>> No default values, other then NULL allowed.
>> Otherwise we would need to support array("classname", "methodname")
>> too, and then people would want default array values for array
>> typehinting etc etc etc.
>>
>>
>>
>>> The information on reflection is limited. what shall
>>> Reflection::Parameter::getTypehint() return? Will that method allow to
>>> differ between a class type and this "magic"?
>>
>> There is no such method anymore :)
>>
>>
>>>
>>> What about ARGINFO? Will internal functions be able to define this type
>>> via ARGINFO? How will this be reported in `php --rf function`?
>>
>> I didn't include arginfo in the patch, but good point. It should
>> probably be included.
>> As Felipe pointed out, ext/reflection hasn't been updated.
>> It should return [ callable $foobar ], just like with any other typehint
>>
>> -Hannes
>>
>> --
>> 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
>
>
smime.p7s
Description: S/MIME cryptographic signature
[PHP-DEV] SVN Account Request: itanea
Translating documentation in french -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Sites still down?
What is the current state of play on the sites that were taken down in March. I'm trying to get a clean copy of files from http://pecl2.php.net/downloads/php-windows-builds/php-libs/ -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Sites still down?
On 8 June 2011 22:24, Lester Caine wrote: > What is the current state of play on the sites that were taken down in > March. I'm trying to get a clean copy of files from > http://pecl2.php.net/downloads/php-windows-builds/php-libs/ Take a look at http://windows.php.net/downloads/php-sdk/ In fact, take a look around http://windows.php.net/downloads. Different bundles of libraries, depending upon what you are building. I've just started building 5.4, so needed new libraries for GD. Thanks to the long suffering Pierre for the URL to this (Pierre, I remembered it ... see). Richard. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Sites still down?
Richard Quadling wrote: What is the current state of play on the sites that were taken down in > March. I'm trying to get a clean copy of files from > http://pecl2.php.net/downloads/php-windows-builds/php-libs/ Take a look athttp://windows.php.net/downloads/php-sdk/ In fact, take a look aroundhttp://windows.php.net/downloads. Different bundles of libraries, depending upon what you are building. I've just started building 5.4, so needed new libraries for GD. Thanks to the long suffering Pierre for the URL to this (Pierre, I remembered it ... see). TA - all the wiki pages are point elsewhere ;) I'd just got to https://wiki.php.net/internals/windows/libs?s[]=windows as well -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
