<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style=""><div><div>I agree that there is no one-size-fits-all (OSFA) solution but I don't understand why you need different protocols in the case you mention. If PO is a persistent-object, then why do 

</div><div><br></div><div>(copy-thing PO)</div><div><br></div><div>and </div><div><br></div><div>(copy-thing (list 1 2 3 PO))</div><div><br></div><div>need to treat PO differently?</div></div></div></blockquote><div><br></div>

</div>these are the two use-cases: <ol><li>user wants to clone an object. we have annotations on the model how to clone different properties (like specific associations) of PO's. </li><li>user wants to manipulate queries, which involves saving and copying queries. queries may contain direct (lisp vm level) references to PO's. or to be more precise references to entities which are PO's with identity. the contract of entities is that in a given transaction there may only be one clos object associated to the transaction that describes a given entity. therefore when copying a query we must not copy the PO, only "copy" by reference.

<br></li></ol>so it is basically:<br><br><div>(clone-persistent-object PO)</div><div><br></div><div>and </div><div><br></div><div>(copy-query `(select (foo)<br>                      (assert (typep foo 'some-entity))<br>                      (assert (parent-of foo) PO)))

</div> now one may argue that 1 should not use copy-thing, but the standard behaviour is ok in most of the time and because of that there won't be too many model annotations. so not using copy-thing would mean quite some code duplication.

the ideal solution would be as i've described, that there were actually two different generic method protols (at least on the api level). a less ideal solution would be if we simply used contextl to define some copy-thing/copy-inner-class overrides in different layers and activate the given layer as needed.

<br><br>hm... if metacopy were integrated (via asdf-system-connections) with contextl then maybe we could keep the current copy-thing structure and provide macros that define the layered stuff and a toplevel entry point like the above mentioned clone-persistent-object transparently:

(defcopyprotocol 'clone-persistent-object (super-copy-protocols)) (defcopymethod ((self type)) ...) where defcopyprotocol would define a 'clone-persistent-object and an internal layer inheriting the layers of the super-copy-protocols. then 'clone-persistent-object would enable that internal layer transparently and then call copy-thing.

hm, if i didn't have several other things to do right now i would put together a prototype. opinions? --  - attila "- The truth is that I've been too considerate, and so became unintentionally cruel...

<br> - I understand.<br> - No, you don't understand! We don't speak the same language!"<br>(Ingmar Bergman - Smultronstället)