From:	"Steve Ball" <steve AT effectivejava DOT com>
Newsgroups:	comp.os.msdos.djgpp
References:	<8hrrqc$21c$1 AT tron DOT sci DOT fi>
Subject:	Re: NO MORE ACCESS FUNCTIONS (Well, almost...)
Lines:	109
X-Newsreader:	Microsoft Outlook Express 5.00.2615.200
X-MimeOLE:	Produced By Microsoft MimeOLE V5.00.2615.200
Message-ID:	<rQS05.1564$5NF5.9961638@news.xtra.co.nz>
Date:	Mon, 12 Jun 2000 08:41:08 +1200
NNTP-Posting-Host:	210.55.35.135
X-Complaints-To:	newsadmin AT xtra DOT co DOT nz
X-Trace:	news.xtra.co.nz 960756119 210.55.35.135 (Mon, 12 Jun 2000 08:41:59 NZST)
NNTP-Posting-Date:	Mon, 12 Jun 2000 08:41:59 NZST
Organization:	Xtra
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

G'zikes, Stefan!

This is a horrible idea. I know the accessor and mutator functions are
tedious, but this is no improvement. In fact, it is a quantum leap
*backwards*:

- accessor and mutator functions can be made virtual, your scheme can only
do something similar by having each derived class remove and reinsert items
into the associative array object.

- small accessor and mutator functions are typically inline and require less
time and space than any function call. Your scheme will bloat your programs
and will incur an enormous runtime overhead.

- all constructors are responsible for loading all attributes whether or not
those attributes will ever be accessed. The time overhead is great.
Construction should be very cheap -- if you like high-cost construction, go
to Java. :-)

- accessors can report values that calculated not stored. For example, a
Money class might store the value in a single long but have accessors for
getDollarValue, getCentValue, getValueAsDouble, getNbMillions, etc. Just
imagine how awful this makes your mutators if setting one value impacts all
the others; you would have to do multiple replacements on the associative
array. (See what Bertrand Meyers has to say on the Principle of Uniform
Reference).

- there is already an associative array in the STL. It stores items in a
balanced red-black tree. It is very efficient and likely to be orders of
magnitude quicker than your own hand crafted associative array. It you must
do this, at least use the map<> class.

- the mechanism is not typesafe, so a misspelling of "radius" as "raidus" is
not caught at compile time but results in a run-time error. (STL)
associative arrays self-insert so your program could work quite happily for
a while between pieces of code that misspell the same way. You have no way
to report that a get operation failed.

- the attributes cannot be of primitive types like int and double because
you cannot create a heterogenous container to store them. Big runtime
overhead here.

It was a nice idea that might actually work well in other OO languages that
depend on dynamic binding for everything (like Smalltalk). However, C++ is
strictly statically type checked, so this scheme runs very much against the
C++ paradigm and incurs space and time overheads as a result. The classes in
the STL are a good pattern for how accessors and mutators should look. It is
always a good idea to get to know the standard libraries well. I think you
would enjoy it--the STL is a masterpiece of good design.

Steve Ball

Traveler <traveler AT netti DOT fi> wrote in message
news:8hrrqc$21c$1 AT tron DOT sci DOT fi...
> Hello to everyone !
>
> When designing classes I have always be annoyed to make different kinds of
> "get this", "get that" access functions.
>
> Now, with associative array I can make more compact classes.
> So for example, instead of this:
>     Circle    circle(160,100,50);
>     cout << circle.getx() << endl;
>     cout << circle.gety() << endl;
>     cout << circle.getradius << endl;
> I can do this:
>     Circle    circle(160,100,50);
>     cout << circle["x"] << endl;
>     cout << circle["y"] << endl;
>     cout << circle["radius"] << endl;
>     circle["radius"] = 30;
>     cout << circle["radius"] << endl;
>
> This is great becourse I do not need to remember all access functions.
Only
> class "attributes".
> (If you do not see this as a problem then try to program something very
> simple with Java or Win32 API without looking a single time from your
source
> book :=)).
> Code will become shorter and save coding time and decreasing the chance of
> errors.
>
> I will include few files that contains the above trivial main program and
> Associative array class implemented as a single linked list. NOTE however
> that this class IS NOT COMPLETE (example: there is no sorting function
> implemented).
>
> When I finally have time to complete this I will continue my work with the
> heterogeneous array class (that is, Array where all elements do not need
to
> be same type). It´s almost working (inserting and inspecting elements
> implemented, removing one single element poses a problem).
>
>
> Thanks for your time and sorry if my english is poor
> Stefan Fröberg alias Traveler2000AD
> traveler AT netti DOT fi
>
>
>
>
>
>
>
>
>

- Raw text -