From: Gavin Sinclair <gsinclair@...>
Date: 2002-08-14T08:25:17+09:00
Subject: Re: ambiguity backtrack - accessors and persistent locals


From: <dblack@candle.superlink.net>


> Hi --
>
> On Tue, 13 Aug 2002, Gavin Sinclair wrote:
>
> > The syntax (for "setter methods") "object.field = value" implies
> > simplicity.  If you need to jump through various hoops every time a
> > field is written, you probably want a method that implies it does
> > something serious.  Saying something simple while doing something
> > complicated will likely make code hard to read.  A minor point,
> > perhaps, but one which, if followed, could again take the sting out
> > of the writer-method-withoud-explicit-self ambiguity.
>
> That's an interesting way to look at it, though I'm not sure it scales
> very well.  I'm thinking of things like hash-like set and fetch
> methods that operate directly (but transparently) on databases, which
> I think can be very convenient and not obscure except to the extent
> that they're designed to black-box-ify the file I/O.

You obviously have quite specific requirements in this case that demand a
little exception to my rule (hand on, wasn't it a conjecture?).  I think a nice
access to the database like that sounds good.  Even so, I expect these beefy
assignment methods will be nicely contained in one class, and the majority of
classes in your project will be more straightforward in this respect.

Thus I don't think "scalability" is the problem, just "absolute generality".

> I definitely do agree with one part or implication of your point,
> namely that #field=() methods should set something.  I know that
> sounds obvious, but I think part of what feels shaky to people might
> be that there's a disconnect between the presence of assignment syntax
> and the question of what's actually taking place.
>
>
> David
>

Gavin