OOP question....proper way to have 2 objects reference each other?

[SJS]

begin  quoting chris at seberino.org as of Tue, Nov 24, 2009 at 05:32:20PM -0800:
> On Wed, Nov 25, 2009 at 12:34:10AM +0000, SJS wrote:
> > You can't force all sets of the variable to be synchronized, which may turn
> > out to be necessary in multithreaded code.  You also can't impose range
> > checking (well, you can, in *some* languages), units conversion, or "lock"
> > the field against further changes.
> >
> > As for typing out "getXXX" and "setXXX", learn to type already. Plus it's
> > just a convention.  Some languages just use the attribute name -- 
> > name(value) is the setter, and name() is the getter.
> 
> I think the contention is due to both of us coming from different
> perspectives.  I assume you are optimizing your language for multiple people
> working on a project.  Most of the code I write is small projects built by
> just myself.  I don't need all that scaffolding.

s/need/want/

I've met a few people who didn't need much scaffolding. I've met a lot more
who said they didn't, but who really did.
 
That being said, this is also an argument against one-language-everywhere.

> You could object that even apps written by "code cowboys" may be viewed by
> others at a later date.  I'm humble enough to know many (most?) of my pet
> projects won't be used by others.  I despise having to build all that
> infrastructure from day 1.  It just slows me down.  The checks you desire
> could also be done with unit tests or assert statements.

And the chances of you actually writing unit tests, properly using asserts,
and so forth if you're worried about how a little typing "just slows you down"
is, well, nil.

> > > 2. Insisting on declaring classes public, private or protected....as if I
> > >    need to be protected from myself because I might be moronic enough to
> > >    "accidentally" call a method I shouldn't.
> >
> > (a) Think of it as documentation.
> >
> > (b) It gives the compiler some information about what can be optimized.
> >
> > (c) It pushes knowledge into the source, where it can be used by the tools
> >     (and other developers), instead of in your head, where it is only
> >      accessible to you.
> 
> Again see my comments above.  Often I'm writing one off code by myself to
> learn something and don't care about optimization.  All these "features"
> just get in the way.

So, you want a language where it's *easy* to write incomprehensible,
unmaintainable, and slow code?

You should say this when you start to diss features.

-- 
I dislike getters & setters, and thus try to avoid revealing any private state. 
Stewart Stremler