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

["Clemm, Geoff" <gclemm@xxxxxxxxxxxx>]

Having the interpretation of this request be context sensitive
would probably result in confusion and errors.

Since this is not a frequent operation, I'd probably prefer that
a "confirmation" dialog occur, that explicitly gives the user the
choice of which interpretation to use (i.e. "move all classes in
this package" vs. "move this package and its subpackages).

Cheers,
Geoff

-----Original Message-----
From: Marco Qualizza [mailto:mqualizza@xxxxxxxxxxxxx]
Sent: Tuesday, March 18, 2003 3:16 PM
To: Clemm, Geoff
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