Re: delete this; (Was: std::string name4 = name4;)
On Aug 11, 4:38 pm, =D6=F6 Tiib <oot...@hot.ee> wrote:
On Aug 11, 4:45 pm, James Kanze <james.ka...@gmail.com> wrote:
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 theref=
ore
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.
In my experiece requirements just forget to mention there some
level of abstraction.
Or you're inventing some additional layers (and additional
complexity) that just isn't necessary.
Requirements always imply there is something.
Obviously. Starting at the universe. But modeling things that
aren't necessary to the application introduces additional
complexity.
Application logic is later needing it there. "Collective" or
"population" are just examples, there is usually something
with more finesse needed like "collective in location".
I've never found this to be the case. Unless such
a "collective" solves a real problem, its introduction is
artificial and adds unnecessary 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"?
Yes it is that everything that is relevant for something. How can it
be they are not needed to be saved/dumped/serialized? In context of
what they are serialized when they are?
When do you ever serialize the entire application? Depending on
the case, there may be "collections", but most of the time,
they're outside the application, sitting in a data base
somewhere. There's never a case where you'd want to serialize
all of the ClientOrder, or IP addresses, for example; you update
the entries for each in the database, when you modify them.
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.
Somehow it feels that these TransactionManagers and
NavigationManagers and so on are for avoiding clear tree-like
hierachy of data.
There is no "NavigationManager". Navigation is handled by the
objects themselves. And the TransactionManager doesn't avoid
anything---it simply deals with a concrete requirement of the
application. There is no tree-like hierarchy of the data in
most applications; typically, the relationships are far more
complex, and usually, they can and should be considered peer
relationships.
However these do not contradict with clear tree-like data.
They feel like some optimizations/shortcuts and so make it
easier to test and verify that the "managers" work correctly.
A TransactionManager is part of the essential program logic.
The requirements specify the rules concerning transactional
integrity.
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).
Position in objects hierarchy has not to be static.
There is no need for a hierarchy to begin with. Unless it's
part of the requirements, it's something artificially imposed on
the design, limiting and adding complexity.
Considering how unpopular is std::auto_ptr ...
What does that have to do with the problem? The reason auto_ptr
is unpopular is that its specification never stopped changing,
so people were never sure about what it might do. (That was
then---we use it a lot now.)
[...]
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.)
Note that if the object under transaction has hierarchical
layout of data then it makes achieving such integrity simpler.
The objects managed by the transaction might have hierarchial
data, although in many cases, it is flat. The objects managed
by the transaction, however, have many and varied relationships
between themselves, most of which are peer relationships, and
not hierarchial. You can impose an additional, artificial
hierarchial relationship on them if you want, but it's just
additional, artificial complexity.
Make copy of object before transaction and swap and discard
the spoiled one when transaction did fail. It is not always
best performing solution but it is most simple to implement.
It's also one of the most frequently used. For objects which
are modified. The issues are more complex when creation and
deletion are taken into account.
--
James Kanze