MochiQuery

[machineghost]

After looking at jQuery recently, I became interested in the idea of
adding core object prototype functions. Imagine if, instead of the
normal MochiKit syntax, you could do:

var a = someObject.clone(); // var a = clone(someObject);
var b = [].isArrayLike(); // var b = isArrayLike([]);
var c = someFunction.partial("arg1"); // var c = partial(someFunction,
"arg1");

Basically, all you need to do is add every MochiKit.Base function as a
method of object.prototype, while at the same time pre-pending "this"
as the first argument. Here's some (relatively untested) code I wrote
to do just that:

var objectMethodExportList = clone(MochiKit.Base.EXPORT);
// Exclude concat to avoid conflict with Array.concat
objectMethodExportList.splice(findIdentical(MochiKit.Base.EXPORT,
"concat"),1);
forEach(objectMethodExportList, function(x) {
Object.prototype[x] = function() {
return MochiKit.Base[x].apply(this, extend([this], arguments));
};
});

You could do the same thing with the DOM library and
Element.prototype, and various other Mochikit functions as well (eg.
"var a =A(); a.connect("onclick", someFunction);").

However, even just my initial tests showed some obvious problems. For
instance, consider
the keys function: it will return a ton of new properties (because
methods are properties in JavaScript) on any object you pass to it.

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

[Jason Bunting]

I am just curious as to the motivation for this; other than an extra dot, I
don't see much of a difference between:

var a = someObject.clone();

and

var a = clone(someObject);

Is it merely because you think it makes more semantic sense or . . . ? I
don't know why we would want to add more complexity to the code base for
something that isn't really giving us anything more. Please tell me what I
am missing, because I am sure there is something (it's late and my brain
doesn't function that well at this time of the morning).

Jason Bunting

> No virus found in this incoming message.
> Checked by AVG.
> Version: 8.0.100 / Virus Database: 270.3.0/1505 - Release Date: 6/16/2008
> 7:20 AM

[troels knak-nielsen]

On Tue, Jun 17, 2008 at 6:23 AM, machineghost <machin...@gmail.com> 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-fp-and-oo-i.html
)

--
troels

[machineghost]

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" <troel...@gmail.com> wrote:

> ( An interesting blog post about that topic exactly:http://michaelfeathers.typepad.com/michael_feathers_blog/2008/05/are-...
> )
>
> --
> troels

[troels knak-nielsen]

On Tue, Jun 17, 2008 at 5:07 PM, machineghost <machin...@gmail.com> wrote:
> 1. Chainability: with this syntax you can chain functions do stuff
> like:
> someObject.update(updateObject1).update(updateObject2);

True, that _is_ something that can't be done with function-oriented
syntax. Personally, I'm not that found of this "fluent interfaces"
style; I think it works fine for simple cases, but lose it's punch
when things get more complex. Plus it can get a bit unintuitive, when
taken out of context. But I understand, that some people like it.

The way jQuery's api works, should make it possible to provide some of
these things without messing with built-in prototypes, I reckon? You
could simply return wrapper objects, which have the methods available?
I don't even remember if jQuery does this?

On Tue, Jun 17, 2008 at 5:07 PM, machineghost <machin...@gmail.com> wrote:
>
> 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.

It works. 5 is a scalar, but it's automagically wrapped in an object,
when used as such.

--
troels

[Per Cederberg]

I haven't tried jQuery, but l find myself browsing through the
Prototype API:s from time to time. And as far as I can see, it seems
to provide much the same functionality like MochiKit, but with an
object-oriented syntax and approach (extending built-in object
prototypes with stuff that should have been there from the start).

If you like that style of programming, I think you'd be better off
using one of these other libraries instead of MochiKit. At least their
mailing list wouldn't be hostile to the basic idea of modifying
built-in prototypes. ;-)

But I'm all for collaboration, cross-library compatibility and a free
exchange of ideas and code between these (quite similar) JavaScript
projects. If there is some clever way of bridging the gap or reusing
code I think it is worth having a look at. If only to allow
MochiKit-based code to run in environments where jQuery or Prototype
are already entrenched.

Question: Is mocking with the built-in object prototypes compatible with JS 2.0?

Cheers,

/Per