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 [email protected]
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
-~----------~----~----~----~------~----~------~--~---
