Have jQuery.type return "jQuery" for jQuery objects

[T.J. Crowder]

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.

[T.J. Crowder]

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

[snover]

Bikeshed/feature creep. Marking for review.

[T.J. Crowder]

Replying to snover:

Bikeshed/feature creep. Marking for review.

Not all refinement suggestions are bikeshedding.

[snover]

Retarget all enhancements/features to next major version.

[dmethvin]

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.

[dmethvin]

Related to #7200 .

[Rick Waldron]

#7815 is a duplicate of this ticket.

[Rick Waldron]

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

[snover]

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.

[T.J. Crowder]

Replying to 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)?

[dmethvin]

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.

[T.J. Crowder]

Replying to 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.

[Rick Waldron]

Bikeshedding.

[kswedberg]

documentation was added 2/11/2011