2009/5/16 Jingcheng Zhang :
>
> Maybe I have not found its detailed description on PHP's official manual,
> but PHP does allow static field inheritance. However there is a little
> difference between dynamic field inheritance and static field inheritance,
> as the following codes shows:
Hi!
I thi
2009/2/15 Michael Wallner :
> Robin Fernandes wrote:
>>
>> robinf Sun Dec 28 19:50:58 2008 UTC
>>
>> Added files:/php-src/tests/output bug46903.phpt
>> bug46900.phpt
>> Modified files: /php-src/
>> Addressing those two points would make things even more consistent.
>> I'm adding some testcases to illustrate.
>
> I fixed the callback case in 5_2. Need to talk to Dmitry about 5_3 and HEAD
> because zend_is_callable_check_func() is damn complex now.
>
> -Andrei
>
Thanks!
I noticed another i
2009/1/6 David Coallier :
>> call to __call() on private method invocation. The former approach presents
>> more of a BC
>> problem IMHO, so I am advocating the latter. I've attached a simple patch
>> for consideration.
>>
>
> I'd say go ahead, this sounds like common sense to be consistent in
> bo
2008/8/3 Marcus Boerger <[EMAIL PROTECTED]>:
>
>> Attached. I just naively moved some logic from __construct() into a
>> separate function and called it from both __construct() and
>> exchangeArray().
>
> Well, naively or not, this seems about perfectly correct. Why don't you
> simply apply this to
Hi Marcus!
>> 1. What should happen when the argument is an object?
>
> Seems like an error message is missing there. It allows to take an instance
> of another ArrayObject/Iterator and use the array from that.
>
> In case any other Object is passed it is ignored. What do you feel?
Sounds alright
Hi all,
I have two questions about the intended behaviour of
ArrayObject::exchangeArray() :
1. What should happen when the argument is an object?
The docs suggest that the arg should be an array, but the prototype in
the code indicates objects are OK too. However, when an object is
passed, the e
Hi all, thanks for thinking about this.
On 26/03/2008, Marcus Boerger <[EMAIL PROTECTED]> wrote:
> On 26/03/2008, Alexey Zakhlestin <[EMAIL PROTECTED]> wrote:
>
> > use case for "protected" is similiar, but relates to cases when you
> > have hierarchy of classes, which still have some common fu
Hi Felipe,
On 25/03/2008, Felipe Pena <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Do we keep the support added in http://bugs.php.net/bug.php?id=37632
> (that isn't supported in C++, for instance)
My preference would be to completely remove this behaviour, by which
protected methods can be invoked
Hi Johannes,
This bug suggests the output buffering re-write in HEAD would be
backported to 5_3: http://bugs.php.net/bug.php?id=42641
Is that still in plan?
I have added it as a "To be discussed" item on http://wiki.php.net/todo/php53.
Regards,
Robin
--
PHP Internals - PHP Runtime Development
Hi Dmitry,
On 13/03/2008, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
> I have separated fixes and optimizations from the delayed early binding
> itself and added comments about options. Now the patch must be more clear.
>
Thanks, that's really interesting.
As mentioned on http://turl.ca/ynny, I'm
Hi phpxcache,
On 08/03/2008, phpxcache <[EMAIL PROTECTED]> wrote:
> all test cases that pass without XCache now pass
> with XCache too.
Are these tests that are already in the cvs repository? If not, it
would be great to get them in. Sounds like they could be useful
whether or not the patch gets
On 26/02/2008, Robin Fernandes <[EMAIL PROTECTED]> wrote:
>
> On 28/01/2008, Marcus Boerger <[EMAIL PROTECTED]> wrote:
> > >
> > > I checked it out in more detail and it is indeed broken as in it is
> not
> > > consistent
>
>
Hi all,
At compile time, the engine detects whether $this is used in an op
array (using opline_is_fetch_this()). If so, it sets the flag
op_array->uses_this.
At the start of each execute loop, if this flag is set and a context
object is available, a reference to the context object is added to the
Hi Marcus,
On 28/01/2008, Marcus Boerger <[EMAIL PROTECTED]> wrote:
> >
> > I checked it out in more detail and it is indeed broken as in it is not
> > consistent
If possible, I'd like to revive this discussion. Patch included. :)
History: http://thread.gmane.org/gmane.comp.php.devel/47956/f
Hi all,
The fix to bug 37212 (http://bugs.php.net/bug.php?id=37632) introduced
an unusual method accessibility rule. A class can access a protected
method declared outside of its own direct class hierarchy if that
method has a prototype in a common superclass.
This is achieved using by zend_get
Contributing test cases (phpts). I have sent some tests to the QA list
(http://news.php.net/php.qa/61935) and intend to contribute more in the near
future.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Marcus,
Thanks for looking in more detail.
> I checked it out in more detail and it is indeed broken as in it is not
> consistent:
> [EMAIL PROTECTED] PHP_5_3]$ php -r 'class A { protected static $p=1; } class
> B extends A { protected static $p=2; } ReflectionClass::Export("B");'
> -> works =
Hi Marcus,
Thanks for the prompt reply and explanation. I have some further
questions though:
> If the base class had the property defined as private
> then the property is private to that specific class and not directly
> accessible by derived classes that is it's name gets prefixed with the cla
Hi all,
If a protected static property is overridden by a public static
property, both properties share the same value:
This behaviour feels strange to me, because:
1. It only applies to that specific combination of visibility
modifiers. If you change A::$a to public OR B::$a to protected, the
Sorry to persist with this, but I think it could be really useful to
clarify the meaning of static:: outside of method bodies...
particularly since parent:: and self:: can already behave very
strangely in such scenarios (see
http://news.php.net/php.internals/32443 ).
For example, I find the follow
ot;
- In B: string(10) "MY_CONST_A"
Instance Properties
- In A: string(10) "MY_CONST_A"
- In B: string(10) "MY_CONST_A"
Constants:
- In A: string(10) "MY_CONST_A"
- In B: string(10) "MY_CONST_A"
Static call:
- From A: string(10) "MY_CONST_A"
- From B: string(10) "MY_CONST_A"
Instance call:
- From A: string(10) "MY_CONST_A"
- From B: string(10) "MY_CONST_A"
Kind regards,
Robin Fernandes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi all,
There has been some discussion on this list about late static binding
and the 'self' & 'parent' keywords. I'm looking to understand the
meaning of self:: and parent:: when used in the declaration of an
inherited class property or constant.
Based on discussions here and on comments to bugs
23 matches
Mail list logo
