On Sat, Jun 13, 2009 at 23:16, Michael wrote:
> Now that there's namespaces are we getting access modifiers on
> class/functions ?
Not in 5.3 at least (see http://php.net/namespaces).
And there is a good chance PHP will never have those...
-Hannes
--
PHP Internals - PHP Runtime Development Mai
2009/6/13 Michael :
> Now that there's namespaces are we getting access modifiers on
> class/functions ?
> eg.
>
> namespace Foo;
>
> private function bar() { }
> public class Baz { }
No thats not implemented, and I don't belive there are any plans to
implement it currently
>
> ---
> Michael
>
Now that there's namespaces are we getting access modifiers on
class/functions ?
eg.
namespace Foo;
private function bar() { }
public class Baz { }
---
Michael
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,
[quote from off-list:]
> I am in way over my head and would not do a good job
> fixing these (or have the time), care to take a crack at it?
Ok, I'll do that tomorrow morning.
> I wonder if the problem is that
> spl_autoload_register should not just be checking to see if zcallable is
> IS_OB
Christian Seiler wrote:
> Hi Greg,
>
>
>> (I meant commit when I said patch, sorry :)
>>
>> http://news.php.net/php.cvs/58696
>> and
>> http://news.php.net/php.cvs/58697
>>
>
> Thanks, looks fine to me. However, I noticed that closures don't work
> with spl_autoload_unregister() and spl_aut
hi,
On Sat, Jun 13, 2009 at 8:01 PM, Christian Seiler wrote:
> This ensures that FPUs on x86 systems are definitely in double precision
> mode. The default situation on Windows with MSVC is that the FPU is
> already in double precision setting as far as I've tested it - however
> there are situat
Hi Pierre,
(Btw. you got the wrong Christian as CC. ;-))
> There is still a significant performance impact due to _controlfp_s
> usage.
Huh? After the modification I made this should only called once (!) at
PHP startup Or did we miss something? Anyway, calling it once should not
cause any perfor
Hi Greg,
> (I meant commit when I said patch, sorry :)
>
> http://news.php.net/php.cvs/58696
> and
> http://news.php.net/php.cvs/58697
Thanks, looks fine to me. However, I noticed that closures don't work
with spl_autoload_unregister() and spl_autoload_functions(). Also,
classes that define __in
hi Christian,
There is still a significant performance impact due to _controlfp_s
usage. I would like to remove it, but before I would also like to know
why you introduced it in the 1st place. The tests pass with or without
changing the fp on almost each fp ops (sigh :).
Can you explain why we ne
Christian Seiler wrote:
> Hi Greg,
>
>> I can do it if someone can answer this question: how do closures
>> uniquely identify themselves? spl_autoload_register is mistakenly
>> treating all closures as if they were a single copy of the static method
>> "Closure::__invoke", and so only the first r
Mark Karpeles wrote:
> Hello,
>
> After extracting my freshly downloaded copy of PHP 5.3.0RC3, I decided
> to read NEWS and saw something that caught my attention:
>
> - Fixed isset() on sub-directories (isset("blah") if file "blah/foo.php"
> exists). (Greg)
>
> Derick agreed with me on the fa
Hi Greg,
> I can do it if someone can answer this question: how do closures
> uniquely identify themselves? spl_autoload_register is mistakenly
> treating all closures as if they were a single copy of the static method
> "Closure::__invoke", and so only the first registered closure is ever
> call
Hello,
After extracting my freshly downloaded copy of PHP 5.3.0RC3, I decided
to read NEWS and saw something that caught my attention:
- Fixed isset() on sub-directories (isset("blah") if file "blah/foo.php"
exists). (Greg)
Derick agreed with me on the fact this doesn't makes much sense.
Whil
13 matches
Mail list logo
