And really, you're not talking about a caller object but about accessing
variables in scope from the next-highest step in the call stack, which may
or
may not be an object. (Hybrid language, remember. It could be a lambda
function as of PHP 5.3, or global scope, or...) ...
function foo()
{
There are patterns that would be violated by using a caller reference,
but none that would be broken by having one. Each development team can
decide what features to use.
With regard to "friend classes", I'll start a new thread since it is a
fundamentally different subject.
For this discu
On Friday 18 September 2009 11:36:08 pm Chris Trahey wrote:
> Hey all, thanks for the discussion.
>
> First, in terms of implimentation, I've gone back and forth between a
> few ways to expose it, but it struck me tonight that the most similar
> keyword in use currently is $this. Next to that I thi
W liście Chris Trahey z dnia sobota 19 września 2009:
> I guess what I'm really getting at is another access modifier:
> private, protected, public...
> And now adding something like trusted.
> trusted function myMethod() callable trustedInterface {}
>
> In a case like this, caller would always be
]
> > Sent: 19 September 2009 11:33
> > To: troels knak-nielsen; Ford, Mike
> > Cc: internals@lists.php.net
> > Subject: Re: [PHP-DEV] reference caller object
> >
> > >I, for one, am quite happy that it's fairly complicated and
> > convoluted
> &g
lege Station I.S.D.
On Sep 19, 2009, at 9:04 AM, "Jared Williams" > wrote:
> -Original Message-
> From: Stan Vassilev [mailto:sv_for...@fmethod.com]
> Sent: 19 September 2009 11:33
> To: troels knak-nielsen; Ford, Mike
> Cc: internals@lists.php.net
> Subje
> -Original Message-
> From: Stan Vassilev [mailto:sv_for...@fmethod.com]
> Sent: 19 September 2009 11:33
> To: troels knak-nielsen; Ford, Mike
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] reference caller object
>
> >I, for one, am quite happy t
I, for one, am quite happy that it's fairly complicated and convoluted
to get the caller of a method, since it could lead to some seriously
incomprehensible code in the hands of someone who don't know what they
are doing. Requiring the user to use the backtrace is a clear warning
sign, and I think
Hey all, thanks for the discussion.
First, in terms of implimentation, I've gone back and forth between a
few ways to expose it, but it struck me tonight that the most similar
keyword in use currently is $this. Next to that I think would be static.
But it seems like there is a bigger decisi
On Friday 18 September 2009 9:12:55 am troels knak-nielsen wrote:
> On Fri, Sep 18, 2009 at 1:05 PM, Ford, Mike wrote:
> > Well, that sounds like a pretty good definition of a "magic" constant, so
> > maybe __CALLER__ might be appropriate as well?
>
> It's not a constant, is it now?
>
> __FILE__,
On Fri, Sep 18, 2009 at 1:05 PM, Ford, Mike wrote:
> Well, that sounds like a pretty good definition of a "magic" constant, so
> maybe __CALLER__ might be appropriate as well?
It's not a constant, is it now?
__FILE__, __LINE__, __CLASS__ etc. can be resolved at compile-time.
The caller will onl
2009/9/18 Ford, Mike :
>> -Original Message-
>> From: Richard Quadling [mailto:rquadl...@googlemail.com]
>> Sent: 18 September 2009 10:43
>
>>
>> Considering we have func_get_args(), maybe func_get_caller() would
>> be
>> a nice fit.
>>
>> I don't like the idea of a constant (CALLER) which
> -Original Message-
> From: Richard Quadling [mailto:rquadl...@googlemail.com]
> Sent: 18 September 2009 10:43
>
> Considering we have func_get_args(), maybe func_get_caller() would
> be
> a nice fit.
>
> I don't like the idea of a constant (CALLER) which changes value as
> you move aro
2009/9/17 Sebastian Bergmann :
> Chris Trahey schrieb:
>> using it is current-implimentation specific (i.e. developer needs to
>> know the format of the array returned)
>
> And adding another language feature is not something the developer needs
> to know?
>
> --
> Sebastian Bergmann
On Thu, Sep 17, 2009 at 10:05 AM, Chris Trahey wrote:
> For each use case, there are going to be ways to acheive results without
> new functionality. I think this feature doesn't make the impossible
> possible, it gives developers a consistent interface to access an object
> that is potentially ve
For each use case, there are going to be ways to acheive results without
new functionality. I think this feature doesn't make the impossible
possible, it gives developers a consistent interface to access an object
that is potentially very relevant, and perhaps not desired to be necessary
in the met
On Wed, Sep 16, 2009 at 1:59 PM, Chris Trahey wrote:
> (Please direct me elsewhere if necessary, this is a feature request)
>
> It would be handy to allow a method to behave differently based on who is
> calling it.
> the function I am looking for would essentially do this:
> .. snip ..
Type hint
Sebastian Bergmann wrote:
Chris Trahey schrieb:
using it is current-implimentation specific (i.e. developer needs to
know the format of the array returned)
And adding another language feature is not something the developer needs
to know?
I think the concern is the overhead of capturing the
> And adding another language feature is not something the developer needs
> to know?
Once implimented, it would be obvious that a constant like "caller" always
means caller.
It is not obvious that the caller object is located in the "object" key of
the second element of the array returned by debu
Chris Trahey schrieb:
> using it is current-implimentation specific (i.e. developer needs to
> know the format of the array returned)
And adding another language feature is not something the developer needs
to know?
--
Sebastian BergmannCo-Founder and Principal Consultant
h
>
>Isn't this exactly what the backtrace is for?
That's fair... but there are ate least two things undesireable about using
the backtrace:
1. Performance - we can get the caller less work
2. using it is current-implimentation specific (i.e. developer needs to
know the format of the array returned
2009/9/17 Chris Trahey :
> It seems worthwhile in a service-provider situation where you do not wish to
> enforce use of $this in service consumers.
> The service provider can impliment caller without modifying existing code.
>
> Semantically, it should be considered redundant to pass $this in a me
It seems worthwhile in a service-provider situation where you do not
wish to enforce use of $this in service consumers.
The service provider can impliment caller without modifying existing
code.
Semantically, it should be considered redundant to pass $this in a
method call. There should be
If the object needs to behave differently based on who called it, there's
already a very easy way to do that:
class A {
function foo() {
$b = new B();
$b->bar($this);
}
}
class B {
function bar($caller) {
if ($caller instance of A) {
// ...
}
}
}
That's also there
24 matches
Mail list logo
