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 -- 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
