So first off I should clarify: I am NOT proposing this for inclusion
in MochiKit. This is just a random little tweak that I thought other
people might be interested in or might have experimented with
already. If I were proposing anything, it'd be more like a new
alternate optional library (but I'm just playing around/experimenting
at this point, so I'm not even doing that).
As for the syntax benefits, I agree that they are rather minimal
(which is why I don't think this belongs as a core part of MochiKit),
but I do think a couple meaningful ones exist:
1. Chainability: with this syntax you can chain functions do stuff
like:
someObject.update(updateObject1).update(updateObject2);
Or if you were to change which argument is replaced with "this", you
could do:
someArray.filter(filteringFunction1).filter(filteringFunction2);
Basically, whenever you're doing two MochiKit functions in a row that
expect the same type of argument #1, and one function gets called on
the other's result, you don't have to repeat the first argument to the
second function. If you make your own utility functions work this way
then you can chain them along with the MochiKit ones, further
increasing the potential value of this technique.
2. Expressiveness: this one's really subjective, but to me:
var a = someObject.update(updateObject1);
just looks better/is easier to read/is more natural than:
var a = update(someObject, updateObject1);
I guess it goes back to when I first started using MochiKit, and my
initial reaction was "this stuff is so awesome it should be a core
part of JavaScript". By adding this type of syntax, you're doing just
that: suddenly it's as if all the browser developers unanimously
agreed to make their browsers (and all their old versions of their
browser) support a new version of JavaScript which adds update as a
method of every object :-)
To be fair, I don't this syntax is better for everything. For
instance, I think:
counter(5);
looks more natural than:
5.counter();
Actually, come to think of it 5.counter() wouldn't even work (since 5
is scalar, it doesn't inherit object.prototype methods). But
hopefully you get the idea.
Anyhow, I'm not trying to suggest we radically depart from MochiKit's
core syntax. I'm just investigating whether I can get some added
benefit/utility/readability out of MochiKit by doing this little
"hack" (and if so perhaps others might be able to do the same).
Jeremy
On Jun 17, 1:35 am, "troels knak-nielsen" <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 17, 2008 at 6:23 AM, machineghost <[EMAIL PROTECTED]> wrote:
> > So before I waste a bunch of time trying to fix such issues, I thought
> > it might help to ask if anyone else had played around with this sort
> > of thing before. Or for that matter, is anyone actually using
> > anything like this? If so, I'd love to hear about your experience.
>
> > Jeremy
>
> It's almost the hallmark of MochiKit, that it _doesn't_ pollute the
> global namespace, like a lot of other libraries do. The problem in
> mocking around with core prototypes, is that you can break code that
> would otherwise work. Of course, you can't run Mochikit together with
> Prototype today either, but that's the fault of Prototype and not of
> Mochikit.
>
> Besides that, what's the benefit of writing thing the other way around
> anyway? Mochikit uses a function-oriented syntax, while jQuery use an
> object-oriented syntax. I find that this helps me to think
> function-oriented, rather than object-oriented, and generally I think
> that's a good thing.
>
> ( An interesting blog post about that topic
> exactly:http://michaelfeathers.typepad.com/michael_feathers_blog/2008/05/are-...
> )
>
> --
> troels
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
