OOP question....proper way to have 2 objects reference each
bofh at stremler.net
Tue Nov 24 17:51:52 PST 2009
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.
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.
More information about the KPLUG-List