On Thu, Oct 22, 2009 at 00:18, Bret Pettichord <[email protected]> wrote:
> On Sat, Oct 10, 2009 at 6:58 PM, Ethan <[email protected]> wrote: > >> On Sat, Oct 10, 2009 at 18:35, Bret Pettichord <[email protected]>wrote: >> >>> >>> On Sat, Oct 10, 2009 at 4:20 PM, Ethan <[email protected]> wrote: >>> >>>> >>>> I considered putting them in their own namespaces but I decided that >>>> would be too confusing. Say you have >>>> >>>> - Watir::TextField for common >>>> - Watir::IE::TextField >>>> - Watir::Firefox::TextField >>>> >>>> I think it would get confusing when you are in, say, the Watir::Firefox >>>> namespace, whether an unprefixed TextField is meant to refer to the common >>>> one or the firefox one. >>>> >>> > I'm not too worried about this. We can always use this syntax for > references to avoid any possible misunderstanding: > > ::Watir::Textfield > ::Watir::IE::Textfield > > and just agree not to have unprefixed TextField in our source. > > > >> Maybe >>>> >>>> - Watir::Common::TextField >>>> - Watir::IE::TextField >>>> - Watir::Firefox::Textfield >>>> >>>> I like this. >>> >>> BTW, this is a big change and really needs to be discussed in the context >>> of how we want to structure Watir 2.0. >>> >>> >>>> so that in any namespace you have to prefix the other's namespace. But >>>> that would break everything that checks stuff like >>>> foo.is_a?(Watir::TextField) - I named the common one after the existing IE >>>> one so that that would still work. (it still breaks backwards compatibility >>>> if code uses foo.class==Watir::TextField, but is_a? is generally >>>> recommended, so I figured this would be acceptable.) >>>> >>> > This is a good argument for using Watir::TextField instead of > Watir::Common::TextField > > >> >>>> Another possibility is >>>> >>>> - Watir::TextField for common >>>> - IEWatir::TextField >>>> - FireWatir::TextField >>>> >>>> But I figured having separate browser-specific class names in one >>>> namespace was preferable to having identical class names in >>>> browser-specific >>>> namespaces. >>>> >>> > I agree with this point > > >> I don't know which one of those I prefer, they all have their pros and >> cons. I am inclined toward one of the first two, as breaking existing >> foo.is_a?(Watir::TextField) seems like a bigger negative than having >> different names (FFTextField and TextField) or ambiguity in some namespace. >> > > I think i agree that not breaking x.is_a? is a good idea. (Not sure at this > point whether I'm agreeing with myself or not.) > > >> • Watir::TextField >> • Watir::IETextField >> • Watir::FFTextField >> all in the same top namespace, no ambiguity referring to TextField, but >> prefixes mean class-specific ones aren't consistently named TextField. >> >> >> • Watir::TextField >> • Watir::IE::TextField >> • Watir::Firefox::TextField >> all in the same top namespace, all consistently named TextField, but >> ambiguous in browser namespace. >> > > So now i am leaning towards this one. > > >> • Watir::Common::TextField >> • Watir::IE::TextField >> • Watir::Firefox::Textfield >> all in the same top namespace, consistent names, no ambiguity, but breaks >> existing code checking for Watir::TextField. >> Bret Pettichord says: I like this. >> >> >> • Watir::TextField for common >> • IEWatir::TextField >> • FireWatir::TextField >> different top-level namespace, so no ambiguity, all consistently named >> TextField. >> >> > I think i would like get this restructuring in for 1.7.0, along with some > restructuring of how things are broken into gems. (Actually, i think i would > like to start using git submodules: can someone recommend a place for me to > learn how to use them?) > > Bret > > Okay, sounds good to me - I'm on board with • Watir::TextField • Watir::IE::TextField • Watir::Firefox::TextField Ethan
_______________________________________________ Wtr-development mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-development
