>> - static always points to the original callee, w/o being "broken" by
>> parent::
>> - get_called_class() should _not_ behave like shown above. It really was
>> not B that got called, but it was A, trough parent::
>> - a new get_static_class() method should return "B".
>
> Ouch. So now not only w
Hi!
Of course, we can't make parent:: reference the parent class of the called
one, as it would break BC.
As in:
class A { }
class B extends A { public static function test() { echo get_class(new
parent), '-', get_parent_class(); } }
class C extends B { }
C::test(); // A-A and not B-B
Maybe y
Am 26.11.2007 um 19:13 schrieb Stanislav Malyshev:
- static always points to the original callee, w/o being "broken"
by parent::
- get_called_class() should _not_ behave like shown above. It
really was not B that got called, but it was A, trough parent::
- a new get_static_class() method sho
- static always points to the original callee, w/o being "broken" by
parent::
- get_called_class() should _not_ behave like shown above. It really was
not B that got called, but it was A, trough parent::
- a new get_static_class() method should return "B".
Ouch. So now not only we have parent:
Am 26.11.2007 um 10:24 schrieb Alexey Zakhlestin:
On 11/26/07, Mike Lively <[EMAIL PROTECTED]> wrote:
class A {
public static function test() {
echo get_called_class()."\n";
}
}
class B extends A {
public static function test() {
parent::test();
}
}
A::test();
B::test(
Alexey Zakhlestin wrote:
On 11/26/07, Mike Lively <[EMAIL PROTECTED]> wrote:
I have come up with three different patches that allow us to work around
the issue of parent:: being considered an 'explicit class reference' and
thus disallowing static:: to effectively used.
The patches are against 5
On 11/26/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > I believe this first patch is the proper way to go. It feels
> > "natural", "intuitive", etc.
>
> I don't see how making parent::foo() and A::foo() work differently is
> either "natural" or "intuitive".
A::foo() doesn't mean any inheri
I believe this first patch is the proper way to go. It feels
"natural", "intuitive", etc.
I don't see how making parent::foo() and A::foo() work differently is
either "natural" or "intuitive".
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829
On 11/26/07, Mike Lively <[EMAIL PROTECTED]> wrote:
> I have come up with three different patches that allow us to work around
> the issue of parent:: being considered an 'explicit class reference' and
> thus disallowing static:: to effectively used.
>
> The patches are against 5.3. I also have pat
Hi,
Am Montag, den 19.11.2007, 10:52 +0100 schrieb Hodicska Gergely:
[...]
> I think the *behavior* of the two code blocks is confusing. And I
> *understand* that it can be stated in the manual that it works in this
> way, but *maybe* not this is the best solution.
Why not something like this
Hi,
On Nov 25, 2007 11:45 PM, Jeff Moore <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> May I suggest renaming get_called_class() to get_static_class() to
> correspond with the use of the static:: keyword for late binding.
It was already kind of discussed, and get_called_class makes more sense IMO.
"st
Hi,
May I suggest renaming get_called_class() to get_static_class() to
correspond with the use of the static:: keyword for late binding.
parent:: and get_parent_class() [no parameters] should also correspond
when used in a static method context.
My preference is that parent:: be late bin
TECTED]
> Sent: Friday, November 23, 2007 12:23 PM
> To: Richard Quadling
> Cc: Marco Kaiser; PHP Developers Mailing List
> Subject: Re: [PHP-DEV] late static binding php6
>
> Hello Richard,
>
> that kind of stuff is the reason we added LSB. There is only one tiny
> thing I
Hello Richard,
what's your point? The output of this script with updated checks and
inheritence still gives expected results:
If you wanted to prevent further inheritance you'd simply mark the class as
final. Say 'final class bar' would prevent existance of 'baz'. I wonder if
we shouldn't make
On 23/11/2007, Marcus Boerger <[EMAIL PROTECTED]> wrote:
> Hello Richard,
>
> that kind of stuff is the reason we added LSB. There is only one tiny
> thing I am not to happy about. You do not at all have to declare static
> $instance. Simply because you never use it. And for that reason you guys
Hello Richard,
that kind of stuff is the reason we added LSB. There is only one tiny
thing I am not to happy about. You do not at all have to declare static
$instance. Simply because you never use it. And for that reason you guys
have your code worng. Use the following snippet for verification:
Markus can explain this a bit more why this isnt possible. :)
-- Marco
> -Original Message-
> From: Richard Quadling [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 23, 2007 10:22 AM
> To: Marco Kaiser
> Cc: PHP Developers Mailing List
> Subject: Re: [PHP-DEV] late s
On 23/11/2007, Richard Quadling <[EMAIL PROTECTED]> wrote:
> On 22/11/2007, Marco Kaiser <[EMAIL PROTECTED]> wrote:
> > Hi again,
> >
> > to explain the main idea a bit more, the code below work and moves the
> > main getInstance function from the class and its possible to abstract
> > this.
> > it
On 22/11/2007, Marco Kaiser <[EMAIL PROTECTED]> wrote:
> Hi again,
>
> to explain the main idea a bit more, the code below work and moves the
> main getInstance function from the class and its possible to abstract
> this.
> it would be cool to get the protected property also into the abstract
> cla
Hi again,
to explain the main idea a bit more, the code below work and moves the
main getInstance function from the class and its possible to abstract
this.
it would be cool to get the protected property also into the abstract
class. Any idea or maybe a solution in the near future?
On Nov 22, 2
Hi List,
just to drop my note here, i asked (i think) 2 years ago for such a
feature to automate my singleton pattern. Not with late static
bindings this is possible.
i think this will also drop much redundant code from some frameworks. :)
So this is one of my examples that helps much.
--
Ma
Hi!
What do you want parent::test() to mean?
Because it wasn't. parent::test() means A::test(). 'parent::' means
'parent class of the class where this statement is' in PHP. For B, it's A.
When you use parent in your code you generally want to add some plus
functionality to the parent class. Bu
Stanislav Malyshev wrote:
>>parent::test();
>
> What do you want parent::test() to mean?
>
>> This will echo 'A'. So like I said you have no way here of telling that
>> B:: was used.
>
> Because it wasn't. parent::test() means A::test(). 'parent::' means
> 'parent class of the class where t
parent::test();
What do you want parent::test() to mean?
This will echo 'A'. So like I said you have no way here of telling that
B:: was used.
Because it wasn't. parent::test() means A::test(). 'parent::' means
'parent class of the class where this statement is' in PHP. For B, it's A
Stanislav Malyshev wrote:
in that situation A::find(); would not be able to know it was being
called by B::find() because parent:: is considered an explicit class
name reference.
>>> It will be, just not by means of parent::.
>> I am missing somethingthen by what means?
>
> By me
Lukas Kahwe Smith wrote:
>
> actually i do not think this is obviously more intuitive than what we
> currently have. also that would introduce BC issues. so i think adding
> some new magic constants (if they are not yet added) would probably
> solve the situation more or less, plus you have self:
Stanislav Malyshev wrote:
>> in that situation A::find(); would not be able to know it was being
>> called by B::find() because parent:: is considered an explicit class
>> name reference.
>
> It will be, just not by means of parent::.
I am missing somethingthen by what means?
--
PHP Interna
Lukas Kahwe Smith wrote:
>
> On 19.11.2007, at 14:24, Alexey Zakhlestin wrote:
>
>> On 11/19/07, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
>>>
>>> On 19.11.2007, at 14:05, Alexey Zakhlestin wrote:
>>>
On 11/19/07, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
> I think the point of
also that would introduce BC issues.
Can you show a use case for BC?
Current implementation:
The __CLASS__ and the get_class() is the same like in the current PHP
version, and the get_called_class() is not yet introduced. Or do I
overlook something?
Best Regards,
Felhő
--
PHP Internals
As I and several others proposed earlier the best option would be:
parent::method() thinks it is the same class as a caller
ClassName::method() thinks it is ClassName
Yes, this would be the logical behavior for me too.
Best Regards,
Felhő
--
PHP Internals - PHP Runtime Development Mailing List
in that situation A::find(); would not be able to know it was being
called by B::find() because parent:: is considered an explicit class
name reference.
It will be, just not by means of parent::.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-882
class A {
static function find($id) {
// lets try and find a 'something'
}
}
class B extends A {}
// I'd like a 'B' please bob.
$b = B::find( 1 );
are you saying that A::find() can tell that it was called as B::find() ?
Yes, this is exactly what LSB does.
--
Jochem Maas wrote:
> Stanislav Malyshev wrote:
>
>>> Rest assured that this is not the bad kind of 'more complex' I believe
>>>
>> I'm afraid I must disagree. The feature that was missing was to know the
>> true calling class name. That was implemented. You can build from it,
>> there's n
I think the point of Stas reply was to use self:: instead of parent::.
Hmm, it doesn't make sense to me. (If I am not mistaken calling self
caused segfault.)
Best Regards,
Felhő
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 19.11.2007, at 14:24, Alexey Zakhlestin wrote:
On 11/19/07, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
On 19.11.2007, at 14:05, Alexey Zakhlestin wrote:
On 11/19/07, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
I think the point of Stas reply was to use self:: instead of
parent::.
On 11/19/07, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
>
> On 19.11.2007, at 14:05, Alexey Zakhlestin wrote:
>
> > On 11/19/07, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
> >
> >> I think the point of Stas reply was to use self:: instead of
> >> parent::.
> >
> > how would self help? that woul
On 19.11.2007, at 14:05, Alexey Zakhlestin wrote:
On 11/19/07, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
I think the point of Stas reply was to use self:: instead of
parent::.
how would self help? that would mean calling this exact method, not
the method of parent-class
that way you c
On 11/19/07, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
> I think the point of Stas reply was to use self:: instead of parent::.
how would self help? that would mean calling this exact method, not
the method of parent-class
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
--
PHP Internals
On 18.11.2007, at 12:27, Gergely Hodicska wrote:
Hi!
I read this thread, and I would like to ask if is there any
decision about the behavior of inheritance?
I wrote on my blog about late static binding (http://blog.felho.hu/
what-is-new-in-php-53-part-2-late-static-binding.html), and I c
Stanislav Malyshev wrote:
>> Rest assured that this is not the bad kind of 'more complex' I believe
>
> I'm afraid I must disagree. The feature that was missing was to know the
> true calling class name. That was implemented. You can build from it,
> there's no need to add further complication to
What's confusing in reading the manual about what self:: and parent::
mean? Unless by "confusing" you don't mean what all other people mean
but "it works certain way, and I know it well, but since I want it to
work other way I'd pretend I don't understand". That would be really
confusing.
You c
Rest assured that this is not the bad kind of 'more complex' I believe
I'm afraid I must disagree. The feature that was missing was to know the
true calling class name. That was implemented. You can build from it,
there's no need to add further complication to the language. You can
easily fin
PHP there will be a natural need for this functionality, and a lot of
user will be confused with the result.
What's confusing in reading the manual about what self:: and parent::
mean? Unless by "confusing" you don't mean what all other people mean
but "it works certain way, and I know it well
Actually, I don't think it was. If you want objects, why not use the
real thing?
Just consider that ZF's initial concept was for ActiveRecord a code
which needs LSB.
"more complex" is not always better.
Did you find my code example "too" complex? I think if LSB is added to
PHP there will be a
Stanislav Malyshev wrote:
>> I realize that instance calls are a completely different ball game than
>> static calls but LSB was supposed to give us the same flexibility.
>
> Actually, I don't think it was. If you want objects, why not use the
> real thing? LSB was created to solve just one parti
I realize that instance calls are a completely different ball game than
static calls but LSB was supposed to give us the same flexibility.
Actually, I don't think it was. If you want objects, why not use the
real thing? LSB was created to solve just one particular problem -
inability to disti
Johannes Schlüter wrote:
> Hi,
>
> and for me the current behavior feels right: The call to
> parrent::findByPk() is an independent call from the call before and
> calls an explicit class (the parent one)
>
>
This makes no sense to me. It makes it COMPLETELY impossible to do any
form of slightly
Hi!
this very subject was already discussed in a thread months ago.
I have read the thread about it, but I didn't find a conclusion (maybe I
missed it).
Basically,
it's a matter of choice whether fully established calls should break the
resolution or not.
I think the code I sent is an absol
Hi,
and for me the current behavior feels right: The call to
parrent::findByPk() is an independent call from the call before and
calls an explicit class (the parent one)
johannes
On Sun, 2007-11-18 at 14:21 +0100, "Etienne Kneuss" wrote:
> Hello,
>
> this very subject was already discussed in a
Hello,
this very subject was already discussed in a thread months ago. Basically,
it's a matter of choice whether fully established calls should break the
resolution or not. Both ways have drawbacks. Implementing both would require
yet another keyword and complications.
On Nov 18, 2007 12:27 PM,
Hi!
I read this thread, and I would like to ask if is there any decision
about the behavior of inheritance?
I wrote on my blog about late static binding
(http://blog.felho.hu/what-is-new-in-php-53-part-2-late-static-binding.html),
and I came up with the following example:
In think it w
Lukas Kahwe Smith wrote:
Sebastian Deutsch wrote:
hello,
is there a patch for the proposal out there? is anyone working on
that problem?
There might be a patch flying around ...
Last I heard from Marcus was that it seems impossible to find a solution
for this without accepting a slow down/me
Sebastian Deutsch wrote:
hello,
is there a patch for the proposal out there? is anyone working on that
problem?
There might be a patch flying around ...
Last I heard from Marcus was that it seems impossible to find a solution
for this without accepting a slow down/memory footprint increase fo
53 matches
Mail list logo
