Ticket #123 (accepted planned)
assigning placements properly
| Reported by: | ichthyo | Owned by: | ichthyo |
|---|---|---|---|
| Priority: | normal | Milestone: | 1alpha |
| Component: | lumieraProc | Keywords: | design |
| Cc: | Blocked By: | #100, #119 | |
| Blocking: | #121, #511, #513, #518 |
Description
Find out about the correct meaning when assigning placements.
The default assignment works flawless, but together with changing the pointee (incl. ownership) and copying the chain of LocatingPin objects, it also overwrites the placement ID. Currently I'm in doubt we want this, because it effectively wipes out the old placement identity. Shouldn't rather the ID be omitted when copying, thus making the identiy a constant property of any given placement instance? (We'd need to use custom assignment operators to achieve this)
To decide upon this question, we should have gained a clearer understanding what a placment denotes in session context, and especially we'd need a real use case for assignment. To be revisited
Change History
comment:3 Changed 2 years ago by ichthyo
- Blocked By 100 added
probably should also build upon the revamp of the Placement internals
comment:4 Changed 2 years ago by ichthyo
- Blocked By
meanwhile unsure if placements should be assignable at all. Or just copy constructible? In this case, we could provide a dedicated member function to assign the locating pins, and another oner to merge locating pins....
comment:6 Changed 2 years ago by ichthyo
- Status changed from new to accepted
Meanwhile the PlacementIndex is implemented; it is clear now that the embedded Placement-ID must not be copied.
I've now added a custom copy ctor to this end, but still retained the default assignment operator, because removing it would break some dummy MObject and session code (which will be replaced soon). Actually, assignment should be completely prohibited, because it interferes with the ref-semantics any placement takes on when attached to the session.
Allowing copy construction but prohibiting assignment seems a good compromise; additionally it would prevent use of Placements directly within STL containers (which is a good thing; PlacementRef should be used for this purpose).
