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.
