A little namespace "proposal"

Frank Caggiano frank at crystal-objects.com
Wed Apr 7 02:28:30 UTC 2004


I've been trying to follow this as best I can and trying to get a feel 
for what each side is proposing. I think I have an idea what Goran is 
putting forth but I'm still a bit confused as to Andreas ideas and needs 
for this. I don't have any formal training in any of this, I've been 
programming by the seat of my pants since I started to many years ago. 
So if my comments are total garbage forgive me :-)

Andreas Raab wrote:

> 
> However, when we look at "alternative implementations of the same concepts"
> such as Morphic vs. MVC vs. Tweak as UI frameworks or Squeak's streams vs.
> Flow there are conceptual conflicts which should make it very hard to "reuse
> a name from a conflicting concept". Say, if I write a Morphic app and I just
> happen to use the name "Switch" which is NOT defined in Morphic but IS
> defined in MVC I should not be able to do this because although there *may*
> be a class called Switch it is not part of the context I am working in -
> there is no working "Switch" class in the context of Morphic so allowing
> users to use that name is simply introducing confusion. Similarly, just
> because Flow may not have a class called "WriteStream" doesn't mean that you
> should mix up the concepts - if Flow says it captures the concept of
> streaming and other IO, then clearly the use of "WriteStream" in the context
> of using Flow is just a complete confusion of concepts and should be avoided
> at all costs.

Here you seem to be proposing not a namespace but a context space or 
idea space. For example you are saying that the name 'Switch' shouldn't 
be reused outside of it's original context. Is it the tools that would 
make it hard to reuse 'Switch'?

> 
> So, to me, a namespace isn't about "my little box" as much as it is about
> "my larger context". That's important because as you can see from the above
> it is absolutely required to "block" names that originate from "conflicting
> contexts". Meaning that the mere requirement of "never specify anything that
> doesn't need explicit specification" is not good enough for me here - it
> leads to conflicts in random places and actually makes things worse. I'd
> rather use prefixes (which I am today) than to introduce that kind of
> conceptual confusion.

Again the statement that names should be blocked.
Up to this point I believe I understand your reasoning, but now some 
problems.

> 
>>- When writing code you can refer to the class Delay in two ways -
>>"Delay" or "Kernel::Delay":
>>
>>1. If you type in "Delay" then we first look in the local Namespace of
>>the class you are editing. If there is a "Delay" in that namespace then
>>we bind to that. If not, then we look in ALL other Namespaces and if it
>>resolves in none we signal an Exception. If it resolves to one we ask
>>the user to confirm the right binding. The source will still read
>>"Delay" but the binding is still in itself fully qualified as
>>"Kernel::Delay" since it is in fact an object reference to that class.
>>If it resolves to more than one, the user gets to choose which one and
>>it will be expanded to "Kernel::Delay" in the source (if that is the one
>>he/she chooses).
> 
> 
> This I dislike too, but on the grounds of consistency and it is also why I
> like imports. The only rule for qualifying names for me is: If I see an
> unqualified name, it exists in my namespace. Period. Otherwise I need a
> qualified name. This approach partly depends on the "large context" point of
> view because I agree that otherwise it would lead to endless imports and
> qualifications which would only be annoying.
> 
> Also, note that the above fundamentally violates the "avoid conflicting
> concepts" rule that I mentioned above - it is the precise point of what I am
> talking about that using the name "Switch" in the context of a Morphic
> project should NOT, NOT EVER, resolve automatically to the MVC class
> Switch - someone who really "means" to use that MVC switch should have to
> state that he is "leaving the concept space of Morphic" by writing
> MVC::Switch.
> 

Here it seems you are saying that the name 'Switch' IS ok to use in 
Morphic only that it shouldn't automatically resolve to the 'Switch' in 
MVC.  (which of course is absolutely correct, thought I didn't see 
anything in Groan's comments suggesting automatic mapping. He says the 
user is asked if it resolves outside his namespace.)

>> When a new class "SqueakMap::Delay" is created the tools should warn
>> me that there already is a class called that in another Namespace and
>> that it is generally better if the classes don't conflict by name
>> because of the way resolving works. Sure, currently (before we get a
>> superserver somewhere that can do lookups globally) this only checks
>> against my current image but should still be useful.
> 
> 
> Here again, it depends on whether the namespace represents a conflicting
> concept or not. If I define a "Switch" in Morphic there is no reason why the
> tools should even bother to say anything. There simply is "no Switch in
> Morphic".
> 

This last bit has me confused. Your middle sentence seems to imply that 
if I use the name 'Switch' in a morphic context it is ok, nothing is 
reported but at top you really seemed to say that 'Switch' shouldn't be 
used. It almost seems that Groan's paragraph comes closer to what you 
wrote at the top. Also how is it determined if there is 'a conflicting 
concept'.

I hope you take these comments in the spirit they are written in. I am 
really trying to follow this discussion. It seems that no matter which 
way it goes it will have an impact on all squeak programmers.

-- 
Frank Caggiano				"The best education for the best
caggiano at crystal-objects.com		is the best education for all."
http://www.crystal-objects.com/		   Robert M. Hutchins

Logo Users Ring
http://www.crystal-objects.com/logo/logoring.html






More information about the Squeak-dev mailing list