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 discussion:
Perhaps saying "language" was misleading. We are talking about an
object model, regardless of where that fits in the story of the
language.
And this seems different than grammar (syntax) or even semantics. This
would be denying a feature because we thought it would not be used
properly. The discussion at this point is kinda "yay" or "nay", style
& syntax would be later.
Positives:
A more complete object model (at least quantitatively)
Perhaps some new patterns will emerge that, despite being out of the
norm for current best-practices, help people solve problems with PHP
Another line item on a feature list (someone's selling this stuff,
right ? ;)
Negatives:
Someone has to code it
Some people will write fragile code with it.
Looking forward to more thoughts...
Chris Trahey
Web Applications Developer
Database Administrator
College Station I.S.D.
On Sep 19, 2009, at 12:57 PM, Larry Garfield <la...@garfieldtech.com>
wrote:
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 think would be
static.
>
> But it seems like there is a bigger decision to make than this
> feature. Should the language itself impose coding guidlines on
> developers?
All languages impose guidelines on developers. Grammar does that. :-)
> This reference seems notably basic in an OOP language. The
Paradigm is
> based largely on two concepts: objects and the messages between
them.
> For each message, the recipient is known (intrinsically) but the
> sender is not. It seems like a basic property of a method call
that is
> not exposed in a semantically appropriate way.
"basic in any OOP language" is a useless statement, as "OOP
language" is such
an ill-defined concept anyway. :-) PHP is a hybrid language. Is
Java an OOP
language? Is Javascript? Is Python? Is Ruby? They all have
extremely
different ideas of what "OOP" means, none of which is inherently
wrong.
From a PHP perspective, as Pawel notes PHP doesn't use full on
message passing
as its communication mechanism. A function call is not a message
pass.
Having implicit knowledge about your context (ie, the caller) makes
encapsulation, testing, and divide-and-conquer substantially more
difficult if
not impossible.
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...) If you need a
variable from
higher in the stack, that's what function parameters are for.
--
Larry Garfield
la...@garfieldtech.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
