Hi Dmitry
On 8.8.2008 17:52 Uhr, Dmitry Stogov wrote:
Hi,
The attached patch is going to fix the problem.
Works also on my OS X 10.4 box now. Thanks a lot for the effort (and if
it brings a performance boost, even better :) )
chregu
It implements its own realpath() function, so we won'
Hi!
I'm not sure to like the idea. I'm not a fan of OO strictness but I'd
to agree with Marcus, I do not expect a reference from an overrided
How can you "not expect reference"? I.e. which code that worked
previously wouldn't work now?
__get. There is also the problem with internal classes
hi!
On Sat, Aug 9, 2008 at 1:50 AM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> Hi!
>
>> I know that we don't like to add new magic methods, but this case
>> seems to require new ones. What's about __getByRef (and its setter
>> equivalent if it is also not supported yet)?
>
> Why would we need
Hi!
I know that we don't like to add new magic methods, but this case
seems to require new ones. What's about __getByRef (and its setter
equivalent if it is also not supported yet)?
Why would we need that? We already have perfectly good __get, which can
perfectly return by-ref. The question i
Hi!
What makes you think there won't be a problem with the reverse. The caller
does not expect a reference but the calle returns one? In OOP the return
Well, I don't know any case where $a = foo() would work in a
substantially different way for the user if foo() returns by-ref and not
by-val
hi Stanislav , Marcus,
On Sat, Aug 9, 2008 at 1:00 AM, Marcus Boerger <[EMAIL PROTECTED]> wrote:
> Hello Stanislav,
>
> Saturday, August 9, 2008, 12:40:34 AM, you wrote:
>
>> Hi!
>
>>> Yes, it breaks the principle. E.g. caller knows callee returns by ref - you
>>> break this, as easy as that.
>
>>
Hello Stanislav,
Saturday, August 9, 2008, 12:40:34 AM, you wrote:
> Hi!
>> Yes, it breaks the principle. E.g. caller knows callee returns by ref - you
>> break this, as easy as that.
> I'm sorry I think you misunderstood my proposal. I proposed allowing
> overriding this:
> public function __
Hi!
Yes, it breaks the principle. E.g. caller knows callee returns by ref - you
break this, as easy as that.
I'm sorry I think you misunderstood my proposal. I proposed allowing
overriding this:
public function __get($name)
with this:
public function &__get($name)
but not the reverse. So if
Hello Christian, Johannes,
Friday, August 8, 2008, 11:48:37 PM, you wrote:
> Hello Christian,
> I updated your patch for 5.3 due to recent changes. It works pretty fine
> for me. Care to test again, especially with your new tests? Note that test
> ext/reflection/tests/closures_001.phpt does no
Hello Stanislav,
Saturday, August 9, 2008, 12:16:29 AM, you wrote:
> Hi!
>> I think we may want to stick to our is-a mantra.
> I'm not sure I understand what you mean here. But our principle was to
> allow things that do not violate the LSP - such as adding optional
> parameters, for exampl
Hi!
I think we may want to stick to our is-a mantra.
I'm not sure I understand what you mean here. But our principle was to
allow things that do not violate the LSP - such as adding optional
parameters, for example. I think returning by-ref can be allowed on the
same principle. Is there a
Hello Stanislav,
I think we may want to stick to our is-a mantra.
marcus
Friday, August 8, 2008, 10:32:53 PM, you wrote:
> Hi!
> Right now, strict inheritance rules do not allow to override
> public function __get($name)
> with
> public function & __get($name)
> I think we may want to allow
Hello Greg,
Monday, August 4, 2008, 10:37:23 PM, you wrote:
> Rasmus Lerdorf wrote:
>> Jani Taskinen wrote:
>>> -- Changed PCRE, Reflection and SPL extensions to always be enabled.
>>> (Marcus)
>>> +- Changed PCRE, Reflection and SPL extensions to be always enabled.
>>> (Marcus)
>>
>> That was
Hello Christian,
I updated your patch for 5.3 due to recent changes. It works pretty fine
for me. Care to test again, especially with your new tests? Note that test
ext/reflection/tests/closures_001.phpt does not work for me and I have no
clue why. Well, besides that obviously the closure class
Rasmus Lerdorf wrote:
Dmitry Stogov wrote:
Hi,
The attached patch is going to fix the problem.
It implements its own realpath() function, so we won't depend on system
anymore. It also improve realpath cache usage by caching intermediate
results.
Very nice. The intermediate caching is going to
Dmitry Stogov wrote:
Hi,
The attached patch is going to fix the problem.
It implements its own realpath() function, so we won't depend on system
anymore. It also improve realpath cache usage by caching intermediate
results.
Very nice. The intermediate caching is going to drastically reduce th
Just semantics but I'd name the function 'tsrm_realpath[_r]' to be absolutely
clear what it does.
--Jani
Dmitry Stogov kirjoitti:
Hi,
The attached patch is going to fix the problem.
It implements its own realpath() function, so we won't depend on system
anymore. It also improve realpath cach
Hi!
Right now, strict inheritance rules do not allow to override
public function __get($name)
with
public function & __get($name)
I think we may want to allow this (but not the reverse - overriding
by-ref return with by-val should not be allowed). Since by-ref return
still can be used in by-va
Hello Lukas,
Friday, August 8, 2008, 9:01:42 PM, you wrote:
> On 08.08.2008, at 15:18, Marcus Boerger wrote:
>> helly Fri Aug 8 13:18:31 2008 UTC
>>
>> Modified files:
>> /ZendEngine2zend_execute_API.c
>> /php-src/mainphp.h
>> Log:
>> - PHP 5.3 todo, store error handl
Hello Etienne,
Friday, August 8, 2008, 9:54:49 PM, you wrote:
> Hello,
> On Fri, Aug 8, 2008 at 9:50 PM, Etienne Kneuss <[EMAIL PROTECTED]> wrote:
>> Hello,
>>
>> On Fri, Aug 8, 2008 at 7:10 PM, Marcus Boerger <[EMAIL PROTECTED]> wrote:
>>> helly Fri Aug 8 17:10:49 2008 UTC
>>>
>>> M
Hello,
On Fri, Aug 8, 2008 at 9:01 PM, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
>
> On 08.08.2008, at 15:18, Marcus Boerger wrote:
>
>> helly Fri Aug 8 13:18:31 2008 UTC
>>
>> Modified files:
>> /ZendEngine2 zend_execute_API.c
>> /php-src/main php.h
>> Log:
>> - PHP 5.3 todo, s
On Fri, Aug 8, 2008 at 21:54, Etienne Kneuss <[EMAIL PROTECTED]> wrote:
> Forgot to mention it: there is something weird in mysqli_driver.c, I
> don't know what the author's original intention was, but it looks
> wrong.
> c.f. FIXME
I think I already filed a bug report about that some months ago,
Hello,
On Fri, Aug 8, 2008 at 9:50 PM, Etienne Kneuss <[EMAIL PROTECTED]> wrote:
> Hello,
>
> On Fri, Aug 8, 2008 at 7:10 PM, Marcus Boerger <[EMAIL PROTECTED]> wrote:
>> helly Fri Aug 8 17:10:49 2008 UTC
>>
>> Modified files:
>>/php-src/main main.c php.h
>>/ZendEngine2
Hello,
On Fri, Aug 8, 2008 at 7:10 PM, Marcus Boerger <[EMAIL PROTECTED]> wrote:
> helly Fri Aug 8 17:10:49 2008 UTC
>
> Modified files:
>/php-src/main main.c php.h
>/ZendEngine2zend.h zend_API.c zend_execute_API.c zend_vm_def.h
>zend_vm_ex
On 08.08.2008, at 15:18, Marcus Boerger wrote:
helly Fri Aug 8 13:18:31 2008 UTC
Modified files:
/ZendEngine2 zend_execute_API.c
/php-src/main php.h
Log:
- PHP 5.3 todo, store error handling mode on stack when executing
internal
or overloaded functions and methods. The issue
On 08.08.2008, at 15:18, Marcus Boerger wrote:
helly Fri Aug 8 13:18:31 2008 UTC
Modified files:
/ZendEngine2zend_execute_API.c
/php-src/main php.h
Log:
- PHP 5.3 todo, store error handling mode on stack when executing
internal
or overloaded functions and methods. The issue
On 08.08.2008, at 15:18, Marcus Boerger wrote:
helly Fri Aug 8 13:18:31 2008 UTC
Modified files:
/ZendEngine2 zend_execute_API.c
/php-src/main php.h
Log:
- PHP 5.3 todo, store error handling mode on stack when executing
internal
or overloaded functions and methods. The issue
Great! :)
It's mean I'm on the right way.
The patch still needs additional work and testing, but I hope it'll be
ready before alpha 2.
Thanks. Dmitry.
Arnaud Le Blanc wrote:
> Hi,
>
> On Friday 08 August 2008 17:52:26 Dmitry Stogov wrote:
>> Hi,
>>
>> The attached patch is going to fix the probl
Hi,
On Friday 08 August 2008 17:52:26 Dmitry Stogov wrote:
> Hi,
>
> The attached patch is going to fix the problem.
> It implements its own realpath() function, so we won't depend on system
> anymore. It also improve realpath cache usage by caching intermediate
> results.
>
> I tested it on Linux
Hi Pierre,
Thank you for feedback.
I already noticed the missing FindClose() and several other issues.
I'll send updated patch on weekend, but the sooner I get info if bug is
fixed on FreeBSD the better.
Thanks. Dmitry.
Pierre Joye wrote:
> Hi Dmitry,
>
> On Fri, Aug 8, 2008 at 5:52 PM, Dmitry
Hi Dmitry,
On Fri, Aug 8, 2008 at 5:52 PM, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
> Hi,
>
> The attached patch is going to fix the problem.
> It implements its own realpath() function, so we won't depend on system
> anymore. It also improve realpath cache usage by caching intermediate
> results.
Hi,
The attached patch is going to fix the problem.
It implements its own realpath() function, so we won't depend on system
anymore. It also improve realpath cache usage by caching intermediate
results.
I tested it on Linux and Windows only and it seems to work without
problems. It breaks one tes
On Fri, 8 Aug 2008, Rui Hirokawa wrote:
> "Chris Stockton" <[EMAIL PROTECTED]> wrote:
>
> > fixed bug #27421 (by david at dfoerster dot de) mbstring.func_overload
> > set in .htaccess becomes global
>
> There are a typo in NEWS of PHP 4.4.9.
> #37421 should be #27421.
Fixed
Derick
--
HEAD be
There are a typo in NEWS of PHP 4.4.9.
#37421 should be #27421.
> fixed bug #27421 (by david at dfoerster dot de) mbstring.func_overload
> set in .htaccess becomes global
Rui
On Thu, 7 Aug 2008 14:09:47 -0700
"Chris Stockton" <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Is the link in the changelo
On Thu, Aug 7, 2008 at 22:37, Arnaud Le Blanc <[EMAIL PROTECTED]> wrote:
> virtual_file_ex() assumes that realpath() returns NULL when the file does not
> exists. But BSD's realpath() will not return NULL if all
> components *but the last* exist. So realpath(/foo/bar) will return /foo/bar
> even if
35 matches
Mail list logo
