On Friday 04 April 2008 16:31:56 John M. Dlugosz wrote: > chromatic chromatic-at-wgz.org |Perl 6| wrote:
> > It shouldn't be. > So you are saying that... I was talking about syntax. > In that case, why allow the variable-name form at all? Because they're variables. Sure, they're instance variables, but like hearsay and conjecture are *kinds* of evidence, instance variables are kinds of variables. Sometimes it's nice to be able to assign to them, for example: method in_place_attribute_assignment ($.a, $.b, $.c); > >> Why keep the variable syntax? > > Uniform access principle. See also "Why Java programmers fetishize their > > IDEs, reason #482: autogeneration of metric boat-loads of > > accessors/mutators at just the click of a button." > > That seems to be saying that using the method-call form is preferred, as > it abstracts whether it is a real hard attribute or not. Since my > question was why keep the variable-name form, I think we are not > understanding each other. Yeah, I think you're asking the question backwards. Maybe you should ask instead "Why are there accessor methods for instance variables? Why not support only direct instance variable access?" > >> I'm getting a picture of 3 forms of access: Really direct, direct but > >> asking the class to access it rather than knowing how storage works, and > >> indirect that may involve your own code to do other things besides just > >> get/set the attribute. But I think the middle one can be handled > >> invisibly by the compiler -- it's no different from a tied hash. > > That really depends on how much external syntax you want to change if you > > change the internal representation of an object. For me, that's > > approximately none. > I don't understand that sentence at all. Again, "invisibly by the > compiler" sounds like what you want. I'm still talking about syntax; I don't care for lvalue methods that look more like methods, not variables. Maybe that's a personal failing. I also could be completely misunderstanding what you're asking. I *am* supposed to be researching a J2EE/SOA article at the moment. -- c