Ticket #123 (accepted planned)

Opened 3 years ago

Last modified 16 months ago

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:1 Changed 3 years ago by ichthyo

  • Blocking 121 added

comment:2 Changed 3 years ago by ichthyo

  • Keywords design added

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:5 Changed 2 years ago by ichthyo

  • Blocking 511 added

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).

comment:7 Changed 2 years ago by ichthyo

  • Blocking 513 added

comment:8 Changed 2 years ago by ichthyo

  • Blocking 518 added

comment:9 Changed 16 months ago by ichthyo

  • Priority changed from lesser to normal
  • Type changed from todo to planned

future

Note: See TracTickets for help on using tickets.