Die Unterstützung für Zuweisungen wird typischerweise von der Programmiersprache gegeben und kann (z.B. in C++) für bestimmte Objekttypen überdefiniert werden. Prinzipiell gibt es drei Arten von Zuweisungen bzw. Kopieroperationen:
Während die Zeigerzuweisung in jedem Fall notwendig ist und auch zur Verfügung gestellt wird, stellt sich bei den beiden Kopiervarianten die Frage, ob sie überhaupt sinnvoll sind, da in beiden Fällen private Daten und Datenstrukturen ohne Kenntnis des betroffenen Moduls dupliziert werden können. Wenn kein Bruch der Abstraktions- und Modulgrenzen zugelassen werden soll, dann darf eine Duplizierung nur in Kooperation mit allen betroffenen Parteien durchgeführt werden.
Beispiel: Wenn ein Objekt s vom Typ Streams.Stream dupliziert werden kann, dann gäbe es Schwierigkeiten, wenn es private Verweise auf Systemresourcen gibt (z.B. ein Dateideskriptor bei UnixFiles): Die Operationen auf dem ersten Objekt s und dem geklonten s0 würden sich gegenseitig beeinflußen, da sie auf der gleichen Datei arbeiten und wenn der eine geschlossen werden würde, könnte auf dem anderen nicht mehr gearbeitet werden. All dies kann nicht in genereller Weise vorhergesehen und berücksichtigt werden.
Eiffel löst dies Problem dadurch, daß die Operationen grundsätzlich (über ANY) zur Verfügung stehen, jedoch für einzelne abgeleitete Klassen überdefiniert werden können. Somit kann die notwendige Kontrolle ausgeübt werden.
In Oberon hingegen ist das Klonen per Zuweisung nur zulässig, wenn keine privaten Komponenten enthalten sind. Allerdings gibt es in der Ulmer Oberon-Bibliothek eine weitere etwas aufwendigere Methode zum Klonen für persistente Objekte, da ein abgesichertes persistentes Objekt auch dann zum Leben wieder erweckt werden kann, wenn sein Original noch lebt. Da die Persistenz-Eigenschaft voll von allen betroffenen Abstraktionen und Implementierungen kontrolliert wird, ist dies ebenfalls kein Bruch der Modul- und Abstraktionsgrenzen.