Naming - Remove vs Delete vs Purge

[Paolo F Cantoni]

In a number of threads in this forum (such as; Not Deleting objects in Project Viewer), I observed that the there was an inconsistency in the way EA treated the delete key.  Also how there was (again) that rather arbitrary distinction between Lines and Shapes.

In another context I got to thinking about the question of naming these types of methods.  I've come up with:

[size=16]Removal vs Deletion vs Purging[/size][/font]
[edit]Since the original publication of this Topic, I've come to the view that Purging is a better description than Destruction (the original term) for this function.  (It also has the benefit of a different first letter   (Apr 2010)[/edit]
Removal merely implies the disassociation between the diagram¹ collection and the item
(such as remove class from diagram - but not from model)

Note: Hiding an entire line or shape is conceptually identical to removal.  EA allows the hiding of specific Line Segment - but since they've used "Hiding" for "Removal" - they have to call the functionality Suppress (yet it's inverse is Show - rather than say Restore).

Deletion implies that although the item can be deleted, there is the possibility of recovery (say via undo)

Purging explicitly says there is no recovery from this action!

Consequently,  where an EA operation directly affects the database (and for which, at present, there is no recovery) we should use the verb Purge.  For operations such as on the diagram where there is very often an undo facility we should use Remove or Delete where appropriate.

Thoughts?

Paolo

BTW: you can only suppress one line segment on a line but there must be at least three and it can't be the origin segment.
¹clarification as a result of Midnight's post below...

[size=0]©2006 Paolo Cantoni, -Semantica-[/size]

[Paolo F Cantoni]

Interestingly, while perusing the changes in the interim UML 2.1 Superstructure specification (see other posting UML 2.1 Superstructure Specification  ) I came across the following issue:

Issue 8169 change ‘isRemoveDuplicates’ to ‘isDestroyDuplicates’

(Page 237, Figure 11.10 - Write link actions)

Paolo

[Eve]

Well, isDestroyDuplicates in a class LinkEndDestructionData makes more sense.

For the discussion, there are a number of 'isDestroy...' attributes (isDestroyDuplicates, isDestroyLinks, isDestroyOwnedObjects) listed in the index, one 'isRemove...' attribute (isRemoveDuplicates) and no 'isDelete...' attributes.

The uses of the ones that are defined match the meanings suggested, while there appears to be no use of the concept of recovery.

PS. For those that are interested, page 237 as appears in the document, refers to a page of 256 if you want to jump to it in Adobe Reader.

[Paolo F Cantoni]

Is this likely to be fixed soon?  Now that I'm more involved with EA, I'm getting more problems with EA not executing my intent.

When we destroy an item, EA asks for confirmation.  Could I suggest the addition of another key (such as Shift or Alt or Ctrl) to inhibit the confirmation dialog?

Paolo

[«Midnight»]

Hi Paolo,

I think there is a setting that prevents the dialog in all cases, but agree this might not be wise.

Are you sure about this in your first message?

Hiding an entire line or shape is conceptually identical to removal

It seems to me that hiding an entire line is not the same as removing the connection from the shape. The "collection" in this case would be context-dependant. Here it means removal from the diagram's DiagramLinks collection, but not the element's "Connectors" collection.

We should avoid potential confusion here, as it can easily result in code that obeyed what we say rather than what we mean. The EA dialog that asks what we want to do with the connector when we attempt to delete could be reworded to reflect your suggestions - thus maintaining consistency. However, I am still concerned that the operation is only "conceptually identical" in one sense, and that could be destructive to the model as a whole if I only want to clean up a diagram.

Personally, I'd like to see a consistent - yes Paolo, your signature line works for me - and richer set of API calls. These could then be reflected in the UI. This last might allow a gradual transition from "Unique" to "User" (or Useful, Utile, etc.) in the UI.

David

[thomaskilian]

There are little creatures on Mars. Unfortunately invisible. But they exist!

[«Midnight»]

They were not removed, deleted nor destroyed.

However, if we discover that they no longer exist, perhaps they were deleted. If we cannot reconstitute them somehow (perhaps by finding all that water we think is hiding on Mars somewhere) then they've probably been destroyed.

I think that's it, anyways?

In any case we'll need an MDG technology add-in to effectively model them in EA. And we'll probably have to wait for the Shape Script 2.0 version before people believe us.

[Paolo F Cantoni]

Note: Hiding an entire line or shape is conceptually identical to removal.

Are you sure about this in your first message?
It seems to me that hiding an entire line is not the same as removing the connection from the shape. The "collection" in this case would be context-dependant. Here it means removal from the diagram's DiagramLinks collection, but not the element's "Connectors" collection.

Isn't that good OO practice?  Seriously, I do need to make it clear that it's the diagram's collections I'm referring to.  And (in the EA context) which set of diagrams I'm talking about.  That is, remove in this diagram, but not in that diagram...

Thanx,
Paolo

[Paolo F Cantoni]

I just tried to move some Classes and Associations from one diagram to another.

So I selected the classes I wanted, pressed [Ctrl+X] and went to the new diagram and pressed [Ctrl+V].  I didn't get the pasted elements.

So, after a bit of user confusion, I checked the menu to discover that EA doesn't actually have a CUT function in the Edit menu.  That's Sparx's right (shame, but I'm getting used to the EA unique user interface again...   )

However, it got me thinking, in the context of this thread, which of the three functionalities would a Cut perform?  My vote is for the Remove - with the removed items going into the clipboard.

Thoughts?

Paolo

[sl@sh]

As listed in this thread: http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.pl?board=suggestions;action=display;num=1174644219 I have stumbled over this level-of-removal inconsistency myself. In my case it was the lack of an easy way to destroy (using the terminology of this thread) a connector, that made me realize "delete" was being used for completely different purposes by EA's UI.

What bugs me most is that EA does actually use the term "hide" elsewhere, but then uses "delete" for most other cases within diagrams, when really the function behind it does only "remove" the representations of these element(s) within the current diagram. Since most of the diagram context menu functions actually do work on the actual object and only change the representation as the result of such a change, there is no reason to assume the "delete" function would work otherwise.

Also, when I "delete" sth on a diagram, I can UNDO that - when I delete sth in the project browser, I can't. Even worse: when I create an object on a diagram I cannot undo that either! So "create" (whatever actual method is used and how it's actually called is irrelevant) and "delete" work in reverse when applied to the project browser, but not within a diagram. It gets worse when you look at connectors, because they can't even be selected within the project browser (why?). So when you "create" a connector you cannot "Undo" them, there is no obvious way to destroy them and you cannot even destroy them within the project browser.

I suppose the naming conventions listed by Paolo are just as good as any - I would just wish for a consistent use of terms, whatever they are. And of course a consistent set of functions for all kind of objects, including connectors!

Stefan

[beginner]

Strange. After reading that I once again wonder how a human brain works. One gets used to the most abnormal things. This is the good part.

Because people take these anomalies as given and unchangeable they (the anomalies, not the people) almost never get rectified. This is the very bad part.

I should amend my signature: s/errores/errores et anomaliae/

b.