Hi -- On Fri, 26 Sep 2003, Thomas Sondergaard wrote: > I am working on an article on the subject of implementing dynamically typed > languages on the .net CLR. In .net Types are immutable, ie. once defined > they cannot be changed. Writing about this I needed to cover the problem of > namespace collisions. Most modern languages including ruby has introduced > namespaces to alleviate the namespace collision problem, but the convention > of adding your own methods to existing classes reintroduces the problem. > > Is ruby merely being pragmatic by allowing you to do this, because it seldom > causes any real problems? Or is it inherently wrong and should not be > permitted by the language/object model? > > How do you feel about this feature. Would it be a big loss if ruby didn't > support it? My own feelings are ambivalent. I have found myself adding > features to Time, Enumerable, Module and when I do it I always appreciate > how nice it is that the feature is where it belongs, but I always have this > nagging fear of collisions that I push to the back of my mind. There's been debate on the merits (or otherwise) of changing core classes; see for example http://www.ruby-talk.org/81923 (Paul Brannan) for some reflections on this. But if I'm reading your question correctly, you're asking generally about the language design which allows dynamic modifications of any class, core or otherwise. If so, then you're asking about a complete transformation in the design of the language... so I doubt you'll get too many Ruby programmers who think this would not be a big loss :-) At least, speaking for myself, a language that was sort of Ruby-ish in appearance but redesigned to be non-dynamic would not interest me. Or did you mean some arrangement whereby core classes were frozen but others were not? I'm not sure how/whether that would/could work, and I personally don't think it would be desireable at all. David -- David Alan Black home: dblack / superlink.net work: blackdav / shu.edu Web: http://pirate.shu.edu/~blackdav