Hi Per,

Good work in compiling the list. You left out the changes to the
Selector module though.

Some random thoughts inline:

On Mon, Oct 27, 2008 at 05:49, Per Cederberg <[EMAIL PROTECTED]> wrote:
> MochiKit.Base
>  o select -- [mp] copies listed keys (and values) from an object
>  o mask -- [mp] removes listed keys (and values) from an object

I would suggest more descriptive names, selectAttributes and
deleteAttributes perhaps.

>  o stackTrace -- [mp] returns current execution stack trace
>  o injectStackTrace -- [mp] injects stack trace for a function

These should perhaps be in an optional module called "Debug".

>  o version -- [other] returns an object for browser detection & such

Needs more descriptive name, this suggests only MochiKit version.

> MochiKit.Async
> MochiKit.Cookie -- new module in [trac]
> MochiKit.Ajax -- new module in [me], names not exported (so no collisions)

I never liked that the XmlHttpRequest stuff was in Async. I also
dislike the name Ajax as it is imprecise and has become very
overloaded. I suggest trimming Async down to just the generic
mechanisms of deferreds etc. and creating a new module, called HTTP.
This module would contain the XmlHttpRequest wrappers (relying on
Async of course), utilities for url-encoding, dealing with HTTP
headers and cookies.

> MochiKit.DateTime
>  o toApproxPeriod -- [mp] converts millis to an approximate time period

I would vote against this. This functionality is too app specific to
add to a generic library. Rather, it should be published in a
"snippets" section on the MK website - as it will most likely require
tweaks for each use case.

> MochiKit.Queue, Stack and AsyncQueue -- new modules in [trac]
>  -- these are suggested data structures, should perhaps be placed in
> a Data module or similar.

I agree these should be combined in one module. I don't know if
"Collections" is the proper name - "Data" is perhaps better.

> MochiKit.Query -- new module in [me]
>  -- I won't document this module here, but it seems (mostly?) API
> compatible with jQuery. It uses MochiKit to implement (part of) that
> API.

I'm not entirely convinced this fits in MochiKit. Why not just use jQuery?

cheers,
Arnar

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"MochiKit" group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to