[Zope-Coders] Towards 2.6

[Shane Hathaway]

Chris McDonough wrote:
>>I'm concerned that the right thing to do is still open for 
>>interpretation.  Based solely on the method names, I would guess that a 
>>method called getUserName() should return "Shane Hathaway", while the 
>>method getId() should return something arbitrary like "501".  Neither 
>>one is my login name "shane", which should be available through the 
>>nonexistent method getLoginName().
>>
>>Would it make sense to add getLoginName()?
> 
> 
> I'm not sure.  If we were starting over, and we knew we wanted to
> capture a descriptive username as metadata in stock user folders, I
> think this makes total sense.  But if we wanted to change the existing
> User implementation and still maintain backwards-compatibility, I don't
> think so.  Here's why:  Descriptive user names in systems like UNIX are
> typically optional.  If we make getUserName() return a long descriptive
> name for the user, and if the username is nonexistent, it would make
> sense to return a blank string instead of the login name...
> 
> Maybe we could add another User implementation to the core that did this
> the "right way" after changing all the calls that depend on
> getUserName().  Maybe even make this the default user folder type.  It
> might be a bitch for 3rd-party stuff, though, and is probably
> inappropriate now right before the final release.

What I'm trying to demonstrate is that differentiating between 
getUserName() and getId() right now seems premature.  Given that there 
are only two methods instead of three, I would first assume that one of 
the methods is for metadata and the other is not.  A login name is not 
metadata, so the login name must correspond with getId().  Doesn't that 
make sense?  That's been my thinking all along.  Doesn't anyone else 
think that way? :-)

Oh well, do it the way you like, but I'm likely to mix up the meaning at 
some point. ;-)

Shane