The reason for creating circular references, usually due to the need to
bind objects.
But this relationship can often be obtained from the context of the call.
It will be very convenient to have a keyword that will return reference to
an object, which caused this object.
Sorry for my English, I'm not a native speaker.
A simple example below shows the behavior that we need.
<?php
class A
{
public function __construct() {
$this->object = new C;
}
}
class B
{
public function __construct() {
$this->object = new C;
}
}
class C
{
public function getCaller() {
return caller::class;
}
}
$a = new A;
$b = new B;
$c = new C;
$a->object->getCaller(); // return A
$b->object->getCaller(); // return B
$c->getCaller(); // Fatal Error - undefined caller context
?>
Create a new keyword can cause problems with backward compatibility...
Perhaps you can solve a problem to using an existing keyword?
Thank you for any feedback.
Usually it is solved sending the $this instance to class C constructor and
C object storing it in some attribute, solving the problem. I don't think a
new keyword would help.
Juan Basso
The reason for creating circular references, usually due to the need to
bind objects.But this relationship can often be obtained from the context of the call.
It will be very convenient to have a keyword that will return reference to
an object, which caused this object.Sorry for my English, I'm not a native speaker.
A simple example below shows the behavior that we need.<?php
class A
{
public function __construct() {
$this->object = new C;
}
}class B
{
public function __construct() {
$this->object = new C;
}
}class C
{
public function getCaller() {
return caller::class;
}
}$a = new A;
$b = new B;
$c = new C;$a->object->getCaller(); // return A
$b->object->getCaller(); // return B$c->getCaller(); // Fatal Error - undefined caller context
?>
Create a new keyword can cause problems with backward compatibility...
Perhaps you can solve a problem to using an existing keyword?Thank you for any feedback.
Yes.
But this creates a static link that will not be constantly changing context
to the calls, the keyword will give a dynamic abstract communication.
2015-01-30 5:50 GMT+02:00 Juan Basso jrbasso@gmail.com:
Usually it is solved sending the $this instance to class C constructor and
C object storing it in some attribute, solving the problem. I don't think a
new keyword would help.Juan Basso
The reason for creating circular references, usually due to the need to
bind objects.But this relationship can often be obtained from the context of the call.
It will be very convenient to have a keyword that will return reference to
an object, which caused this object.Sorry for my English, I'm not a native speaker.
A simple example below shows the behavior that we need.<?php
class A
{
public function __construct() {
$this->object = new C;
}
}class B
{
public function __construct() {
$this->object = new C;
}
}class C
{
public function getCaller() {
return caller::class;
}
}$a = new A;
$b = new B;
$c = new C;$a->object->getCaller(); // return A
$b->object->getCaller(); // return B$c->getCaller(); // Fatal Error - undefined caller context
?>
Create a new keyword can cause problems with backward compatibility...
Perhaps you can solve a problem to using an existing keyword?Thank you for any feedback.
I will clarify the benefits of the keyword.
Single instance of the class can reused in different contexts calls.
<?php
class A
{
public $object;
}
class B
{
public $object;
}
class C
{
public function getCaller() {
return caller::class;
}
}
$a = new A;
$b = new B;
$c = new C;
$a->object = $c;
$b->object = $c;
$a->object->getCaller(); // return A
$b->object->getCaller(); // return B
$c->getCaller(); // Fatal Error - undefined caller context
?>
2015-01-30 5:50 GMT+02:00 Juan Basso jrbasso@gmail.com:
Usually it is solved sending the $this instance to class C constructor and
C object storing it in some attribute, solving the problem. I don't think a
new keyword would help.Juan Basso
The reason for creating circular references, usually due to the need to
bind objects.But this relationship can often be obtained from the context of the call.
It will be very convenient to have a keyword that will return reference to
an object, which caused this object.Sorry for my English, I'm not a native speaker.
A simple example below shows the behavior that we need.<?php
class A
{
public function __construct() {
$this->object = new C;
}
}class B
{
public function __construct() {
$this->object = new C;
}
}class C
{
public function getCaller() {
return caller::class;
}
}$a = new A;
$b = new B;
$c = new C;$a->object->getCaller(); // return A
$b->object->getCaller(); // return B$c->getCaller(); // Fatal Error - undefined caller context
?>
Create a new keyword can cause problems with backward compatibility...
Perhaps you can solve a problem to using an existing keyword?Thank you for any feedback.
I will clarify the benefits of the keyword.
Single instance of the class can reused in different contexts calls.<?php
class A
{
public $object;
}class B
{
public $object;
}class C
{
public function getCaller() {
return caller::class;
}
}$a = new A;
$b = new B;
$c = new C;$a->object = $c;
$b->object = $c;$a->object->getCaller(); // return A
$b->object->getCaller(); // return B$c->getCaller(); // Fatal Error - undefined caller context
?>
This seems like an extremely bad idea to do in the first place. Code in
class C should function the same whether it was called from $a or $b.
If it should vary, that should be made explicit in the object's
construction and you have DIFFERENT instances of it.
Having an object that behaves differently depending on an implicit
relationship with where it happened to be called from is full of all
kinds of impossible to debug magic. I don't even know how you'd unit
test it. I can think of no use case where this wouldn't cause only
problems.
--Larry Garfield
De : Larry Garfield [mailto:larry@garfieldtech.com]
Having an object that behaves differently depending on an implicit
relationship with where it happened to be called from is full of all
kinds of impossible to debug magic. I don't even know how you'd unit
test it. I can think of no use case where this wouldn't cause only
problems.
The only use case I can think of is to enforce access restriction (an alternative to 'friend' classes), faster than using debug_backtrace(). But I would prefer really implementing friend classes/namespaces.
@S.A.N: you can already determine the caller using debug_backtrace(). Slow and inconvenient, but it works.
Regards
François
The reason for creating circular references, usually due to the need to
bind objects.But this relationship can often be obtained from the context of the call.
It will be very convenient to have a keyword that will return reference to
an object, which caused this object.Sorry for my English, I'm not a native speaker.
A simple example below shows the behavior that we need.<?php
class A
{
public function __construct() {
$this->object = new C;
}
}class B
{
public function __construct() {
$this->object = new C;
}
}class C
{
public function getCaller() {
return caller::class;
}
}$a = new A;
$b = new B;
$c = new C;$a->object->getCaller(); // return A
$b->object->getCaller(); // return B$c->getCaller(); // Fatal Error - undefined caller context
?>
Create a new keyword can cause problems with backward compatibility...
Perhaps you can solve a problem to using an existing keyword?Thank you for any feedback.
see the previous discussion on this topic:
http://grokbase.com/t/php/php-internals/099g86x7k6/reference-caller-object
I think having it as a magic constant would be better, but I still don't
like the idea (it is already possible, there aren't really a good usecase
for it, the example you mentioned is a prime example how would it be
misused to cause debugging nightmares, etc.).
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
No, I'm not describing this behavior, but I chose the wrong name
keyword, this is not perceived correctly.
My source code examples, it is clear that no returns previous object
from the call stack, me need return references to the holder object.
It's more like the dynamic of "this" in JavaScript.
Dynamic "this", sometimes very convenient for the event model, so I
proposed to implement this feature in PHP.
In PHP, there traits, extends, but it's all static bind, in runtime
can not be added or redefined.
I'll show a simple JS example, in which needed behavior dynamic this.
<script language="JavaScript"> function A(){} function B(){} function getHolder() { console.log(this.constructor.name) } var oA = new A var oB = new B oA.getHolder = getHolder oB.getHolder = getHolder oA.getHolder() // return A oB.getHolder() // return B getHolder() // return Window </script>Perhaps we should use the keyword "this" instead of "caller"? :)
Then the code in PHP will look like this:
<?php
class A
{
public $object;
}
class B
{
public $object;
}
class C
{
public function getHolder() {
return this::class;
}
}
$a = new A;
$b = new B;
$c = new C;
$a->object = $c;
$b->object = $c;
$a->object->getHolder(); // return A
$b->object->getHolder(); // return B
$c->getHolder(); // Fatal Error - undefined context
?>
What do you think?
Thank.
2015-01-30 18:43 GMT+02:00 Ferenc Kovacs tyra3l@gmail.com:
The reason for creating circular references, usually due to the need to
bind objects.But this relationship can often be obtained from the context of the call.
It will be very convenient to have a keyword that will return reference to
an object, which caused this object.Sorry for my English, I'm not a native speaker.
A simple example below shows the behavior that we need.<?php
class A
{
public function __construct() {
$this->object = new C;
}
}class B
{
public function __construct() {
$this->object = new C;
}
}class C
{
public function getCaller() {
return caller::class;
}
}$a = new A;
$b = new B;
$c = new C;$a->object->getCaller(); // return A
$b->object->getCaller(); // return B$c->getCaller(); // Fatal Error - undefined caller context
?>
Create a new keyword can cause problems with backward compatibility...
Perhaps you can solve a problem to using an existing keyword?Thank you for any feedback.
see the previous discussion on this topic:
http://grokbase.com/t/php/php-internals/099g86x7k6/reference-caller-object
I think having it as a magic constant would be better, but I still don't
like the idea (it is already possible, there aren't really a good usecase
for it, the example you mentioned is a prime example how would it be misused
to cause debugging nightmares, etc.).--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
No, I'm not describing this behavior, but I chose the wrong name
keyword, this is not perceived correctly.My source code examples, it is clear that no returns previous object
from the call stack, me need return references to the holder object.It's more like the dynamic of "this" in JavaScript.
Dynamic "this", sometimes very convenient for the event model, so I
proposed to implement this feature in PHP.
In PHP, there traits, extends, but it's all static bind, in runtime
can not be added or redefined.I'll show a simple JS example, in which needed behavior dynamic this.
<script language="JavaScript"> function A(){} function B(){} function getHolder() { console.log(this.constructor.name) } var oA = new A var oB = new B oA.getHolder = getHolder oB.getHolder = getHolder oA.getHolder() // return A oB.getHolder() // return B getHolder() // return Window </script>Perhaps we should use the keyword "this" instead of "caller"? :)
Then the code in PHP will look like this:<?php
class A
{
public $object;
}class B
{
public $object;
}class C
{
public function getHolder() {
return this::class;
}
}$a = new A;
$b = new B;
$c = new C;$a->object = $c;
$b->object = $c;$a->object->getHolder(); // return A
$b->object->getHolder(); // return B$c->getHolder(); // Fatal Error - undefined context
?>
What do you think?
Thank.
Hi,
I think I get what you're trying to do, but I'm not sure the PHP code
you suggest is quite equivalent to the JavaScript. In JavaScript, you
are setting a single function (getHolder) as a direct member of your
objects:
oA.getHolder = getHolder
oB.getHolder = getHolder
But in the PHP, you are attaching a whole object to a property:
$a->object = $c;
$b->object = $c;
When you call getHolder in PHP, the "holder" of that method is always
$c, because you could split the code up like this:
$something = $a->object;
$something->getHolder();
In general, a method can't be copied from one object to another in PHP
like it can in JS, so the concept of dynamic this doesn't normally make
any sense. However, you can do something similar by "binding a closure";
you just need to invoke it a bit differently because properties and
methods are not interchangeable like they are in JS:
<?php
class A {
public $getHolder;
}
class B {
public $getHolder;
}
$getHolderDefinition = function() { return get_class($this); };
$a = new A;
$b = new B;
$a->getHolder = $getHolderDefinition->bindTo($a);
$b->getHolder = $getHolderDefinition->bindTo($b);
echo $a->getHolder->__invoke(), "\n";
echo $b->getHolder->__invoke(), "\n";
// Or
$method = $a->getHolder;
echo $method(), "\n";
$method = $b->getHolder;
echo $method(), "\n";
For many callback / event scenarios, you don't actually need to treat
the closure as a property / method of the object at all, you just want
the $this reference, so the ->bindTo() part is all you need, maybe more
like this:
class SomeEventTarget {
function triggerEvent($someCallback) {
$boundCallback = $someCallback->bindTo($this);
$boundCallback($some, $arguments);
}
}
(PS: The house rules for this list asks for replies to be below quoted
text, not above.)
Regards,
--
Rowan Collins
[IMSoP]
2015-02-01 0:10 GMT+02:00 Rowan Collins rowan.collins@gmail.com:
No, I'm not describing this behavior, but I chose the wrong name
keyword, this is not perceived correctly.My source code examples, it is clear that no returns previous object
from the call stack, me need return references to the holder object.It's more like the dynamic of "this" in JavaScript.
Dynamic "this", sometimes very convenient for the event model, so I
proposed to implement this feature in PHP.
In PHP, there traits, extends, but it's all static bind, in runtime
can not be added or redefined.I'll show a simple JS example, in which needed behavior dynamic this.
<script language="JavaScript"> function A(){} function B(){} function getHolder() { console.log(this.constructor.name) } var oA = new A var oB = new B oA.getHolder = getHolder oB.getHolder = getHolder oA.getHolder() // return A oB.getHolder() // return B getHolder() // return Window </script>Perhaps we should use the keyword "this" instead of "caller"? :)
Then the code in PHP will look like this:<?php
class A
{
public $object;
}class B
{
public $object;
}class C
{
public function getHolder() {
return this::class;
}
}$a = new A;
$b = new B;
$c = new C;$a->object = $c;
$b->object = $c;$a->object->getHolder(); // return A
$b->object->getHolder(); // return B$c->getHolder(); // Fatal Error - undefined context
?>
What do you think?
Thank.Hi,
I think I get what you're trying to do, but I'm not sure the PHP code you
suggest is quite equivalent to the JavaScript. In JavaScript, you are
setting a single function (getHolder) as a direct member of your objects:oA.getHolder = getHolder
oB.getHolder = getHolderBut in the PHP, you are attaching a whole object to a property:
$a->object = $c;
$b->object = $c;When you call getHolder in PHP, the "holder" of that method is always $c,
because you could split the code up like this:$something = $a->object;
$something->getHolder();In general, a method can't be copied from one object to another in PHP like
it can in JS, so the concept of dynamic this doesn't normally make any
sense. However, you can do something similar by "binding a closure"; you
just need to invoke it a bit differently because properties and methods are
not interchangeable like they are in JS:<?php
class A {
public $getHolder;
}
class B {
public $getHolder;
}$getHolderDefinition = function() { return get_class($this); };
$a = new A;
$b = new B;$a->getHolder = $getHolderDefinition->bindTo($a);
$b->getHolder = $getHolderDefinition->bindTo($b);echo $a->getHolder->__invoke(), "\n";
echo $b->getHolder->__invoke(), "\n";// Or
$method = $a->getHolder;
echo $method(), "\n";$method = $b->getHolder;
echo $method(), "\n";For many callback / event scenarios, you don't actually need to treat the
closure as a property / method of the object at all, you just want the $this
reference, so the ->bindTo() part is all you need, maybe more like this:class SomeEventTarget {
function triggerEvent($someCallback) {
$boundCallback = $someCallback->bindTo($this);
$boundCallback($some, $arguments);
}
}(PS: The house rules for this list asks for replies to be below quoted text,
not above.)Regards,
--
Rowan Collins
[IMSoP]--
Yes, you're right, in PHP you can solve this problem by other methods, I know...
But the problem is that PHP is no nice and convenient for solving this problem.
So I suggested to add new keyword, not to do manually bindTo($this)
for each methods.
Thank.
Yes, you're right, in PHP you can solve this problem by other methods, I know...
But the problem is that PHP is no nice and convenient for solving this problem.
So I suggested to add new keyword, not to do manually bindTo($this)
for each methods.
Have a closer look at my example; the point is that without bindTo,
there is no way of doing the first part of your JS example, i.e.
attaching the same function/method to two objects - there is no
equivalent of this line:
oA.getHolder = getHolder
In your PHP example, you introduce an extra object, $c, which doesn't
exist in your JS example; if it did, it would look like this:
var oA = new A
var oB = new B
var oC = new C
oA.myC = oC;
oB.myC = oC;
oC.getHolder = getHolder
oA.myC.getHolder() // returns C
oB.myC.getHolder() // returns C
Hopefully you can see that that makes all the difference - myHolder is
now always called from the same object, the one created with "new C".
The reason this doesn't translate well is that In JS, a method is just a
property which happens to be a closure, so "this" is necessarily dynamic
- there is no class definition to define the relationship between the
method and the object (ES6 introduces all sorts of variations and
caveats to this, all of which can be emulated in older versions). In
PHP, a method is fundamentally different from functions, closures, and
properties, despite similarities in syntax, so none of the same
behaviours would make sense.
Regards,
--
Rowan Collins
[IMSoP]
2015-02-01 21:41 GMT+02:00 Rowan Collins rowan.collins@gmail.com:
Yes, you're right, in PHP you can solve this problem by other methods, i
know...But the problem is that PHP is no nice and convenient for solving this
problem.
So i suggested to add new keyword, not to do manually bindTo($this)
for each methods.Have a closer look at my example; the point is that without bindTo, there is
no way of doing the first part of your JS example, i.e. attaching the same
function/method to two objects - there is no equivalent of this line:oA.getHolder = getHolder
In your PHP example, you introduce an extra object, $c, which doesn't exist
in your JS example; if it did, it would look like this:var oA = new A
var oB = new B
var oC = new CoA.myC = oC;
oB.myC = oC;
oC.getHolder = getHolderoA.myC.getHolder() // returns C
oB.myC.getHolder() // returns CHopefully you can see that that makes all the difference - myHolder is now
always called from the same object, the one created with "new C".The reason this doesn't translate well is that In JS, a method is just a
property which happens to be a closure, so "this" is necessarily dynamic -
there is no class definition to define the relationship between the method
and the object (ES6 introduces all sorts of variations and caveats to this,
all of which can be emulated in older versions). In PHP, a method is
fundamentally different from functions, closures, and properties, despite
similarities in syntax, so none of the same behaviours would make sense.Regards,
--
Rowan Collins
Yes you are right.
In PHP, i added to $holder a sub-object, for two reasons:
-
In PHP, it is impossible
$holder->call = function(){};
$holder->call(); // Error -
I need to have a common state in $this.
That's why i decided to add a subobject: $holder->object->call();
But i understand that this is a bad idea.
i originally thought that it simplifies the implementation of
solutions in PHP, but it is not.
Maybe correct option, native implement in PHP - pattern prototype,
then do not need to create new keywords and questionable behavior.
Let me show you an example JS, i want to do in PHP:
<script language="JavaScript"> var A = {} var B = {} var C = { object: { index: 0 }, method: function () { console.log(this.object.index++) } } A.__proto__ = C B.__proto__ = C A.method() // return 0 B.method() // return 1 C.method() // return 2 </script>In PHP, I would like to have an analog method Object.create
http://www.ecma-international.org/ecma-262/5.1/#sec-15.2.3.5
Perhaps the option to add in PHP, new magic static method:
ClassName::__create($object).
This method will create a new instance of the class and introduce API
from specified object.
It would also be very nice to have a method of changing the prototype
at run time, this could be used method: $a->__proto($other)
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-additional-properties-of-the-object.prototype-object
Then the PHP code looks like this:
<?php
class A{}
class B{}
class C
{
public $object;
public function __construct()
{
$this->object = new stdClass;
$this->object->index = 0;
}
public function method()
{
return $this->object->index++;
}
}
$c = new C;
$a = A::__create($c);
$b = B::__create($c);
$a->method() // return 0
$b->method() // return 1
$c->method() // return 2
?>
If it is technically possible and PHP developers is interesting, then
it is better to create a new topic, to discuss implementation of the
prototype in PHP.
I do not want to break the paradigm of PHP and not impose everywhere
and always use prototypes, I hope that PHP will have a multi-paradigm.
ECMAScript not had classes, but version 6+ implemented class, is nice.
If PHP 7 will be implemented prototypes will be very cool to everyone.
Thank you all.
Hi!
The reason for creating circular references, usually due to the need to
bind objects.But this relationship can often be obtained from the context of the call.
If the API behaves differently depending on who is calling it, or
requires some information from the caller, it should be passed
explicitly - as a parameter/method call/etc. - not hidden. Otherwise it
would lead to nasty surprises when the user of the API assumes caller
does not matter but the implementor assumes it does.
Stas Malyshev
smalyshev@gmail.com
2015-02-01 1:52 GMT+02:00 Stanislav Malyshev smalyshev@gmail.com:
Hi!
The reason for creating circular references, usually due to the need to
bind objects.But this relationship can often be obtained from the context of the call.
If the API behaves differently depending on who is calling it, or
requires some information from the caller, it should be passed
explicitly - as a parameter/method call/etc. - not hidden. Otherwise it
would lead to nasty surprises when the user of the API assumes caller
does not matter but the implementor assumes it does.Stas Malyshev
smalyshev@gmail.com
This is a controversial statement.
If the caller explicitly send the object as an argument, it worsens
loose depending API.
And agreed this code looks weird and not well thought-out:
<?php
$holder->object->call($holder);
?>
Opportunity to shoot yourself in the foot, will always, developers
node.js it know.
I know that this code can be arranged differently, but then you have
to make it more difficult and not nice.
But if have an easy way to get a pointer to the owner, in practice, is
very convenient.
Hi!
If the caller explicitly send the object as an argument, it worsens
loose depending API.And agreed this code looks weird and not well thought-out:
<?php$holder->object->call($holder);
This code explicitly says "object->call() is using $holder". It is clear
and unambiguous. If you did it implicitly - i.e. wrote
$holder->object->call() and that used $holder under the hood in call() -
then you could have modified or even completely destroyed $holder under
the assumption that nobody depends on it, but in fact whatever is in
$holder->object, unknown to you, would depend on it and would break.
Such hidden dependencies are not a good design.
But if have an easy way to get a pointer to the owner, in practice, is
very convenient.
It may be convenient in short run, but I think in the long run creating
hidden dependencies would make code less robust so it is better not to
enable it as a best practice.
Stas Malyshev
smalyshev@gmail.com
2015-02-01 2:23 GMT+02:00 Stanislav Malyshev smalyshev@gmail.com:
Hi!
If the caller explicitly send the object as an argument, it worsens
loose depending API.And agreed this code looks weird and not well thought-out:
<?php$holder->object->call($holder);
This code explicitly says "object->call() is using $holder". It is clear
and unambiguous. If you did it implicitly - i.e. wrote
$holder->object->call() and that used $holder under the hood in call() -
then you could have modified or even completely destroyed $holder under
the assumption that nobody depends on it, but in fact whatever is in
$holder->object, unknown to you, would depend on it and would break.
Such hidden dependencies are not a good design.But if have an easy way to get a pointer to the owner, in practice, is
very convenient.It may be convenient in short run, but I think in the long run creating
hidden dependencies would make code less robust so it is better not to
enable it as a best practice.Stas Malyshev
smalyshev@gmail.com
Everything is relative, when there is an experience in a dynamic
context (this) in JS, while unwieldy structure in PHP code look
something old and not comfortable.
I think, that purchased experience will be the use of safety culture
dynamic runtime context, many developers it would be appreciated, to
implement this PHP frameworks.
Hi!
Everything is relative, when there is an experience in a dynamic
context (this) in JS, while unwieldy structure in PHP code look
something old and not comfortable.
In this case I'd suggest you to write your PHP code in wieldy structure
so it would be comfortable ;) I'm not sure what exactly you mean by
"dynamic context in JS" but take into account that JS implementation of
OO is quite different from PHP, so you can not directly port concepts
between them.
I think, that purchased experience will be the use of safety culture
dynamic runtime context, many developers it would be appreciated, to
implement this PHP frameworks.
I'm sorry, I'm having hard time understanding what you mean here. I
believe if you want to take it further, you'd need to provide some more
detailed explanations, with examples, etc. of what you're trying to
improve and why.
--
Stas Malyshev
smalyshev@gmail.com
Am 01.02.2015 01:15 schrieb "S.A.N" ua.san.alex@gmail.com:
$holder->object->call($holder);
The way I solve this in the very few places (*) where it makes sense, is to
use __call in the holder class to implement forwarding methods that pass on
the holder object reference. The member property is NOT exposed.
Call will be like this: $holder->object_call();
Code could look something like this (untested):
class holder {
public function _call($method, $args) {
list ($propname, $membermethod) = explode('', $method, 2);
if (!property_exists($this->$propname) || !is_object($this->$propname))
// add other policy
return null; // or any other error behaviour
return $this->$propname->$membermethod($this, ...$args);
}
}
(*) really just one place at the moment, tightly coupled, and not as
general as shown above. I don't see a use for the fully general case, where
the member objects would both care about knowing their holder object and
work with practically any holder object.
best regards
Patrick
""S.A.N"" wrote in message
news:CALW=WEDFmUXap7Bx=chHx5VYHcOi1kBahgDkJiF2aDLx6YT6Jg@mail.gmail.com...
2015-02-01 1:52 GMT+02:00 Stanislav Malyshev smalyshev@gmail.com:
Hi!
The reason for creating circular references, usually due to the need to
bind objects.But this relationship can often be obtained from the context of the
call.If the API behaves differently depending on who is calling it, or
requires some information from the caller, it should be passed
explicitly - as a parameter/method call/etc. - not hidden. Otherwise it
would lead to nasty surprises when the user of the API assumes caller
does not matter but the implementor assumes it does.Stas Malyshev
smalyshev@gmail.comThis is a controversial statement.
If the caller explicitly send the object as an argument, it worsens
loose depending API.
And how is this different from Dependency Injection which is supposed to be
a common and accepted technique?
--
Tony Marston