[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [imp-dev] Semantics of TypeStore
|
Hi Jurgen,
Good questions.
It's true that always treating imports transitively could cause problems
since at this point there's essentially a single global namespace.
E.g., if
TypeStore A imports TypeStore B imports TypeStore C, and A defines a
type Foo, a conflict arises if at some point TypeStore C starts
exporting
a different Foo.
I think the addAll() proposal actually introduces another problem: now
clients of a TypeStore need to know where to find all of the other types
that are needed. In some sense this breaks TypeStore encapsulation.
We could try making encapsulation the default (i.e., importing a
TypeStore
doesn't automatically import its transitive dependents), and
permitting a
TypeStore to re-export types defined by its dependent TypeStores.
That said, I'm not sure that we're not conflating two issues here: the
notions of "interface" (or "module" or "namespace") and caching. To the
extent that TypeStores correspond to interfaces, all types are public
and necessary. Caching a type, on the other hand, shouldn't imply
exposing it to clients.
So, in other words, what's the real purpose of the TypeStore?
Canonicalization? Interface definition? Caching?
On Feb 25, 2009, at 11:17 AM, Jurgen Vinju wrote:
I was talking about TypeStore with Arnold Lankamp and we were
thinking of removing
some functionality from it. Currently it implements an "import"
functionality, which is designed
to lookup types through TypeStores that refer to eachother. The
current implementation
does not interpret imports transitively. It simply searches for a
type locally, and then in all
the imported TypeStores.
This design is inspired directly by the semantics of Rascal, but
what if you want something different?
Sometimes you might want to have transitive imports, sometimes you
don't. The fact that
we can discuss this is a hint that we may not want this
functionality at all on the PDB level.
So, we could remove the import functionality from TypeStore, and
instead add an 'addAll(TypeStore other)'
method to it. Then, the TypeStore acts like a store that manages
(and checks) type declarations on the PDB level,
but nothing more. More advanced functionality could be implemented
by user-defined sub-classes of TypeStore or
other classes that manage TypeStores. Or, direct API users in Java
would probably need nothing more then this
simple TypeStore functionality.
What are your thoughts on this?
--
Cheers,
- Bob
-------------------------------------------------
Robert M. Fuhrer
Research Staff Member
Programming Technologies Dept.
IBM T.J. Watson Research Center
IMP Project Lead (http://www.eclipse.org/imp)
X10: Productivity for High-Performance Parallel Programming (http://x10.sf.net
)
