It seems to me that the reason the Vapir forks exists is because Ethan has valued a consistent, logical API over compatible support for legacy users and testsuites whereas the Watir team has been extremely reluctant to disrupt legacy users even if that means that our API is less consistent from a strictly engineering perspective.
Another way of saying this is that we don't really treat technical inconsistency (which can often create complications for Watir developers) as a problem until users complain about the inconsistency. A good example of this is zero-based indexing, which many users have complained about. Another Watir principle has been to try to present an API that maps to casual user's models of a web page, even if that means that it doesn't exactly map to the DOM. For example, there are several ways to include buttons in HTML. Watir provides a single API to any of them, where as more DOM-focused tools (e.g. Hpricot) require users to be more technically accurate. Bret On Fri, Sep 10, 2010 at 10:27 AM, Ethan <[email protected]> wrote: > It is true that you can have the second part without the first, indeed, I > already have the second part without the first (as does watir-webdriver), > and thinking about that led me to consider deprecating :index. > > True, it will annoy people, but that's always true with API changes - just > a question of whether the benefits outweigh the annoyance. I think you end > up with a better API (specifying index as a subscript is more ruby-like and > doesn't conflate :index with other attributes), and cleaner backend code. I > think it's worth it. But, this is sort of far out thinking, along the lines > of deprecating 1-indexing - I wouldn't plan on dropping support for quite > some time, not until the next major version, at some point significantly in > the future. > > > On Fri, Sep 10, 2010 at 09:50, Alan Baird <[email protected]> wrote: > >> My .02 - >> >> The first part of the proposal, deprecating :index, is >> an unnecessary reduction in functionality and breaks backwards >> compatibility. It would be a pain to update. >> >> The second part of the proposal, adding locators to collections, would be >> a cool feature to have. Of course, you can always use Ruby's select or >> reject iterator to accomplish this, it's just more wordy. >> >> I don't see what deprecating this usage gets you other than annoying >> Watir's users. Seems like you could do the 2nd part without the first. >> >> Alan >> >> _______________________________________________ >> Wtr-development mailing list >> [email protected] >> http://rubyforge.org/mailman/listinfo/wtr-development >> > > > _______________________________________________ > Wtr-development mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord
_______________________________________________ Wtr-development mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-development
