>> - 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
Etienne Kneuss wrote:
It's always dangerous to introduce a new keyword, as it can/will break
BC (i.e what if somebody has defined a function derived(), the parser
would choke on that).
I'm personally fine with static, even if it may eventually introduce
some confusion.
Regards
Perhap
Bart de Boer wrote:
I thought late static binding had something to do with accessing static
_variables_ in child classes. You're currently solving that problem by
defining a static function getTableName() in the child class. But I think
that isn't very efficient when you're dealing with complex o
> Bart de Boer wrote:
>> Ken Stanley wrote:
>>
>
> ...
>> That's not right. Accessing the child class would only be possible from
>> within an instantiated object. Unlike parent::, you will never be able
>> to use static:: in a purely static context. Imagine there are multiple
>> child classes whi
Jochem Maas wrote:
Bart de Boer wrote:
Ken Stanley wrote:
...
That's not right. Accessing the child class would only be possible from
within an instantiated object. Unlike parent::, you will never be able
to use static:: in a purely static context. Imagine there are multiple
chil
Bart de Boer wrote:
> Ken Stanley wrote:
>
...
> That's not right. Accessing the child class would only be possible from
> within an instantiated object. Unlike parent::, you will never be able
> to use static:: in a purely static context. Imagine there are multiple
> child classes which all inh
That's right. And that's exactly why it's such a bad idea to call it
static::. It's the scope resolution operator which already makes them
static, not their name. (I'm sorry for catching you on your words ;) )
I agree that it is not the best name, just not as bad as some of the others.
:)
Tha
Ken Stanley wrote:
As for parent/self:: and even static::, what makes
them static is the scope resolution operator (::), not their name.
Their name just implies the context in which they are to be used.
That's right. And that's exactly why it's such a bad idea to call it
static::. It's the
First of all, thank you to everybody who has responded to my (silly)
questions; you have made this subject a lot more understandable. :)
static:: seems weird because it implies otherkeyword:: is not static.
I think the point that was made from the other posters was that child:: was
way too conf
Richard Lynch wrote:
On Wed, May 30, 2007 9:54 am, Jochem Maas wrote:
Richard Lynch wrote:
Maybe I'm just confused (well, I'm always confused...) but if a
Class
has multiple children, how the heck would PHP know which child:: to
call?...
the use of the name 'child' is very confusing, I would p
On Wed, May 30, 2007 9:54 am, Jochem Maas wrote:
> Richard Lynch wrote:
>> Maybe I'm just confused (well, I'm always confused...) but if a
>> Class
>> has multiple children, how the heck would PHP know which child:: to
>> call?...
>
> the use of the name 'child' is very confusing, I would prefer 's
static function getTableName() { return 'PRODS'; }
What a great idea! You can just do:
$tableName = $this->getTableName();
...from within the base class. No need for static:: or super:: keywords
anymore... It may be not as elegant as having a special keyword for
it... But, for now, this appr
static function getTableName() { return 'PRODS'; }
What a great idea! You can just do:
$tableName = $this->getTableName();
...from within the base class. No need for static:: or super:: keywords
anymore... It may be not as elegant as having a special keyword for
it... (Or if this is the inte
Richard Lynch wrote:
> Maybe I'm just confused (well, I'm always confused...) but if a Class
> has multiple children, how the heck would PHP know which child:: to
> call?...
the use of the name 'child' is very confusing, I would prefer 'super' or
'static' ...
regardless the concept is actually qu
Maybe I'm just confused (well, I'm always confused...) but if a Class
has multiple children, how the heck would PHP know which child:: to
call?...
On Sat, May 26, 2007 5:48 pm, Ken Stanley wrote:
> Hi all!
>
> I've been researching the current status of late static binding, and I
> came
> across t
parties involved could help clear up for me. Basically, I am wondering if
anybody has tossed around the idea of having a scope of child::, just like
Well, this exactly name makes little sense, since class has only one
self and one parent, but can have many children, so child:: does not
uniquel
This subject has some correlation with my previous suggestion. Except I
totally forgot about the "late static binding" discussion.
I'd like to give another real life example. This is an oversimplified
version of what I'd currently like to do (without a bunch of workarounds):
'Address');
On 5/26/07, Mike Lively <[EMAIL PROTECTED]> wrote:
It appears that all you are suggesting that is different from what has
been discussed previously is purely syntactical. In that regard I would
have to say that while neither this:: or static:: are jaw-droppers,
child:: seems somewhar counter-int
Ken Stanley wrote:
I've been researching the current status of late static binding, and I
came
across this mailing list with a few topics on this subject. After
doing the
reading, I had a couple of questions that maybe one of the experienced
parties involved could help clear up for me. Basicall
Hello Lukas,
iirc everyone interested agreed to that syntax. However so far we only saw
one implementation and that comes with a slowdown of every function call.
The problem is that the only known solution so far is to puch the context
(the initial calling scope/class) along with $this etc on th
That one seems fine to me.
-Andrei
On Apr 26, 2007, at 8:00 AM, Lukas Kahwe Smith wrote:
Hello,
does anyone have a patch for PHP6 to add late static binding?
have we agreed on the syntax?
IIRC, static:: as the favorite ..?
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing L
73 matches
Mail list logo
