Re: setter problem

[thant@void.esd.sgi.com]

> Can you elaborate on why, exactly, exporting a setter function is a problem?
> 
> -T


Modules have two purposes: The first is to prevent namespace pollution.
The second is to guarantee that clients only use the advertised 
interfaces to libraries so that the libraries can be changed without
breaking client code.

Coming from the C++ world, I feel weird without the ability to make
methods private at the class level, let alone the module level.

I understand that getter and setter are really two different things.
I just don't like the price Dylan is making me pay.  I would think
the right thing to do is dispatch 'set!' the same way all the methods
are dispatched and use whatever mechanism it uses to only export 
the appropriate methods.  This would make things simpler in terms
of syntax because 'set!' would look like any other method.  This 
also wouldn't prevent Dylan from automatically creating the set! for 
you when you created the slot.

Is there a reason why 'set!' isn't treated like a regular method?
Does it have to do with the fact that normally set! is a special 
case because it doesn't evaluate the variable being set?

thant