Hi guys, I like #1 as well. It has come up on Celerity's tracker before
http://github.com/jarib/celerity/issues#issue/7 I don't think it will be a huge backwards compatibility issue since the current behaviour is to raise an ArgumentError. On Fri, May 7, 2010 at 7:04 PM, Jarmo <[email protected]> wrote: > How do you see that #1 will cause compatibility problems? Do you mean > 0-based indexing? This is done anyway already with Watir WebDriver > (http://wiki.github.com/jarib/watir-webdriver/comparison-with-watir-1x) > and i think that it is a really good thing. If you have that in mind, > then default :index => won't bring any backwards compatibilities. > Just to be clear: watir-webdriver implements 0-based indexing, but it does not return the first element when calling an element method without arguments > >>> >>> And with the possibility (from Google Wave about Watir 2.0 by Jari) to >>> use locators for collections: >>> product = b.table(:id => "table_id").trs(:text => "Something else").first >>> product.link.click >> >> Definitely. This is a priority for me in my fork. > This is already done in Watir WebDriver. > No, watir-webdriver does not do this (yet). divs(:id => "foo") will return all divs, not only those matching the argument. It's a bug. I'm not a big fan of #2 - the default "hows" in 1.X were confusing enough, and they're gone in watir-webdriver. Limiting it to id would help somewhat, but I do like the selectors to be explicit. Another argument is that migration will be easier if the single-argument syntax raises an ArgumentError rather than an UnknownObjectException. #3 was discussed in the "Watir Roadmap" wave, copied here: >> Obsoleting non-hash syntax. >> Nov 16, 2009 >> >> Bret: >> For example, I'm thinking that Watir 2.0 should only support hash syntax. >> Thus: browser.text_field(:id => 'name').set 'Grayson' will continue to work, >> but browser.text_field(:id, 'name').set 'Grayson' won't. I haven't made up >> my mind on this, and am eager for feedback, but I want to give you a >> picture, right now of the kind of disruptions I'm anticipating for Watir 2.0. >> Nov 17, 2009 >> >> [email protected]: >> Any specific reason for going ahead with hash syntax? I am sure that it will >> break a lot of stuff >> Nov 17, 2009 >> >> Deniz: >> I agree on this, I recall this discussion but there was no conclusion. I >> also vote for staying compatible with the old syntax, using only hash will >> break a lot of stuff and confuse a lot of people. >> Nov 17, 2009 >> >> Bret: >> I can back off on this. Mainly, my thinking is that simplifying the api >> makes it easier to create implementations. >> I don't really have a strong opinion either way, but this change does break backwards compatiblity for miniscule benefits. The implementation argument is somewhat weak, since it's very easy to get right: if args.size == 2 args = { args.first => args.last } end My vote is #1: +1 #2: -1 #3: 0 Jari PS. While we're on the topic; there are two other APIs that needs discussion: tables and cookies. I'll bring them up in separate threads when I've had time to create some sensible proposals. _______________________________________________ Wtr-development mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-development
