From: David Simmons Date: 2001-11-27T07:47:24+09:00 Subject: [ruby-talk:26566] Re: Selector Namespaces: A Standard Feature for Smalltalk? "Doc O'Leary" wrote in message news:261120011559596827%droleary@subsume.com... > In article <3C019B73.60205@mail.com>, James A. Robertson > wrote: > > > Actually, they do. Take Smalltalk - I load a component like Distributed > > Smalltalk into the system. It overrides the Object>>#printOn: method. > > > > I now load some other component - someone's custom inspector framework. > > It also overrides Object>>printOn: > > > > I to use both - having selector level namespaces would solve > > this, while versioning doesn't help me . > > 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. Hi Doc, We are basically disagreeing. Further discussion will just result in re-hashing the same arguments with different variations. 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. 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. Software systems and re-use are not always possible to design from "whole-cloth" and often may never be entirely designed -- this is a bio-system view. Therefore, design well with what whatever "whole-cloth" elements you control and exercise care and attention to provide fault tolerant software through conscious acts of defensive programming. 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". -- Dave S. [www.smallscript.org]