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
