Re: delete this; (Was: std::string name4 = name4;)
On Aug 11, 9:21 am, =D6=F6 Tiib <oot...@hot.ee> wrote:
On Aug 10, 1:19 pm, James Kanze <james.ka...@gmail.com> wrote:
On Aug 9, 8:56 pm, =D6=F6 Tiib <oot...@hot.ee> wrote:
On 9 aug, 20:34, James Kanze <james.ka...@gmail.com> wrote:
It's just good OO design. An object has behavior, and
part of that behavior is destroying itself when the time
comes. (In practice, of course, the issues are more
complicated, and in some cases, the actual delete will
be done by a transaction manager or some such. But the
decision is usually that of the object.)
Now i have yes, 3 replies that this is not the case. It is therefore
self-owned object?
The real question is whether ownership even has a meaning. An
object is an autonomous entity, with its own behavior. It
doesn't (necessarily, at least) "belong" to any other object.
That other, owner object must not be particularily real "owner" but
some whole for a part. If there are none then it feels that i lack a
step of hierarchy and some things belong nowhere. It may be for
example a "collective" or "population" if nothing else.
But why do you need to introduce additional, owning "wholes", if
the application logic doesn't require them. That's just added
complexity.
I avoid self-owned objects. It may be is good OO, but turns
things unnecessarily complex.
Just the opposite. If you forget about ownership, and consider
that an object has responsibilities, and that one of those
responsibilities is to delete itself when it no longer has any
reason to continue to exist, it simplifies a lot of things.
Presence of ownership (more properly whole/part hierarchy) makes
things like dumping full state of everything, saving and restoring
situations simpler.
For some definition of "everything"?
What you're talking about doesn't sound like ownership to me,
but rather navigation. If you need to navigate over
"everything" (for whatever reasons), then you need to provide
the means of doing so. It has nothing to do with ownership or
object lifetimes.
Serialization is often headache or nightmare that is good to
simplify. Other things it helps with are when achieving full
exception safety or lockless synchronization. These topics
take also master hands to make properly.
But ownership in an absolute sense doesn't really play a role
with either. Exception safety is just a form of transactional
integrety, which doesn't involve ownership (except insofar as
transactions can be said to "own" the objects in the
transaction). And the "ownership" relevant to thread safety is
which thread "owns" an object (at a particular time).
Of course there are tons of situations where i have not been.
Application (may be?) does not need the advantages what such
hierarchy gives. Hierarchy is maybe too "feudal" and
"inflexible" for some other thing? What are these "lot of
things"?
(Of course, a lot depends on the application. If you have
complex transactions, which have to be atomic, it's very
difficult to roll back a deleted object. So regardless of
who makes the decision to delete---the object itself or some
other object---the "delete" will take the form of a request
to the transaction manager, who will do the actual delete in
the commit phase.)
Probably i see now. You do not have whole/part relations, instead some
finalizing is done by transaction manager.
It depends on the application. If the application handles
external requests which may modify any number of objects
(including creating new objects and deleting existing objects),
and such requests must be atomic, then you need some sort of
transaction management.
Sounds interesting, but i suspect that it is complex magic
there and i can really not see how not.
No magic, but if you need transactional integrity, you need some
way of rolling back any changes that might have been made before
failure occurs. (If at all possible, of course, it is
preferrable to ensure that everything will work, and report any
errors and abort the transaction before changing anything. But
this isn't always possible.)
[...]
This is independent of who does the delete---in my parenthetical
example above, the transaction manager certainly doesn't own the
object, even if it does do the actual delete in its commit
phase. (And the object lifetime can obviously be more than
a single transaction.)
Yes, sounds so. Possibly i do not fully understand your
example about transactions. It helps to minimize undo/redo
problems?
It ensures the basic integrity and internal coherence of the
system. Depending on the automicity required, it may be
trivial, but I've usually worked on larger systems, where it
required some additional logic.
--
James Kanze