Re: delete this; (Was: std::string name4 = name4;)
On Aug 12, 5:01 pm, =D6=F6 Tiib <oot...@hot.ee> wrote:
On Aug 12, 12:57 pm, James Kanze <james.ka...@gmail.com> wrote:
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.
Usually it solves a real problem. For extending example of
"collective in location": Various effects are location-local
(like thread-local?). You do not need to build separate
messaging, signaling, observing system into each of objects to
tell to whole population in a location about such effects for
example. Instead you can tell it to "collective in location".
And then? This artificial "collective in location" doesn't
really need to know; other objects may or may not need to know.
Or does the "collective in location" notify all of the other
objects in it? This seems a bit strange to me: perhaps some of
the interested objects are in a different "collective in
location", and most of the objects in the "collective in
location" are probably not interested.
Presence of ownership (more properly whole/part hierarchy) makes
things like dumping full state of everything, saving and restorin=
g
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?
Almost never. That is the point. Tree-like hierarchy helps me to
simplify and to sort out what is a minimal "whole" set that has to be
serialized.
The "whole" set which needs to be serialized is the set of
objects modified in the transaction (if the serialization is for
persistency), or the objects which should be returned from the
request (if the serialization is for data transfer)---in the
latter case, it's entirely possible that some of the objects are
on the stack.
[ ... ]
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.
Ok. Lets say i need a complex multidirectional graph.
I implement it on base of vertexes list and nodes list. For me
such underlying simple structure helps to implement and verify
and serialize and test that complex structure of graph and
algorithms on it. Now ... how such underlying tree-like
structure ("graph" -> "node list" -> "nodes" and "graph" ->
"vertex list" -> "vertex") makes something more complex? On
the contrary, the nodes and vertexes lists are maybe not
naturally there but for me they make everything simpler and
more robust.
What role do the node list and vertex list play in the
application? I've not done a lot of work with graphs, but in
general, the graph itself contains the nodes.
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.
Hmm. Are you claiming that presence of such TransactionManager
somehow contradicts with or is limited by tree-like data
hierarchy?
No. It's orthogonal to the data hierarchy.
Data hierarhy likely simplifies developing such
TransactionManagers.
Just the opposite. It's one more relationship you have to worry
about.
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.
What does it really limit? It adds one view to data (data
hierarchy) so that presence of such view has to be taken into
account, yes. But that comes automatically with experience.
For one you may not "delete this" something just like that,
but i have not met urge to do it anywway. Such limit feels not
too intrusive for me. However it has removed number of "what
the hell we do now" situations.
So you have to have some unnatural logic when an object
determines that its correct response to a simulus is to die?
The point is that you're doing extra work for nothing.
[...]
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.
When there is great likelihood that number of objects participating in
atomic operation are not modified, created nor deleted during
transaction, but it is hard to predict then lazy copying (copy-on-
write) may boost performance considerably. Algorithm has always to
discard one copy after transaction (either original set or results of
failed transaction) and it is cheaper to discard a copy that was never
really made at first place. Again ... without hierarchy such lazy
copies may be somehow hanging in air and may make things more error-
prone (at least for average maintainer).
That's simply not true. I've never seen an application where
copy on write was appropriate for transaction management; but
that's not really a problem if that's what you want to do. What
is important is that you notify the TransactionManager in all
such cases, since in the end, it is the TransactionManager (and
only the TransactionManager) who can determine which set of
objects to keep. If you're modifying the original object (not
always a good idea if you're multithreaded), then you could
argue that the TransactionManager is the owner of all of the
backup copies.
--
James Kanze