From: Joel VanderWerf Date: 2001-12-05T16:32:22+09:00 Subject: [ruby-talk:27529] Re: Package Naming Dave Thomas wrote: > > nobu.nokada@softhome.net writes: > > > At Wed, 5 Dec 2001 14:12:14 +0900, > > Hal E. Fulton wrote: > > > module X::Y::Z > > > > > > I am saying that Z is a module, regardless > > > of whether X and Y are classes or modules. > > > > Yes, but I think there must be preceding X and X::Y > > definitions, or it should cause NameError. > > I _think_ my preference would be to assume that any undefined > constants are always Modules, and then to raise a name error > subsequently if this turns out not to be the case. Then, for consistency, should def X::foo; end define X as a module, if it's undefined? In any case, I'm not crazy about implicit definitions that might or might not conflict with later definitions. Why not force the programmer to be explicit about the class/module choice? What if 'module X::Y::Z' occurred without definitions of X and X::Y in a library that I published? Let's say one programmer who uses my library has already defined X and X::Y as classes. Then he writes code that loads in my stuff and instantiates class X::Y. Another has already defined them as modules. Her program has an 'include X::Y'. Their code is incompatible (that's their fault), but neither of them has been notified of any problem, which is the fault of my library. Is this extra level of dynamism worth something, or is it just an opening for bad style? -- Joel VanderWerf California PATH, UC Berkeley mailto:vjoel@path.berkeley.edu Ph. (510) 231-9446 http://www.path.berkeley.edu FAX (510) 231-9512