On Thu, Oct 30, 2008 at 18:57, Per Cederberg <[EMAIL PROTECTED]> wrote: > Arnar: I didn't include the Selector module in the list since it > doesn't change the API. But naturally, the updates to Selector will > probably be one of the big features in 1.5.
There will actually be a minor API change, the Selector.Selector prototype will go away. Maybe we should also expose the Sizzle prototype instead. >> MochiKit.Base > > The Base module is slowly getting larger. Perhaps this is not such a > big issue. But it will affect load times for everyone, since it cannot > be omitted. We should absolutely be very picky about what goes into Base. >> o isFalse -- [mp] check for false, with wide interpretation > > And, of couse, a corresponding isTrue function. Following Doug > Crockford terminology, these should probably be named isFalsy and > isTruthy instead. To draw from Python again, both could be implemented with one function called "bool". This would convert any object to a boolean. > But perhaps something more generalized would be better: > > firstArgument(isNot(isUndefinedOrNull), arg1, arg2...) How about a generic "first" function in Iter? Would be first(someCheck, iterable[, defaultValue=undefined]) >> o dict -- [mp] merges keys and values to dictionary object > > Coming from Python, this can't be wrong... :-) I'm not sure I understand, JS doesn't have named arguments so this would be called with x = dict({'key1': 'val1', 'key2': 'val2'}) right? Isn't that just the identity function? function dict(x) { return x; } >> o select -- [mp] copies listed keys (and values) from an object >> o mask -- [mp] removes listed keys (and values) from an object > > I think the name suggestions from Arnar are good -- selectAttributes and > deleteAttributes. Or selectProperties and deleteProperties. Should pick the one that is more consistent with JS nomenclature. >> o stackTrace -- [mp] returns current execution stack trace >> o injectStackTrace -- [mp] injects stack trace for a function > > I'm using this for logging, so perhaps that would be a better > location. Creating a new Debug module would also be ok, but we'd need > more functionality to move there. Logging sounds find to me. >> o version -- [other] returns an object for browser detection & such > > Others call this browser(), but MochiKit isn't necessarily used in a > web browser. Perhaps env() or environment() would be better? If MK is ever used in a command-line JS interpreter, then environment would suggest the OS environment variables. I propse platform(). platform() should return an object with keys/values if called with no arguments, and return a the value of a key otherwise.. i.e. platform() == {'kind': 'browser', 'name': 'Google Chrome', 'version': ...} platform('name') == 'Google Chrome' > Agree with Arnar on the HTTP module. Don't know if the JSON stuff fits > in there, though. Or perhaps they do. Not sure if there's a better place atm. >> MochiKit.Signal >> o connectEventMap -- [trac] connect signals through a declarative map > > I don't see any clear benefit with this. Personally kind of like to > declare the signals one by one in code. I agree. > The default Array class provides an efficient Stack and Queue already. > So I'd like to see a solid use case here. ... also with this. > But again. If I'm the only one interested in pushing [Widget] forward it > is probably better suited for a separate project. I think it might. To me, MK is a programmer's utility library. UI libraries should be kept separate because everyone want's a different UI. Also, UI libraries are huge cans of worms. 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 -~----------~----~----~----~------~----~------~--~---