Joerg 'Herkules' Plewe wrote:
>
> But it's a bad idea to introduce automatic getter/setter for everything just
> for OO dogmatic reasons. Is my class a pure data container? Well, express
> that! Don't make it more 'important' by introducing lots of methods doing
> nothing. Most (99%?) of these thing will never change in future (my
> experience, at least).
If you have a look at the J3D API, you will find that is exactly what
happens. All the vecmath classes have public vars. However, once you get
to the real core, then they are not - simple reason: sets and gets do a
heck of a lot more than just set a value. A simple thing that came up in
a different thread - setting the transform on a Transform group from
outside a behaviour. Artur was concerned about it getting trashed
halfway through a copy. Those sort of things you just simply cannot
protect against having public variables.
Now, let me put on my spec writer's hat.
For a public, general purpose, widely used library perspective, the
absolute *worst* thing you can do is make all the variables public. You
talk about "I really don't want my object to tell me I'm an idiot and
cannot handle it. Not even manage a variable." Well, obviously you are
one of the few. Do you realise how many subtle errors run into code
taking that approach - and we're not talking spinning cubes here? When
you get so many newbies hitting an API, you end up spending all your
time dealing with trying to debug their mistakes where their array was
one item too short and your code generates index exceptions etc etc.
Even far more experienced programmers forget about this sort of stuff.
Safety catches are an exceedingly important thing to have in a anything
that is public. Start writing any decent size application and it does
help tremendously. As a public API developer, I like to spend my time
helping the advanced people wring more performance out of it, or add new
features or debug those hideously difficult problems, not answer every
3rd email saying "your API is fucked because it keeps crashing with
array index exceptions" when it is really their problem. Tell them they
are a stupid idiot before it becomes your problem - they respect that
much more then.
Heading over to the J3D side....
Internally the model for java3d is "multiple simultaneous threads doing
parallel execution of behaviours, rendering, collision and
whatever-the-hell-else-we-feel-like-adding". All these threads have to
synchronise on a single common datasource. This means that having public
variables is a hugely horrible problem dealing with synchronisation.
>From your comments it seems like you've never done much large scale
multi-threaded coding. It is indeed a different kettle of fish to your
simple two or three independent thread app that most programmers ever
get to do. Just have a look at the "simple" problem in another thread of
having his behavior freeze when he synchronises. Now, take this and
multiply it by a factor of about 10 and that's what you would see in j3d
if it went with public vars. In fact, I think you would find that it
would be even *slower* if it had public vars because of all the extra
context checking that has to be done between all of the threads, the
public variables and other internal code. So, what may seem like a
convenience to you ends up resulting in even worse system for many, many
different reasons.
--
Justin Couch http://www.vlc.com.au/~justin/
Freelance Java Consultant http://www.yumetech.com/
Author, Java 3D FAQ Maintainer http://www.j3d.org/
-------------------------------------------------------------------
"Humanism is dead. Animals think, feel; so do machines now.
Neither man nor woman is the measure of all things. Every organism
processes data according to its domain, its environment; you, with
all your brains, would be useless in a mouse's universe..."
- Greg Bear, Slant
-------------------------------------------------------------------
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
