So we have at least three different views on concept.
It seems that patch will be delayed again. :(
Thanks. Dmitry.
-Original Message-
From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 19, 2007 8:51 PM
To: Dmitry Stogov
Cc: 'Marcus Boerger'; 'Lukas Kahwe
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
To:
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
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
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 been
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
structure,
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 to use one of
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
{
public
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,
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/
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
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
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
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 :)
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
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
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
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
18 matches
Mail list logo
