Roles (Re: Category Theory and Dynamic Object Document Browsing)

Daniel Allan Joyce daniel.a.joyce at worldnet.att.net
Sun Feb 13 20:33:29 UTC 2000


> Well, yes, though it does a little structuring as well.  How does
> this apply to components/connectors and roles/ports?  I really don't
> understand.

	The point was I thought you were advocating a different inheritance
system from what already exists.

> As far as I've given them roles aren't part of the tree, they're not
> even objects (though, with the right meta-reification, they would be
> integrated back into the tree, though not at the same level).  They
> are slots in connectors.

	Huh?
	Are you talking about protocol/interface objects?

> 
> Yes, of course.  Most of this has always been done, sort of, in some
> way shape or form (just like objects *do* have different aspects
> etc.)  The issue is how to actually talk about these things
> explicitly and slice up the conceptual space.

	That's what programming is about. I agree on that.

> 
> Nope, that's not it at all.  Object <-> Role is not a "isa"
> relationship.  A role is something that an object fills, just like an
> actor fills a role or a word fills a role in sentence.  "Subject"
> (as in grammar) is not a kind of word, it is a role in a sentence
> that can be filled by different words.  In order to fill this role,
> they have to be "noun" compatible, however, they don't have to
> actually *be* nouns.  For example, a verb can take that role if it
> acts like a noun (gerund etc.).

	Well to be noun compatible they either 
		A) inherit from nouns ( too limiting )
		B) Use a Noun Protocol/Interface
		
	If you use the new interface code from Squeak, well, it's an object.
They made it that way so interfaces can inherit, and we can have
protocol heirarchies. 

	So are you talking about something different or lower level than
interfaces?

	Also, the interface subtree is pretty orthoganol to everything else in
the system.

> 
> Yes, we do try and model these things, but haphazardly at best.
> 
> 
> That was what ports are about.  An object's interface is a set of
> ports, with each port appropriate for specific roles.  How an object
> got to have that port is immaterial.
> 
	But if the parent has all the ports to communicate to the kids, then
the parent starts getting this horribly convoluted interface, for things
it doesn't even directly implement. Things that are outside it's direct
purpose.

	If we provide access to the child components of a composite then we
open up internal implementation. 

> >       How do you manage the parts of a composite object that express
> > different roles? How is it best to talk to them?
> 
> Through the port appropriate for that role.  Ports of objects fill
> roles of connectors.

	Ah, okay, we have objects/whatever that group  interfaces to
parents/children in composites as roles specific to that composite, but
that do make sense to the pieces individually...?
	Then again, isn't this just a sub/superset of interface behavior? Oh,
but it'd require some way to 'hold onto' ref to different pieces of the
composite so it knew how to route messages as needed. 
	This is something I've been struggling with at work. Dealing with a
complex composite object that needs to manage different types of data
about a given part. Something like a 'roles' interface would be useful
without having to return subcomponents of a composite object ( doing
this to avoid cluttering up the interface of the composite's parent ).
My 'parent' would then just present a set of roles to the world instead
of all these interfaces, or resort to having to provide individual
handles to each of it's subcomponents. 

	If this is what you mean, yes it would be useful... :)
	
> 
> Marcel
>





More information about the Squeak-dev mailing list