On Fri, 11 Feb 2005 10:33:07 -0500, Lex Spoon <lex at cc.gatech.edu> wrote:

> Do you know a good writeup of what's wrong with them?

Yeah - here it is: "they suck" ;P

(sorry, couldn't resist)

> Or would you mind
> making a few notes, if not?  I've never worked with VW, and I hear a lot
> of complaints about its namespaces!
>
I think the biggest issue is that they are not orthogonal - they try to  
solve multiple problems. It's a bit hard to be more specific than that  
because it's been a while since I last worked in VW (half a year or so)  
so  mosty remember that they were a mess, rather than the exact reasons.

What probably didn't help, either, was that VW has class categories,  
parcels, packages, namespaces, and these all are largely independent from  
each other. This allows you to create a real mess...

Vague, vague, vague. I think it's important we get it right so I'll try to  
take a peek at VW the coming week, maybe that helps getting my memory  
right.

> I would say that this *is* a namespace approach.  Objects will
> presumably want to refer to items in other partitions than their own.
> What do you do?  Import a local name for it?  Specify it explicitly
> ("item foo of partition bar")?
>
Well, with capabilities you either have the capability or not, you cannot  
decide ad-hoc to 'import' it. So what you'd do in such a system when  
setting up a partition is probably composing a couple of capability-based  
namespaces, handing that to the partition, and off you go. End of story,  
not? If you want to call capabilities in other partitions, you probably  
don't need to refer to them by name anyway. You receive them as capability  
and just send the capabilities messages; you can't instantiate them anyway  
(the primary reason to access objects by name seems to be to access  
classes to tell them to create instances, not?).

The sole reason for namespaces, I think, is that names are rightfully  
overloaded. Personally, I think that a Socket should be a Socket and  
there's no place for a Foo::Socket or a Bar::Socket as in two different  
implementations of a Berkeley-style network socket - if they mean the  
same, name them the same; solve the conflicts rather than work around  
them. But different partitions would typically contain code operating in  
different domains, so the partition a, say, 'Widget' is referred to  
probably contains all the context to access the right kind of widget. An  
application dealing with electrical parts might have a Socket in its  
domain model. Would that domain model need to know anything about network  
sockets? I don't think so, it'd show bad layering. If you let the domain  
model run in a separate partition, connected to the outside world with  
(nameless or locally named) capabilities, you wouldn't really need  
namespaces on top of that, I think.

Anyway, I'm rambling here about a topic I haven't spent enough time on.  
Please ignore all this. I'm going to think about it, look at VW, and get  
back to it, ok? It just occurred to me that capabilities might make  
namespaces unnecessary. And as capabilities and a partitioned image are a  
whole lot more useful than inventing smarter ways of dealing with global  
names, it also occurred to me that that would be more worthy of our  
attention...