From: Doc O'Leary Date: 2001-11-28T03:29:41+09:00 Subject: [ruby-talk:26686] Re: Selector Namespaces: A Standard Feature for Smalltalk? In article , David Simmons wrote: > "Doc O'Leary" wrote in message > news:261120011559596827%droleary@subsume.com... > > > > I never said namespaces weren't a solution, I just said they were a > > poor, indirect solution to what developers really want. Namespaces > > muck up the code far too much for the benefits they offer. It doesn't > > take much imagination to come up with a system that better suits your > > needs at a higher level instead of suffering with the hackery that > > namespaces provide. > > I sense that you are focused on design and getting things right, and > anything less must be excluded from your world view. If my assertion is > correct, then it ignores human nature (path of least resistance/easiest > course) and a natural proclivity thereby to what staunch-advocates of the > "right-design" way would term laziness. Quite the opposite. It is you who seems fixated on namespaces while I am encouraging you to explore different solutions that might better solve the probelm. I have never once claimed that you could completely eliminate the root problem of a poor design or bad management influences. Because I am aware of problems in the *entire* development lifecycle, I know that namespaces fall short of what developers really need to properly integrate systems. Yeah, you can make due, but it's pure hackery to throw namespaces at all the problems that crop up. > My personal view is to strive to always design and get it right. Balance > that against other real-world goals and constraints; recognize that designs > need to evolve based on experience and changing requirements so iterative > processes are essential [assume un-anticipated changes will happen]. That's > one of the main reasons why after 25 years of professional software > engineering experience I am such a staunch advocate of dynamic languages. I have a feeling we disagree far less than you think. I simply think that stopping at namespaces is a mistake when there are more direct and powerful solutions out there to address the issues. My abstraction of a class or an object method doesn't involve the string of characters used to name it, and as such I see the introduction of namespaces as completely missing the mark. I'll leave it to others to figure out if this means I have more or less than "25 years of professional software engineering experience". > I've seen far too many projects and companies get blamed for "failures" in > "carefully designed" systems that failed not because they were "at fault", > but because some 3rd-party late-integration element couldn't run properly > because the primary system was intolerant and unflexible [frequently through > versioning]. The result was failure to deploy successfully/properly; the > impact was loss of business [money, clients, reputation, etc] and ultimately > that prevented [or negatively impacted resources for] ever polishing it > iteratively to get it "right". You've seem to have mixed up the issues. The can of course "at fault" and deserving of blame for "failures", but it would be because the system *wasn't* "carefully designed" as they had claimed. I would never make such claims when 3rd party integration issues (late or otherwise) were still a factor, regardless of language or system features that would purportedly address them. I've lived through too much hype and "silver bullet" solutions to believe that namespaces are the One True Solution(tm) to the ills of integration.