"Alberto" <[EMAIL PROTECTED]> writes: > I *think* the correct thing to do is what Max pointed out, and make > Demeter happy on the way. What if materialColetado's structure > changes? If you use that level of indirection, you'd have to change > your fields declaration AND any other code that needs that attribute > from an "analise" instance, if you code it as a property, you just need > to modify the getter.
Anywhere materialColetado is used inside analise it uses this SQLObject's feature. I don't write getters and setters for something that the toolkit provides me automatically. This is one benefit of SQLObject. Besides that, the structure doesn't change often and if it changes, who'll grant me that this field won't disappear and have to be removed from the code anyway? Or get renamed to a better thing and need to be changed all over, again? > I think it wouldn't be *that* easy to implement either, as you'd have > to traverese the full path to the desired attribute... what if one of > the intermediary attributes is a callable? (well, ok, it could be a > property...). it remind's me of Cheetah's name lookup mechanism (though > maybe my memory is not good at all :). I think it's too much magic for > just a little datagrid ;) Doesn't it use SQLObject's feature for traversal? If it is using column names and syntax like what is defined in SQLObject, why not let it do all the job? To me it would be less surprising if it worked since I am forced to use SQLObject's syntax and then I expected SQLObject's features to work. If it is a callable, it wouldn't be inside quotes as it happens now with functions and lambdas. > Disclaimer: Haven't read the code before writing the last paragraph so > I might be *way* wrong... :D :-) -- Jorge Godoy <[EMAIL PROTECTED]>
