-
Key: CPP12-2
-
Legacy Issue Number: 4160
-
Status: closed
-
Source: AdNovum Informatik ( Stefan Wengi)
-
Summary:
I took a closer look at orbos/99-07-01 to see how I'd have to implement
local objects.
Several questions came to my mind:1)
what happens if you invoke CORBA::Object::_duplicate on a LocalObject?- does it call _add_ref on the local object (as the spec seems to say in
4.1.2)? - is it allowed to return a copy of the object?
2)
how is memory handling done on existing interfaces?4.1.5 defines a list of interfaces that are changed to local interfaces
e.g. CORBA::Current. How are they supposed to support proper memory
handling when the default implementations of _add_ref/_remove_ref do
nothing?3)
local interfaces can be implemented by the application programmer, e.g.
PortableInterceptors.- what happens if my _duplicate operation on CORBA::Object creates a
copy (which is legal) and my implemenation of the local interface
contains some state?
This mapping creates more problems than it solves.
It breaks at least one of the basic rules of OO design: base classes
must not know about subclasses.
Also disabling some methods that are valid on CORBA::Object (e.g. is_a)
is a hint for bad design.
Why not take the same interface 'inheritance' approach as with value
types? - does it call _add_ref on the local object (as the spec seems to say in
-
Reported: CPP 1.1 — Thu, 18 Jan 2001 05:00 GMT
-
Disposition: Resolved — CPP 1.2
-
Disposition Summary:
see above
-
Updated: Fri, 6 Mar 2015 20:57 GMT