Re[3]: [platform-vcm-dev] Re: Move Delete Hooks problem

["Kevin McGuire" <Kevin_McGuire@xxxxxxxxxx>]

>>How much flammage do I get if I suggest that the scope of the action is
>>determined by how you're currently viewing your packages?

Well I don't know about flammage but I'm sure you can keep people arguing about it for a long time <g>.

1. As far as I know, the actions don't know the view that they are being executed in.  So this would be a significant change and you can make your own guesses as to the likelyhood of it being made.

2. Its not hard to come up with a case where this isn't what you want.

Personally, I believe they can't be view dependent.

For a practical argument against:

Lets say I hide .project and .class path files.  If one of these files gets modified, I still want it to show up as an outgoing change when I do a CVS synchronize (or, for Geoff, a Clearcase commit ? <g>).  In fact, not committing it would be disastrous!  This is even more interesting a case since these files are modified programmatically and I may not even have realized they were changed.  So operating on just what I can see would be very bad here.

Another trivial example: the Java Projects view (in the Java Browsing perspective) doesn't show files.  If I delete the project, should the files stick around ... somewhere?


For a theory argument against:

Model actions (ie. menu items) are operations on the underlying model, not on your view of the model. From an OO modelling point of view, the containment and dependency rules are determined by relationships in the model, and these determine the scope of elements affected by an operation.  To do otherwise introduces semantic inconsistencies.  For example, strong vs. referencial containment determines whether children should be deleted when the parent is deleted.  (<digression>I seem to recall a very cool paper by Grady Booch (pre Rational) on annotating model relationships to scope the extent of operations, so for example if you copied the car on the assembly line you didn't get the whole assembly line</digression>).

Directories and files in eclipse are strongly contained by their parent directories/projects (except linked resources). This is because it matches the model of nearly every file system.  My UML is a bit rusty, but I think if one were to do a UML model of eclipse, Packages would be stereotypes of directories.  Put another way, Packages get the same containment semantics of directories since directories are the real model.

Kevin

Marco Qualizza <mqualizza@xxxxxxxxxxxxx> Sent by: platform-vcm-dev-admin@xxxxxxxxxxx 03/18/2003 03:15 PM Please respond to platform-vcm-dev

To:        "Clemm, Geoff" <platform-vcm-dev@xxxxxxxxxxx>         cc:                 Subject:        Re[2]: [platform-vcm-dev] Re: Move Delete Hooks problem

The problem with this... problem... is that the way you *view* you packages
will affect your interpretation of how moving/renaming/deleting should work.

If I view the packages as a tree, then, as Geoff stated, it's odd (and
disconcerting) to have to rename/move/delete all "sub-packages".

If I view the packages as a flat list, then I agree with Boris, and only the
specifically moved/renamed/deleted package should be affected.

How much flammage do I get if I suggest that the scope of the action is
determined by how you're currently viewing your packages?


> I agree that the naming of a package (hierarchical or otherwise) has
> no semantic meaning for Java, but I don't see how that is relevant
> here.

> The point is that when you rename/move a node in a naming hierarchy,
> it is very strange/unexpected for that to not result in a rename/move
> of all of the children of that node as well.  For example, suppose
> that a company named "rational" were acquired by a company named "ibm"
> (just a random example :-).  If I move com.rational to
> com.ibm.rational, I expect all of the packages under com.rational to
> go along with it, and don't want to be forced to go and rename every
> subpackage one by one.

> And if I did want to just move the classes in com.rational (and not
> the package itself) then I would have asked for that (i.e. move the
> classes, and not the package itself).

> A supporting argument for this interpretation is that it eliminates
> all the current special cases identified in the response to bug
> id=22458, e.g. keeping the package around if it currently has
> child packages, but deleting it otherwise.

> Cheers,
> Geoff

> -----Original Message-----
> From: Boris Pruessmann
> [mailto:boris+mailinglists.platform-vcm-dev@xxxxxxxxxxxxxx]
> Sent: Tuesday, March 18, 2003 1:31 PM
> To: platform-vcm-dev@xxxxxxxxxxx
> Subject: RE: [platform-vcm-dev] Re: Move Delete Hooks problem


> On Tue, 18 Mar 2003, Clemm, Geoff wrote:

>> I looked at bud id=22458, and the thread seems to
>> assume that renaming package "x" to be "xnew" should
>> not also rename "x.y" to be "xnew.y" and "x.y.z" to
>> be "xnew.y.z", but instead should just leave "x" in
>> place and move the classes defined in "x" to the
>> new package.
>> 
>> I'm interested in what is the basis for this opinion?

> I would think the Java Language Specification, saying e.g. "The hierarchical

> naming structure for packages is intended to be convenient for organizing 
> related packages in a conventional manner, but has no significance in 
> itself..."

> This means that although the packages "x.y" and "x.y.z" share some part 
> of their names ("x.y"), there is no direct relation between them (other 
> than convention). So the packages are independent of each other and as 
> such, renaming should work independetly on those packages.
> _______________________________________________
> platform-vcm-dev mailing list
> platform-vcm-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-vcm-dev


-- 
     The lawn of the state capital is a popular place for people to sled,
     especially when it snows.
        newscaster A.J. Sterling, TVF-Nashville, reporting at the Tennessee
        state capitol after a large snowstorm

    Insurance-Engine.
    (613) 234-2426x226

_______________________________________________
platform-vcm-dev mailing list
platform-vcm-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-vcm-dev