From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
	INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,248f80acc3d5ccb3
X-Google-Attributes: gid103376,public
From: "Vladimir Olensky" <vladimir_olensky@yahoo.com>
Subject: Re: Objects properties -  Ada design issues question
Date: 2000/02/04
Message-ID: <s9mdep9idh30@corp.supernews.com>#1/1
X-Deja-AN: 581647562
References: <s9ljhv6jdh127@corp.supernews.com>
 <877lgklryd.fsf@deneb.cygnus.argh.org>
Organization: Posted via Supernews, http://www.supernews.com
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Newsgroups: comp.lang.ada
X-Complaints-To: newsabuse@supernews.com
Date: 2000-02-04T00:00:00+00:00
List-Id: <comp.lang.ada>


Florian Weimer wrote in message <877lgklryd.fsf@deneb.cygnus.argh.org>...
>Why are Get/Set subprograms inferior to this approach?  IMHO, this is
>just syntactic sugar of very questionable quality.  It doesn't make
>sense to me to write:
>
>        Some_Label.Width  := New_Width;
>        Some_Label.Height := New_Height;
>
>instead of:
>
>        Resize (Some_Label, Width => New_Width, Height => New_Height);
>
>The latter one is much more explicit and immediately suggests that
>some kind of operation takes place.


Problem arises ( as I described in previous message)  when we want
to define common interface to the set of objects ("Black Boxes") derived
from some root class and we do not know in advance properties  for
particular derived  object  that should be revealed to the client. In
addition
that properties could be very  different for different derived  classes.

Problem with standard Get  and Set approach is that you need to extend
interface for each derived type and this breaks our intention to have
common interface with some limited set of operations  to each "Black Box"
component.

So it would be nice to have common interface to different properties
(that are not known in advance) of different  kind of objects.
So here use of  ":=" as a standard Get Set operator for any property
is very useful. We just define in the private part of the implementation
what this operator does for each particular property without disturbing
public interface.

And as I shown this could be done without any change in the
current Ada syntax.

>Finally, use of properties seems to be rather restricted to visual GUI
>design, and there are some technical reasons for it in this region.


Not at all.  This problem  is not limited to this particular area.
It is much broader.

This problem arises when we try to implement "Black Box" design
model where each "Black Box" may have completely different set of
properties but provide some common sort of functionality.

 In my particular case I encountered this problem working on the
ACMN  (Ada Communication Subsystem )  for WinNT  that would
 provide common (standardized)  interface to most of the
communication resources available in the underlying OS or
driver of some communication device.

Regards,
Vladimir Olensky