[mochikit] Re: Class inheritance
A far more effective method for this I think is just to do protype
inheritance the way javascript is designed.
other.prototype = Helper;
no looping over accessors and trying to figure out if you already have this
method or accessor in your object.
I had never really thought of MochiKit as an OO helper library. The joose
project is probably closer to what you are looking for in a class helper:
http://code.google.com/p/joose-js/
MochiKit I think has different goals.
Disclaimer:
I am an occasional contributer to the joose project.
On Mon, Oct 6, 2008 at 10:40 AM, Akari no ryu [EMAIL PROTECTED]wrote:
Ok, I've searched through the archives for posts referencing the word
inheritance but most of them are just referring to prototype and the
lack of scope that JS gives you if you don't bindMethods(this)
I'm asking about actual OO inheritance in this post, wherein a class
inherits methods from another class.
I've also tried google but that was utterly useless. Gave me
suggestions for code which doesn't work when you're using MochiKit,
because of the bindMethods function.
I've added a bequeathTo method to my helper class which does the
following
Helper.prototype.bequeathTo = function(other)
{
for(var i in this)
{
other[i] = MochiKit.base.bind(this[i], other)
}
}
That works.
It's been tested and implemented in two classes that inheret methods
from it.
I'll upload my code for linkage later.
I don't know if all y'all want to implement this but I though I'd post
just in case.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[mochikit] Re: Selector speedup by using John Resig's Sizzle
Hi all, On Tue, Oct 7, 2008 at 06:21, JasonBunting [EMAIL PROTECTED] wrote: Any update on this? According to slide 92 of John Resig's recent JavaScript Library Overview slides from Ajax Experience '08 (http://www.slideshare.net/jeresig/javascript-library-overview- presentation/), this is being integrated into MochiKit. Sorry, a sudden onslaught of thesis work has been keeping me busy. I was just thinking about this last night though. I can upload a patch for review tonight. There are two main problems, both of which might be considered acceptable: 1. A few existing unit-tests for Mochikit.Selector fail, because Sizzle doesn't support some (rarely used) selectors. The list of failed tests is earlier in this thread. 2. The global name space is polluted a bit. If someone is willing to review the patch and either make suggestions how to fix these, or if the ML is ok with both problems - then I can commit it. 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 -~--~~~~--~~--~--~---
[mochikit] Re: Class inheritance
I never used `bindMethods`. I can see why a Pythonista might find it
intuitive, but quite frankly, it's reveals a fundamental
misunderstanding of the language being used. Javascript does not have
classes, and trying to emulate them is going to be a very leaky
abstraction. You would be much better off using the features that the
language supports (prototypical inheritance). Maybe the documentation
should include a note about this, under `bindMethods`?
--
troels
On Mon, Oct 6, 2008 at 5:40 PM, Akari no ryu [EMAIL PROTECTED] wrote:
Ok, I've searched through the archives for posts referencing the word
inheritance but most of them are just referring to prototype and the
lack of scope that JS gives you if you don't bindMethods(this)
I'm asking about actual OO inheritance in this post, wherein a class
inherits methods from another class.
I've also tried google but that was utterly useless. Gave me
suggestions for code which doesn't work when you're using MochiKit,
because of the bindMethods function.
I've added a bequeathTo method to my helper class which does the
following
Helper.prototype.bequeathTo = function(other)
{
for(var i in this)
{
other[i] = MochiKit.base.bind(this[i], other)
}
}
That works.
It's been tested and implemented in two classes that inheret methods
from it.
I'll upload my code for linkage later.
I don't know if all y'all want to implement this but I though I'd post
just in case.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[mochikit] Re: Selector speedup by using John Resig's Sizzle
On Oct 7, 1:49 pm, Arnar Birgisson [EMAIL PROTECTED] wrote: To be clear, I'm basically asking the mailing list: Would you be OK with it if the following selectors would stop working? a[fakeattribute] - i.e. checking for presence of attribute p[lang|=en] - membership test of hyphen-seperated string collections :nth-of-type(...) pseudo-class :enabled, :disabled and :checked pseudo-classes :root pseudo-class My votes... Drop these (not in jQuery, so may be not supported by Sizzle): 1) p[lang|=en] 2) :nth-of-type(...) Rename this: 1) :root to :first Should be there: 1) a[fakeattribute] 2) :enabled 3) :disabled 4) :checked 5) ... more form selectors (see jQuery doc) Regards -- Amit Mendapara --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[mochikit] Re: Selector speedup by using John Resig's Sizzle
On Tue, Oct 7, 2008 at 19:09, Jason Bunting [EMAIL PROTECTED] wrote: Arnar Birgisson wrote: To be clear, I'm basically asking the mailing list: Would you be OK with it if the following selectors would stop working? a[fakeattribute] - i.e. checking for presence of attribute p[lang|=en] - membership test of hyphen-seperated string collections :nth-of-type(...) pseudo-class :enabled, :disabled and :checked pseudo-classes :root pseudo-class Sounds good to me - would it be too hard to hook into Sizzle and add these ourselves so that the tests pass? I don't know squat about the current code and what is involved in doing this; would it be much work? I intend to find out tonight :) 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 -~--~~~~--~~--~--~---
[mochikit] Re: Selector speedup by using John Resig's Sizzle
Arnar Birgisson wrote: To be clear, I'm basically asking the mailing list: Would you be OK with it if the following selectors would stop working? a[fakeattribute] - i.e. checking for presence of attribute p[lang|=en] - membership test of hyphen-seperated string collections :nth-of-type(...) pseudo-class :enabled, :disabled and :checked pseudo-classes :root pseudo-class Sounds good to me - would it be too hard to hook into Sizzle and add these ourselves so that the tests pass? I don't know squat about the current code and what is involved in doing this; would it be much work? Jason --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[mochikit] Re: Selector speedup by using John Resig's Sizzle
Hey all, Experimental version ready in seperate branch, see below. On Tue, Oct 7, 2008 at 19:11, Arnar Birgisson [EMAIL PROTECTED] wrote: Sounds good to me - would it be too hard to hook into Sizzle and add these ourselves so that the tests pass? I don't know squat about the current code and what is involved in doing this; would it be much work? I intend to find out tonight :) As it turns out, most of these were easy to implement. Sizzle actually pulls some implementation from jQuery if it is available. I copied and adapted the relevant parts from jQuery (which is also MIT licensed). Sizzle had a few bugs (or at least incorrect behaviour imo) which were easy to fix, among those was support for the |= selector. I created a branch called selector_sizzle [1] and committed this there, ready for review - with the following notes: [1] http://svn.mochikit.com/mochikit/branches/selector_sizzle 1. All unit tests pass in FF except those for three types of selectors. As they were stopping the test suite I had to comment them out. The three selector types that do not work are: - :nth-of-type(...) This one is not supported by Sizzle, and it is not straight forward to do so. I think we should just accept that, they are CSS3 features and probably not used a lot. - a[someattribute] Now this is quite common, and I think that it is the intention of Sizzle to support this. However, the implementation is broken - I couldn't figure out what was wrong so I emailed John about it, I'm currently waiting for a reply. If nothing else, MochiKit should thus lead to one bugfix in Sizzle. :) My opinion here is to wait for John, either he fixes it or helps me to do it. - :root This selector is also from CSS3 and is not supported by Sizzle. I think it is possible, I tried adding support for it but it didn't work out too nicely. This has to do with the fact that Sizzle assumes one is working with document (the main doc) but MochiKit.Selector, and thus the unit test for :root, tries to use this on other documents with the functionality in MochiKit.DOM (withDocument, currentDocument etc.). My opinion is that we should simply skip this as well. 2. The change in the branch introduces a few global names. Namely: chunker, cache, Sizzle, Expr, makeArray, dir, dirNode, dirCheck. This is a bit messy since many of these names are non-distinct and could be used by users or other libraries. We should probably enclose them somehow in the MochiKit.Selector namespace. However, I will suggest to John that Sizzle only binds one global name (Sizzle) and tucks the others away in that namespace. Some unit tests fail on Safari, will have to look at that tomorrow (unless someone else wants to give it a go). Please run the unit tests on other platforms and browsers as I only have access to FF3 and Safari 3. My speed measures, using the SlickSpeed framework, indicate a 55x speedup - going from 3.9 sec with the old Selector module to 71 ms for the new Sizzle based one. The SlickSpeed benchmark tests many selectors, but far from all of them (i.e. it does not has enough coverage to be a unit test). Please run the benchmark on your browser if you like, just visit [2] and everything should be set up already. [2] http://www.hvergi.net/arnar/public/sizzle/speed/# So.. please try this out and comment. What changes do you think are necessary (if any), including my suggestions above, before comitting this to trunk? 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 -~--~~~~--~~--~--~---
