[Zope3-dev] naming issues: id vs name, delObject vs ?

[R. David Murray]

In an IRC discussion Jim, SteveA, and I talked about some naming issues
with the current code, and we would like more input.

1) Id vs Name

    Zope2 fairly consistently uses 'id' for the string that identifies
    (names) an object.  In Zope3 the Interfaces and code sometimes
    use 'id', and sometimes use name.  We should pick one or the
    other and make the code and Interfaces consistent.

    Arguments favoring id:

      a) Aope2 uses it

      b) It is two characters shorter <grin>

    Arguments favoring name:

      a) The Zope3 entity we are labeling is slightly different in
	 semantics from from thing labeled by a Zope2 id.  In zope2,
	 an id "belongs" to an object, and also shows up in the
	 container's mapping pointing to that object.  In Zope3,
	 the name is what the container uses to map to the object, while
	 the object itself does not (usually) know the name used to
	 refer to it.  Thus, using a different term makes it clear
	 that things are different now.

      b) Saying "Returns the named object" in a docstring is a little
	 more elegant that saying "Returns the object with with the
	 given id".

2) delObject vs ?

   Steve observed that IWriteContainer has a method 'delObject' whose
   semantics are to remove the *reference* to the object from the
   container.  The name delObject, while fairly reasonable when you
   think of it in analogy to the python 'del' keyword, is potentially
   confusing, especially to a newcommer.  Should we choose another
   name?  delObject's inverse is currently called setObject; we may
   want to rename both into some consistent scheme.

   Here are some alternate suggestions:

	o removeObject

	o linkObject, unlinkObject

	o defName, delName

	o addObjectRef delObjectRef

	o bindName, unbindName

   It also occurs to me that we could switch to using python syntax::

   	collectionobject['somename'] = object
	del collectionobject['somename']

   I won't be surprised if someone tells me this last is abhorent for
   some reason <grin>.

--RDM