[cap-talk] Objects and Facets

[Eric Northup]

On Wed, 2006-08-02 at 11:53, Charles Landau wrote:
> At 9:19 AM -0400 8/2/06, Eric Northup wrote:wrote:
> >It seems to me that, in the design you presented above, there are two
> >distinct objects.
> >
> >The second one, an OpenFileHandle, responds to requests like read(),
> >write(), seek(), tell(), close(), etc.  The OpenFileHandle object has
> >access to state representing all the bytes of the file, and also the
> >per-session state like the cursor position.
> 
> I would just call it an OpenFile, since all capabilities are handles.
> 
> The state of the OpenFile object is the cursor (and the "other 
> things" unnamed above), and a capability to the file.
> 
> >The first one responds only (?) to the open() operation, and returns
> >OpenFileHandles.  So it might be considered a "factory" object,
> >OpenFileHandleFactory.
> 
> I would just call it a File. If you were to implement other 
> operations such as ReadWithCursor(), you wouldn't want to rename the 
> object.
> 
> >This object has access to the state representing
> >the bytes of the file
> 
> The File object doesn't just "have access to", but actually contains, 
> the bytes of the file (and the meta-data). That is its state.

I agree.

> >It might be worth considering that *all* the object state described is
> >"private", from their clients in the sense that the objects do not share
> >it freely with clients.  Instead, the objects expose accessor methods to
> >manipulate the state.  The fact that some state is shared between
> >different OpenFileHandle instances doesn't make it any less private to
> >the clients.
> 
> Perhaps I'm misunderstanding the above, but clearly the file data are 
> not private. If two processes open a file and one writes, the other 
> will read the written data.

I meant "private" in the C++ sense; that the OpenFile does not give
clients
direct access to the data/capabilities used to implement the file data,
but rather exposes them through method invocations.  Assuming that the
OpenFile used a Segment to implement the file data, the OpenFile would
not give clients the capability to that segment.

There is no privacy/confinement of the data clients send to an OpenFile,
so perhaps I need a better term for the relationship between an object
and
the data+capabilities it does not provide direct access to.

> >I would not consider them two facets to a single object, because I think
> >the factory object is mostly a wrapper (perhaps an EROS Contructor /
> >KeyKOS Factory) around a second type of object.  So their top-level
> >message processing event loops are different.  I would consider
> >ReadOnlyOpenFileHandle / AppendOnlyOpenFileHandle /
> >ReadWriteOpenFileHandle to be different facets of the same object.
> >
> >But the OpenFileHandleFactory and the OpenFileHandle could be
> >implemented in a way such that they are two facets to the same event
> >loop.  In that case, I would consider them to be different facets.
> 
> The description of objects and facets depends on their interfaces and 
> is independent of the implementation. The File and the OpenFile have 
> different state, so they are different objects.

Thanks for this clarification.

-Eric