Re: ACTION-161 - proposal for message management

Hi Max,

On Apr 22, 2010, at 15:31 , Max Froumentin wrote:
> Here's a simple solution.

Between this and Daniel's ACTION-164, it seems to me that there is a simple solution for this, that no one has objected to it (yet), and that there are good reasons for having this functionality inside the same API. The only counter-argument I see is if there is interest in only implementing a subset, but I haven't heard that so far (and the specification can be inherently modularised I guess). Or did I miss something? If not, I suggest that we resolve to add this functionality.

> add to interface MessagingManager
> 
> const unsigned short FOLDER_INBOX = 0;
> const unsigned short FOLDER_OUTBOX = 1;
> const unsigned short FOLDER_SENT = 2;
> const unsigned short FOLDER_DRAFTS = 2;

We have a tendency to resort to numerical constants. I wonder if that's not just cargo-culting. Essentially, it leads to three potential code variants:

// unreadably terse
foo.getMessages(2, cb);

// unreadably long
foo.getMessages(MessagingManager.FOLDER_OUTBOX, cb);

// meh
var outbox = MessagingManager.FOLDER_OUTBOX;
foo.getMessages(outbox, cb);

Instead, I reckon we could use string constants:

foo.getMessages("outbox", cb);

I know that WebIDL doesn't do string constants, but I don't think that it matters. We can get away with "The type parameter accepts the following case-sensitive values: inbox, outbox, hatbox, outofthebox, springbox. Other values must be ignored." It has the further advantage that it has a clear set of extensibility strategies using strings to identify other, possibly arbitrary, folders.

I for one have always hated the numerical constants in the DOM, if we could avoid propagating that I'm all for it. It's not like we're standardising UNIX system calls in the 1970s.

--
Robin Berjon
  robineko — hired gun, higher standards
  http://robineko.com/

Received on Wednesday, 28 April 2010 12:20:44 UTC