getting rid of DOTTEDNAMES ?

Hi,

During the implementation of the new @decorators and direct attribute access, I've run
into some more issues regarding DOTTEDNAMES.
That feature (disabled by default) doesn't play well with direct attribute access. That
gives you a local copy of the attribute's value so writing something like this:

	proxy.attr.update("new value")

will actually invoke update() on the local copy instead of on the attribute in the
remote object.

This may look silly at first, but if you think of the semantics of directly accessing
the remote attribute's value, it makes sense. Without that feature you'll have to write
a getter method and call that:

	proxy.get_attr().update("new value")

This *also* retrieves a local copy of the attribute value and will call update() on the
local copy instead of the remote.

The only way to directly update the remote attribute's value is to not use the new
metadata system, and setting DOTTEDNAMES to True (or be sane and write an updater
method). In other words, DOTTEDNAMES is only working when the new Metadata feature is
disabled (which it won't be by default).

Also, as you know, enabling DOTTEDNAMES opens up a serious security hole in the server.

(and finally, a theoretical issue; enabling DOTTEDNAMES allows you to break the Law of
Demeter on your remote interfaces)


Bottom line: I want to get rid of DOTTEDNAMES altogether when rolling out the new
metadata feature. It's just too much trouble.


Thoughts? Anyone actually using it?



Irmen

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds