Skip to main content

Bug Tracker

Side navigation

#7224 closed enhancement (wontfix)

Opened October 17, 2010 10:08AM UTC

Closed December 30, 2010 03:34PM UTC

Last modified March 28, 2011 02:14PM UTC

Have jQuery.type return "jQuery" for jQuery objects

Reported by: T.J. Crowder Owned by: rwaldron
Priority: low Milestone: 1.5
Component: core Version: 1.4.3
Keywords: needsreview Cc:
Blocked by: Blocking:
Description

The new jQuery.type function is great! Would like to see an enhancement to it: Return "jQuery" for jQuery instances. This comes out of this question on StackOverflow, in which the OP wanted to know how to reliably tell whether a given object was a jQuery instance or not. Nick Craver suggested looking for whether it has a .jquery property on it, but as that property is undocumented, I lean away from it. jQuery.type seems like an excellent way to document a means of doing this test.

Attachments (0)
Change History (19)

Changed October 17, 2010 10:10AM UTC by T.J. Crowder comment:1

See also ticket #7200, which is a ticket Nick created for documenting the .jquery property.

Changed October 18, 2010 10:23PM UTC by snover comment:2

keywords: → needsreview

Bikeshed/feature creep. Marking for review.

Changed October 19, 2010 12:11AM UTC by T.J. Crowder comment:3

Replying to [comment:2 snover]:

Bikeshed/feature creep. Marking for review.

Not all refinement suggestions are bikeshedding.

Changed October 19, 2010 01:07AM UTC by snover comment:4

milestone: 1.4.41.5

Retarget all enhancements/features to next major version.

Changed October 22, 2010 06:01PM UTC by rwaldron comment:5

component: unfiledcore
priority: undecidedlow

Changed November 20, 2010 03:46AM UTC by dmethvin comment:6

keywords: needsreviewneedsreview needsdocs

Core currently uses .jquery in a few places, so perhaps we should document it since it's been that way for years? If it makes sense to distinguish a jQuery object in jQuery.type great.

Changed November 21, 2010 02:15AM UTC by dmethvin comment:7

Related to #7200 .

Changed November 21, 2010 02:15AM UTC by dmethvin comment:8

status: newopen

Changed December 21, 2010 06:18PM UTC by rwaldron comment:9

#7815 is a duplicate of this ticket.

Changed December 27, 2010 08:45PM UTC by rwaldron comment:10

owner: → rwaldron
status: openassigned

Changed December 28, 2010 04:37PM UTC by rwaldron comment:11

Adds a condition to jQuery.type that checks for the existence of a jquery property on the object being tested, and whether or not that property's value is the same as jQuery.fn.jquery (helps avoid false positives)

https://github.com/jquery/jquery/pull/151

Changed December 30, 2010 01:48AM UTC by snover comment:12

_comment0: I still don’t see any reason for this. If someone wants to know if an object is a jQuery object, the standard mechanism for performing such a test is to inspect whether or not a jquery property exists, and that’s not likely to change any time soon since it is used very heavily internally and has been promoted as the de facto mechanism for testing. \ \ Making this change only guarantees that people will end up assuming that its return value is a guarantee, when internally we are just doing the exact same thing. Additionally, this mechanism is intended only to expose the class type of JavaScript natives, not user-created classes, and I think it’s a dangerous road to go down by embellishing it with special magic for jQuery.1293673725362662

I still don’t see any reason for this. If someone wants to know if an object is a jQuery object, the standard mechanism for performing such a test is to inspect whether or not a jquery property exists, and that’s not likely to change any time soon since it is used very heavily internally and has been promoted as the de facto mechanism for testing.

Making this change only guarantees that people will end up assuming that its return value is a guarantee, when internally we are just doing the exact same thing. Additionally, this mechanism is intended only to expose the class type of JavaScript natives, not user-created classes, and I think it’s at worst dangerous, at best needless to embellish it with special magic for jQuery just because we can.

Changed December 30, 2010 02:44PM UTC by rwaldron comment:13

resolution: → worksforme
status: assignedclosed

Changed December 30, 2010 02:58PM UTC by T.J. Crowder comment:14

Replying to [comment:13 rwaldron]:

I don't know much about Trac, but I'm not following "worksforme". Did you mean "wontfix" (in deference to @snover's view)? Or "fixed" (by your pull request)?

Changed December 30, 2010 03:09PM UTC by dmethvin comment:15

I think the "worksforme" here is intended to mean that there is a good solution available (check for the .jquery property) so we don't need to add anything to .type().

Like snover said, .type() currently returns Javascript types. Also, like many utility functions in jQuery it was created for an internal core code need. Core doesn't get any benefit from this addition.

We still need to document the .jquery property per #7200.

Changed December 30, 2010 03:19PM UTC by T.J. Crowder comment:16

Replying to [comment:15 dmethvin]:

I think the "worksforme" here is intended to mean that there is a good solution available...

Okay. To me it's a "wontfix". The thing doesn't do what was requested; "worksforme" in every bug tracker I've dealt with means, basically, the report was erroneous or we haven't managed to replicate it. Doesn't really matter, but seems odd.

Agreed about #7200, easy enough to create one's own type knowing that that's not going to disappear.

Changed December 30, 2010 03:33PM UTC by rwaldron comment:17

resolution: worksforme
status: closedreopened

Changed December 30, 2010 03:34PM UTC by rwaldron comment:18

resolution: → wontfix
status: reopenedclosed

Bikeshedding.

Changed March 28, 2011 02:14PM UTC by kswedberg comment:19

keywords: needsreview needsdocsneedsreview

documentation was added 2/11/2011