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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC 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: Florian Weimer <someone@deneb.cygnus.argh.org>
Subject: Re: Objects properties -  Ada design issues question
Date: 2000/02/08
Message-ID: <87u2jjjtx9.fsf@deneb.cygnus.argh.org>#1/1
X-Deja-AN: 583789864
References: <s9ljhv6jdh127@corp.supernews.com>
 <877lgklryd.fsf@deneb.cygnus.argh.org> <s9mdep9idh30@corp.supernews.com>
Mail-Copies-To: never
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: abuse@cygnus.argh.org
X-Trace: deneb.cygnus.argh.org 950043330 19080 192.168.1.2 (8 Feb 2000
 20:55:30 GMT)
Organization: Penguin on board
User-Agent: Gnus/5.0804 (Gnus v5.8.4) Emacs/20.4
Mime-Version: 1.0
Reply-To: Florian Weimer <fw@s.netic.de>
NNTP-Posting-Date: 8 Feb 2000 20:55:30 GMT
Newsgroups: comp.lang.ada
Date: 2000-02-08T20:55:30+00:00
List-Id: <comp.lang.ada>

"Vladimir Olensky" <vladimir_olensky@yahoo.com> writes:

> 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.

I'm sorry, but I'm still not convinced.  This explanation suggests
that you are aiming at Java interfaces or Objective C protocols.
Certainly a nice feature, but not related to properties.

> 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.

Which derived type?  Derived from the record type, or derived from
the type of the components?  Could you show some Ada code which shows
the problem?

> 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.

Why can't you use factory methods which create appropriate interface
classes?  This seems to achieve pretty much the same thing, and it can
be expressed directly in Ada.