This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23586 - Naming conflict for query
Summary: Naming conflict for query
Status: RESOLVED FIXED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: URL (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: Unsorted
Assignee: Anne
QA Contact: sideshowbarker+urlspec
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-21 18:35 UTC by Erik Arvidsson
Modified: 2013-11-01 17:32 UTC (History)
6 users (show)

See Also:

Attachments

Description Erik Arvidsson 2013-10-21 18:35:03 UTC 
Both http://dom.spec.whatwg.org/#parentnode and http://url.spec.whatwg.org/#api defines a property named query.
Comment 1 Anne 2013-10-22 10:21:22 UTC 
Wow, even with the same author we get clashes. Sad times.

I'm not sure which one to rename.

Should we go for searchObj and URLSearch?
Comment 2 Erik Arvidsson 2013-10-22 20:17:24 UTC 
Maybe name the property urlQuery?

Another option is to not have a URL query property on HTMLAnchorElement nor HTMLTextAreaElement.
Comment 3 Domenic Denicola 2013-10-22 21:45:12 UTC 
I am starting to like queryParams or queryPairs. (Or searchParams/searchPairs.)
Comment 4 brian kardell 2013-10-22 21:50:16 UTC 
(In reply to Domenic Denicola from comment #3)
> I am starting to like queryParams or queryPairs. (Or
> searchParams/searchPairs.)

+1 queryParams ... intuitive, been used before in other languages/frameworks/documentation and still fairly short.
Comment 5 Erik Arvidsson 2013-10-22 22:02:35 UTC 
I'm also fine with queryParams.

Should we rename URLQuery to QueryParams as well?
Comment 6 Anne 2013-10-23 10:43:41 UTC 
Where has queryParams been used before? And yeah, if we go with that we should probably rename the interface.
Comment 7 brian kardell 2013-10-23 12:49:25 UTC 
(In reply to Anne from comment #6)
> Where has queryParams been used before? And yeah, if we go with that we
> should probably rename the interface.

Seems to be pretty common parlance among devs to me - i see it in code frequently in several languages.

some google searches show examples supporting...

https://www.google.com/search? q=%E2%80%9Dqueryparams%E2%80%9D

https://www.google.com/search? q=%E2%80%9Dqueryparams%E2%80% 9D+querystring

https://www.google.com/search? q=%E2%80%9Dqueryparams%E2%80%9D+url
Comment 8 Anne 2013-11-01 15:33:09 UTC 
I'm still a bit torn. If we cannot use the actual proper term I think I somewhat prefer consistency with the existing API and either use searchObj or searchParams.

I'm happy to be overruled though, it's not a big deal.
Comment 9 brian kardell 2013-11-01 15:52:35 UTC 
(In reply to Anne from comment #8)
> I'm still a bit torn. If we cannot use the actual proper term I think I
> somewhat prefer consistency with the existing API and either use searchObj
> or searchParams.
> 
> I'm happy to be overruled though, it's not a big deal.


searchParams isn't so bad... where is that more consistent though?  

non-sequitur complaint on the platform in general: I hate that we have so many properties that begin with a potential verb and therefore seem like they might be a method.  Seems kinda bad because it blocks a potentially useful method name and leaves us in situations picking a less than ideal name.  Don't really see a great solution here for that, just mentioning that it bothers me :)
Comment 10 Anne 2013-11-01 16:01:54 UTC 
So my thinking is that either we have the short good name query and ignore search exists. Or we embrace that search exists and offer a classList-like companion. searchObj mostly stems from HTMLMediaElement src / srcObj (although they might name it srcObject).
Comment 11 Erik Arvidsson 2013-11-01 16:59:14 UTC 
(In reply to Anne from comment #10)
> So my thinking is that either we have the short good name query and ignore
> search exists. Or we embrace that search exists and offer a classList-like
> companion. searchObj mostly stems from HTMLMediaElement src / srcObj
> (although they might name it srcObject).

I'm fine with searchObject but not with searchObj. We should not name things "obj". obj is fine for local variable names etc but we should not promote obj, doc, el, evt etc to APIs.

Other options include

{search,query}{List,Map,Object,Params}
Comment 12 Anne 2013-11-01 17:09:58 UTC 
Are you aware of srcdoc?

Anyway, I am cool with searchParams with as object URLSearchParams.