Congratulations!
On 9/11/07, Stephan Beal <[EMAIL PROTECTED]> wrote:
>
>
> On Sep 11, 11:18 pm, "John Resig" <[EMAIL PROTECTED]> wrote:
> > Only using shallow copy? You're definitely in a very, very, small
> > minority, then. What are the use cases for shallow copying a large DOM
> > structure, that has a ton of child elements?
>
> Shallow copying is useful, e.g., when copying images. Granted,
> however, that a deep copy is just as cheap for images because they
> don't have child elements. In my boardgaming interface i use(d)
> shallow clones to copy playing pieces from the "piece tray" to the
> game board.
>
> > Because we want to move away from one-use specialty methods. arguing
> > against the removal would be the same as arguing for the inclusion of
> > getIfNotCached or getSynchronous.
>
> Fair enough.
>
> > I'm confused about your complaint of file size, as well - we're
> > literally talking about the difference between:
> > $.get("url") and
> > $.ajax({url: "url", ifModified: true});
>
> i was assuming that the convenience funcs were removed to save a few
> bytes in the (growing) core. Under that assumption, the extra bytes
> simply moved from the core into the client code. Your justification
> for removing the convenience funcs goes deeper than saving a few bytes
> in the core, though, so my assumption was incomplete/incorrect.
>
> > > 3) eq()/lt()/gt() are dead. Long live eq()/lt()/gt(). Again, the
> ...
> > You don't have to hang on the dev list to be in tune with what's
> > happening. These changes were put up on the wiki back in mid-June:
> http://docs.jquery.com/JQuery_1.2_Roadmap
>
> i was aware they were going away, just not clear about exactly why
> they are going away (other than "because you can do the same thing
> with slice [by typing a bit more]").
>
> > That being said, those method - 3 of them - were specialty methods
> > that were only capable of performing one task - and they weren't
> > terribly good at it either, as they had to interact with the selector
> > engine in order to use it (which is, comparably, quite slow). Slice is
> > a couple things: 1) Faster. 2) Uses an existing idiom, making it
> > easier to use and learn. 3) More Powerful. 4) A reduction of the API.
>
> All fair enough points, though i would argue that greater-than and
> less-than are more commonly used idioms than slice. Since those
> functions are all "long-timers" in the API, wouldn't it make sense to
> keep them and reimplement them in terms of slice()? Of the 7 plugins
> i've published, only one of them is incompatible between 1.1 and 1.2,
> and only because lt() and gt() went away. Were it not for that, i
> wouldn't have had to edit any code to accommodate both 1.1 and 1.2.
> (OTOH, the fact that only 1 of 7 plugins uses gt/lt may indicate that
> those funcs are relatively seldom used.)
>
> With the coming of slice(), there is now a greater discrepancy between
> the functional API and the selectors, because there is no longer a
> symmetry between $("x").gt(2) and $("x:gt(2)"), like there was before.
> Now it's $("x:gt(2)") vs $("x").slice(3). The "off by one" in the
> slice() forces me to stop and think every time i see it.
>
>
> > No, "evalScripts" only occurs when when HTML is injected into the DOM
> > - so if you load HTML from a remote page, the scripts contained in the
> > HTML won't be executed until the HTML is actually inserted into the
> > document.
>
> Excellent :). Thanks for that clarification.
>
>
>
