Re: Properties

[Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de>]

On 12/1/10 8:52 PM, Martin Krischik wrote:
> Am 28.11.2010, 13:37 Uhr, schrieb Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de>:
>
>> As such, an ASIS enabled Ada processor should be able to write
>> these without too much effort.
>
> Not from a readability point. The argument for properties is that they don't clutter your code. Imagine that when 'Image, 'Value etc. pp where purposed your solution was choosen and code generator would actually add the code for those functions into source. Would that not look hyper ugly.

I don't see how "automatic" get/set subprograms offer
software engineering advantage, even when they are terse
and semi-implicit and purport to avoid repetitive clutter.
It's the desire for the structural clutter that get/set
style really is that I find worrisome.

I'd like to mention an alternative language design idea
by Jeffrey Kingston for contrast with get/set style for
record components.  Whenever you invoke an operation of
an object, you create a new object.


Observe the programs resulting from get/set style. If they
are working, aren't they typically hiding spaghetti coding,
and privacy intrusion?

There certainly are ways of justifying programs in spite
of these qualities.  One is the post hoc fallacy:

"The get/set feature works, since this program works.
Therefore, to choose the get/set approach was right."

If the post hoc fallacy helps you as a person to get
along, fine.
If the post hoc fallacy helps bring customers to Ada,
that's fine for the vendors, I'd say.
Is it fine, though, with those companies in industry
needing to maintain software in order to stay competitive?


There is an everyone-does-it argument in favor of get/set.
I list some use cases.  Which ones do I miss?

- array like access to data structures.

The low level style thinking shines through.
Sometimes just right.  Worth a language change?

- GUI field updates

Forms have not really become "smarter", though, after 30 years
of writing form input logic.  (Oh, I see!  If we did the
software engineering thing and use good algorithms instead of
record component assignments bridled by get/set, still à la FORTRAN 66,
we will not make any more money by writing the same programs
over and over. The old ones still work... O.K., that's a point.)

- data base objects

For building a layer on top of relational records, OK.
For quick and dirty database scripting it might be enough
to update some field in some view (or table) through some setter.
As a design guide, get/set let me understand the many reports about
data bases whose handling requires intimate knowledge of
the details of every program and of every table.

- ...

OK, I'm biased as I'm usually the one who cleans up after
those who think that getting and setting is the best software
design principle.

Anyway, one can always add get/set to Ada since that eases
the transition from the other languages who have added
get/set in very recent years, too.   And exclude get/set
from SPARK for the more critical programs.


~