, I set each port's connection
property to point to another port. So Input points to Output and Output
points to Input. Only one-to-one relationships are allowed (one connection
per input/output).
It's best not to do this kind of cleanup in dealloc/finalize. Instead, have
an explicit method
For example, if I were creating an application with documents that
consisted of connected nodes, I’d have the document own (retain) the nodes
and have the nodes just reference (assign) each other.
Actually, that's what I do ;)
Thanks
___
Cocoa-dev
Hi Karolis,
I’d say your pattern is absolutely correct. I assume those two objects
do not retain each other, they just need to know about the other one.
And they should be allowed to die separately, while cleaning up the
otherwise dangling pointer in the other object.
The good news is
Thanks, Kai, Greg, Jens,
It's generally a bad idea to have two objects each retain the other. It
produces a reference loop, which means neither object can be deallocated
without manually releasing each side of the relationship.
As was stated in my original email these are all weak
On 12-Oct-2009, at 7:26 PM, Karolis Ramanauskas wrote:
Thanks, Kai, Greg, Jens,
It's generally a bad idea to have two objects each retain the
other. It
produces a reference loop, which means neither object can be
deallocated
without manually releasing each side of the relationship.
As
On 12.10.2009, at 13:42, Roland King wrote:
On 12-Oct-2009, at 7:26 PM, Karolis Ramanauskas wrote:
Thanks, Kai, Greg, Jens,
It's generally a bad idea to have two objects each retain the
other. It
produces a reference loop, which means neither object can be
deallocated
without manually
No. Under GC you don't have this problem at all. You don't need
weak references or anything else funky, it just works. MyClass1
pointing to MyClass2 and back with ordinary object references/
assign properties does create a cycle yes, however GC can manage
that perfectly well. Once there
Thanks to everyone! Reading all this I realized that there is a little more
to GC than I know... or should I say a lot more. at this point I'm unable to
choose exactly what may be the best solution. I will have to read
documentation and interpret that information through the prism of my
to point to another port. So Input points to Output and
Output
points to Input. Only one-to-one relationships are allowed (one
connection
per input/output).
It's best not to do this kind of cleanup in dealloc/finalize. Instead,
have an explicit method like -disconnect that's called to remove
Good day, everyone,
The situation is simple, I have two instances of the same class (MyClass).
This class has a connection instance variable and a declared property for
that variable:
@property (readwrite, assign) MyClass * connection;
So basically an object has a reference to another object of
Karolis Ramanauskas wrote:
- (void)dealloc {
if (self.connection) {
self.connection.connection = nil;
}
[super dealloc];
}
Why would you do this? You're making one object responsible for the
internals of another object. This is a bad idea. It breaks the
If you want to do something that doesn't break encapsulation, then you
should simply release the one ivar connection. That will let the receiving
object perform its own actions, by itself, on its own behalf, as appropriate
to its own affairs.
Thanks, however, I do not see how to accomplish
On Oct 11, 2009, at 7:44 PM, Karolis Ramanauskas wrote:
I have object1 that has a connection to object2, (object1.connection =
object2). And at the same time object2.connection = object1:
O1 - O2
O2 - O1
It's generally a bad idea to have two objects each retain the other.
It
On Oct 11, 2009, at 4:11 PM, Greg Guerin wrote:
Why would you do this? You're making one object responsible for the
internals of another object. This is a bad idea. It breaks the
individual encapsulation of each object.
But there are times you need to do this. One example is in some
Jens Alfke wrote:
It's not so much making an object responsible for another object's
internals, as simply managing a relation from that other object. In
other words, I'm the one who told the window to point its delegate
property to me, so it's OK for me to tell it to point it to nil
when
If my screensaver must be able to run both in the reference-counted
and in the garbage collecting environment,
should I then implement both the dealloc and the finalize method?
Regards,
Gabriel.
smime.p7s
Description: S/MIME cryptographic signature
On Oct 9, 2009, at 11:31 AM, Gabriel Zachmann wrote:
If my screensaver must be able to run both in the reference-counted
and in the garbage collecting environment,
should I then implement both the dealloc and the finalize method?
If you allocated objects in your class that you need
On Oct 9, 2009, at 10:31 AM, Gabriel Zachmann wrote:
If my screensaver must be able to run both in the reference-counted and in
the garbage collecting environment,
should I then implement both the dealloc and the finalize method?
That is correct.
b.bum
18 matches
Mail list logo
