You could see about 20 tests with the latest patch.
2 of them especially to show inheritance problem.
Thanks. Dmitry.
> -Original Message-
> From: Zoe Slattery [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 20, 2007 10:54 PM
> To: Stanislav Malyshev
> Cc: Dmitry Stogov; 'Marcus Bo
Do you have any ideas on how to allow this to be at all useful with
inheritance and overriding? If the patch is left to where these examples
would all return 'A' and something wasn't put in place to allow
overloading a static function AND forward on the original called class
What do you mean
From technical point of view it is possible to propagate LSB with self::,
parent::, and static:: and not with CLASS::.
I think it may be a good compromise.
I am very much in favor of this. I think it allows the greatest amount of
control. If you need a specific class's static method called then
I hope I won't bother you with obvious things, but I think Stefan has
pointed out something important about LSB: the importance of the relative
access (like parent::), and the ambiguity of the context. It's not a problem
of static data.
Let me give an example, from my present real-life.
I am writi
How about writing the test cases first - and then the patch?
I'm fine with that - that's why I asking people for examples of what
they want to do with it.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Inte
Stanislav Malyshev wrote:
So we have at least three different views on concept.
It seems that patch will be delayed again. :(
I think we better spend time on figuring out the concept and then do
the patch than first do the patch and then discover we don't know how
it was supposed to work :)
The basic idea would be to add API functions like
zend_op_array_add_data(key, data, size, flags)
zend_op_array_remove_data()... zend_op_array_get_data,
zend_op_array_get_all_data
In the flags one could choose: Needs to be cached etc...
Well and this will be stored in a datastructure that will jus
One problem I and others have run into is that from time to time we need
to store extra information for specific opcode arrays. For simple values
it is possible to use one of the reserved slots in the op_array
structure, but in the past that has been unrelieable because APC for
example simply over
Does closing php tags end the namespace declaration? ie would the
following work:
php tags would not influence namespace declarations, i.e. it would
continue as if there were just PHP code.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829
Is it possible or feasible to distinguish betwenn parent:: and
NameOfParentClass::? That would allow to push a call "up" while
I'm not sure I understand - what's the difference? Can you give an example?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408
So we have at least three different views on concept.
It seems that patch will be delayed again. :(
I think we better spend time on figuring out the concept and then do the
patch than first do the patch and then discover we don't know how it was
supposed to work :)
--
Stanislav Malyshev, Zend
On 9/11/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> if the
> file has namespaces, then it can have no code outside namespaces.
This seems like a great compromise, FWIW +1 here.
Does closing php tags end the namespace declaration? ie would the
following work:
namespace foo;
class a
{
pub
On Thu, 20 Sep 2007, Stefan Esser wrote:
> Derick Rethans schrieb:
> > On Thu, 20 Sep 2007, Stefan Esser wrote:
> >
> >
> >> One problem I and others have run into is that from time to time we need
> >> to store extra information for specific opcode arrays. For simple values
> >> it is possible
Derick Rethans schrieb:
> On Thu, 20 Sep 2007, Stefan Esser wrote:
>
>
>> One problem I and others have run into is that from time to time we need
>> to store extra information for specific opcode arrays. For simple values
>> it is possible to use one of the reserved slots in the op_array
>> str
On Thu, 20 Sep 2007, Stefan Esser wrote:
> One problem I and others have run into is that from time to time we need
> to store extra information for specific opcode arrays. For simple values
> it is possible to use one of the reserved slots in the op_array
> structure, but in the past that has bee
Is it possible or feasible to distinguish betwenn parent:: and
NameOfParentClass::? That would allow to push a call "up" while
preserving the called name while not making Class:: mean different
things depending on the location of the call, which is a very bad thing
IMO (it's an effect that may not
Hi everyone,
I would like to use this list to address the major players in bytecode
caching tools: Zend, APC, Xcache...
One problem I and others have run into is that from time to time we need
to store extra information for specific opcode arrays. For simple values
it is possible to use one of th
>From technical point of view it is possible to propagate LSB with self::,
parent::, and static:: and not with CLASS::.
I think it may be a good compromise.
Thanks. Dmitry.
> -Original Message-
> From: Stefan Walk [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 20, 2007 1:10 PM
> T
18 matches
Mail list logo
