Re: [cme-dev] question on the expected mutual consistency of project cla

[Juri Memmert <memmert@xxxxxxxxxxxx>]

On Fri, 2004-04-30 at 15:34, Stan Sutton wrote:

Hi All,


<snip>
> The key consistency issue is whether references to classes will be
> resolved in the same way in all projects, i.e., according to all
> classpaths in the workspace.  There is a more formal and precise
> statement of what this means below, but a basic manifestation of the
> issue is whether a reference from a class A in one project to a class
> B in another project will be resolved to the same declaration of class
> B according to the classpaths in two different projects.

I believe it is safe to assume that a reference to
org.eclipse.cme.some.package.SomeClass always references the same class,
regardless of which project references the class, IF the declaration
exists only once within the classpath.
Yes, I know, great deal, completely obvious. ;-)
Even in projects which have circular classpaths (and the associated
hacks) or JDK version constraints that require the same class to be
compiled against different JDKs, the declaration of the class remains
the same.

It does become a bit murkier when the same package.class declaration
exists more than once within the workspace.

Project_1.org.eclipse.cme.some.package.SomeClass and
Project_2.org.eclipse.cme.some.package.SomeClass. 
This situation is a tad more complex as there are several different
possible use cases at work:

- There is no connection between these two classes and they have the
same declaration by accident (Project_1.utility.Converter and
Project_2.utility.Converter)

- There is a reason for the overlap because each project maps to a
concern and the different concerns are to be mapped onto one another
(Concern_1.org.eclipse.cme.some.package.SomeClass and
Concern_2.org.eclipse.cme.some.package.SomeClass).

- The concerns defined are mutually exclusive, so while both projects
are part of some concern and there is a concern mapping for them, they
never are mapped onto one another.

The problem is, of course, that all these options can not be identified
until there IS a concern model that can be resolved against the
classpaths.
Until that condition is met, I am afraid that there is no easy way to
guarantee that all references to some.package.SomeClass always can be
mapped to the first occurrence in the classpath.

Not that any of this is news to you, of course. ;-)


> On the other hand, this condition is not required by Eclipse, we don't
> know whether typical users will typically assume this condition holds
> or will be taking advantage of the more general Eclipse semantics, and
> we have no idea as to whether our current workspace (or typical
> workspaces) will observe the condition.  We would also have to create
> some means of verifying the condition (which we expect would operate
> mainly as a stand-alone utility).

Given the workspaces I have seen, it is safe t assume that the Eclipse
semantics will be used to their limits.


> If we cannot safely assume that the condition holds (or if we just
> want to model the more general Eclipse semantics), then we would have
> to compute a set of relationships relative to the classpath for each
> project and keep those separately (or be able to sort them out).  This
> has a higher cost in terms of computation and storage.  It could
> complicate the views of the workspace and the formulation of queries
> against it (which would have to accommodate an element of project
> relativity).  The impact on the loaders would be minor (less than the
> impact of changes that we've incorporated on a regular basis); my
> understanding is that future work on query implementations could
> accommodate this change readily but that existing implementations
> would have to be re-engineered to some extent.  On the other hand, it
> if is not safe to assume the condition, and we do not contextualize
> the relationships, then the information and views we provide for a
> workspace will be wrong in general and the utility of the environment
> will be compromised.

I believe that a view that provides only a subset of the semantics
Eclipse gives the users would not be beneficial, even if the cost of
computation is higher (or are we talking about orders of magnitude
here?)
People would want to employ the CME to their existing projects... and
those would use the superset of functions, not our subset.


> Two additional notes:
>       * Even if the classpath-consistency condition is a safe
>         assumption in many cases, we probably still need the
>         capability to subdivide a workspace (or our views of the
>         workspace) into some form of working sets.  Even people who
>         habitually work with sets of Eclipse projects that have
>         consistent classpaths may still work with several such sets in
>         a single workspace.

I know I work with more than a dozen working sets.


>       *   Accommodating multiple working sets is likely to raise some
>         of the issues that contextualizing relationships would raise,
>         e.g., the need to accommodate contextualized views and
>         queries.  However, it would probably not entail some others,
>         such as the performance and storage costs for multiple
>         alternative sets of relationships.

>From what I understand, the cost of tailoring the underlying model to
either the full workspace or different working sets would be minimal (at
least in my naive way of looking at the problem). But it definitely
would be useful to scope queries to working sets, like so many other
queries within Eclipse (Problems view, search, etc.)


> So, we're wondering whether classpath consistency reflects reality in
> the perception and use of Eclipse and whether it would be natural or
> onerous to require it of our users.  We don't have the breadth of
> perspective to judge this by ourselves.  Please let us know what you
> think!

>From what I can tell, I do not see a single consistent classpath across
the full scope of the workspace. There are consistent paths for part of
the workspace (for instance working sets) and most of my working sets
either do not overlap or have a consistent classpath over all projects
in all working sets that overlap (e.g. Working Set 1 contains the
projects P1, P2, P3 and Working Set 2 contains P2, P4 and P5. Then P1,
P2, P3, P4 and P5 have a consistent classpath)


I hope that helps,

	Juri


-----
Bucy's Law: Nothing is ever accomplished by a reasonable man.