Yes, a branch is the idea. Though a branch normally implies something in-repo, while a fork implies it being a project of it's own (even though it is continually integrating). I've thrown around the terms "fork branch" and "offsite branch" before, I guess the term use is just another case of my own messed up interpretation of terms (heh, ^_^ maybe this is why I have issues talking with other programmers, but I can get the layman to understand what I'm trying to put across about technical stuff).
I went off on a bit of a tangent later on (this was the bottom of the mail), Instead of sending it I added it to a wiki page: http://code.google.com/p/js4query/wiki/WhyGit Ya, I know there are more ambiguous points. I've been going through one by one, I've seen a few more "\\ save the old ???\n_???: jQuery.fn.???" lines in the code but not noted them yet. I'm only part way through on that part of the project. Nice point on the toggleVisibility name, I wouldn't have thought about that now. Since you pointed it out now, I can give it a better name without needing to rename it a second time later. Do you think .toggleDisplay is better? You noted it was the display being toggled, I'd also agree "Display" is easier to type than "Visibility". Other than that the only other one I can think of would be .showHide(...); Ya, I thought about those performance improvements to size as well. Right now all I'm doing is wrapping around the dimension function pairs, and I don't plan on doing much more changes than that in the code. Trying to add .size performance improvements into 4query would make it harder to merge jQuery updates in. That's why I like the idea of doing as much inside jQuery itself as possible, it reduces the complexity of continually merging, and lets the project work on the actual improvements it's trying to do. Oh, I didn't haven't listed it yet (that improvements page is far from complete) but if jQuery isn't adding it the .remove -> .destroy rename that was discussed earlier on in the list will probably go into 4query. Good documentation is nice, but an unfortunate fact is it's not exactly always read through. I was bitten by .remove once, and I understand the API fairly well. If someone understands the jQuery API fairly well from reading other documentation pages, they aren't likely to look at the documentation page for every single method they use when they already have an idea what it is /supposed/ to do. John, I should probably note it here. In 4query I'm using a init a little different than jQuery. jQuery( selector, [context] ); // jQuery $4( [context], selector, selector, ... ); // 4query At work the current framework I have setup effectively uses this technique. I know that using jQuery(context).find(selector).find(selector)... is pretty much the same thing, however idoms like pf(widgetObj, functionToBuildSectionSelector('foo'), '.fineGrainSelector'); are used extremely heavily. Using .find to push a selector onto a selector just takes a single selector chain just ends up bloating the code, and doesn't read very well (Technically also if it's stuck in a single method it is possible to potentially improve performance in the future). It kind of makes a little more sense as well, instead of having a selector with an optional node to it's right, you can read from left to right and see how each selector builds onto each other. I'm in no way suggesting making such a large change to the jQuery init, however I was wondering if you were open to a small modification to jQuery in the init. Right now I have two separate objects in 4query, a jQuery obj, and a 4query obj which inherits from it. This is done to separate any heavy renames done to 4query in case jQuery and 4query end up conflicting in part of the API (jQuery().someMethod can work perfectly fine while $4().someMethod has the incompatible improvement). Since you are interested in some of the 4query api changes going into jQuery and it looks like more collaboration is possible, if I can get a small modification to init into jQuery which will make selector/context order dependent on how init is called. Then I might be able to have 4query get away with nothing but a simple $49) function which will call .init in a slightly different way than jQuery(). Of course that meaning that the jQuery/4query object separation wouldn't be there either. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://nadir-seen-fire.com] -Nadir-Point & Wiki-Tools (http://nadir-point.com) (http://wiki-tools.com) -MonkeyScript (http://monkeyscript.org) -Animepedia (http://anime.wikia.com) -Narutopedia (http://naruto.wikia.com) -Soul Eater Wiki (http://souleater.wikia.com) John Resig wrote: > So a quick point: What you're talking about isn't a fork, it's a > branch (you track commits in a branch, you take the project in a new > direction with a fork). > > As far as your specific changes are concerned. > - I like .click(fn, fn) as an alternative to .toggle(fn, fn). > - I don't like .toggleVisibility - especially since you aren't > toggling the visibility, you're toggling the display of an element. > - I like your proposed API for size (.size, .innerSize, .outerSize) - > I'd imagine that it'd be able to speed up some code. > > One piece of ambiguity that you missed was .load() (.load(fn) and .load(url)). > > --John > > > > On Tue, Mar 3, 2009 at 3:47 AM, Daniel Friesen > <[email protected]> wrote: > >> I've mentioned my little fork project on the list a few times before, >> I've finally written a bit of a report on the goals in the project. I >> think it's probably missing some stuff, but it definitely explains a bit >> more. I never really noted how the project relates to the project at >> work, and there are more improvements and rationales to detail. But for >> now it's a good start. >> http://code.google.com/p/js4query/wiki/Report >> >> I'd appreciate it being looked over and commended on, especially by John >> since it would be nice to do as much of the goals and improvements as >> possible inside of jQuery itself instead of in a fork. >> >> Currently I think I got the trunk to a moderately usable point. Right >> now I was just merging updates from jQuery in and tr...@6256 made a bit >> of a conflict with the jQuery/4query object separation, so I'm merging >> it and will push those updates once I integrate the improvements together. >> >> -- >> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery Development" 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/jquery-dev?hl=en -~----------~----~----~----~------~----~------~--~---
