Objects properties - Ada design issues question

Objects properties - Ada design issues question

[Vladimir Olensky]

Objects properties -  Ada design issues question:

In "Black Box" design model any object may have some properties
(run time or design ) that need to be known to the client of that
"Black Box" object. Some of them are read-write properties, some
others are read-only properties. Last ones are viewed as
constants by clients but could be updated internally, so they
have read-write access internally.

The notion of properties is already supported by some of the non
standardized languages (e.g. Delphi Object Pascal).

It is some pain though to model them in Ada.

The problem is that when designing the hierarchy of some types we
do not know in advance how many and which properties descendants
of the root type will have. On the other hand we want to provide
standard common interface to each "Black Box" component including
access to it's properties which we do not know in advance.

So this means that we do not want to export additional  Get and
Set functions/procedures for each new descendant with new set of
properties and we want to get access (read or write)  to these
properties  in some unified way without exporting new set
of Get and Set functions/procedures for each new descendant.

In Ada if we want to have predetermined and separate access to
each internal "Black Box" property  (read or read-write) we
have to extend our public interface adding new Get and Set
procedures for each internal property and separately describe
each property in our interface. This brakes our intent not to
disturb common hierarchy interface by extending it for descendant
types. In other words it does not allow us to obtain highest
possible level of encapsulation by hiding Get and Set individual
property procedures from clients. This means that we are not able
to provide unified property interfaces for the whole type hierarchy.

One of two possible ways in Ada to provide unified access to each
instance property is to have record that contains all the object
properties. This record is in turn is one of the field in the
"Black Box" object  record.
Doing that we can  use root predefined Get_Properties and
Set_Properties procedures which retrieve or set  the whole
record of properties all at once.

Though this approach allows us to obtain some additional level of
encapsulation we lose two things.

1. First we can not now address each property individually as
Get and Set procedures are applied to the whole properties record.
One should remember that main intent of the Get and Set procedure
is not only to extract or set some properties fields.
Get procedure should update appropriate property fields from some
object internal and thus make them available for client. Set
procedure should not only update property field in the  property
record but put it into effect internally.

2. Secondly this does not allow us to have some properties to have
different access privileges (some are with read-write access and
some are with read-only access which is a constant view).
All of the entries in the property fields of the object instance
property record entry will have read-write access for the client
which is not good.
This is due to the fact that Ada does not allow to have constant
fields in record types.

So described above approach could be considered only as some
extremely limited way to provide common interface to any
descendant object properties.

I should mention that for "static" type properties that is common
for several type instances it is very easy to provide constant view
of the internal read-write variable to the client of the package
without  need to use access types for client.
(If anyone is interested I may provide working example of that).

But  we need to be able to do that for properties of each object
instance so though it may be useful in some situations it does
not help much.

I like the approach to this problem implemented in Delphi Object
Pascal.

We may declare some public or published object properties and
assign for each property individual Read or Write or both
procedures  that are not visible to the clients as they are located in
the private object declaration part.
In addition we may also use  different property use and access
modifiers.

Delphi approach  is very  close to Ada syntax.

We can just declare something like this:

type T = class (some_parent_class)
  private
     function        Get_Property1 () : Integer;
     function        Get_Property2 () : Integer;
     procedure    Set_Property1 (prop :Integer);
     procedure    Set_Property2 (prop: Integer);
  public
     property  prop_1 : Integer read Get_Property1 write Set_Property1;
  published
     property  prop_2 : Integer read Get_Property2 write Set_Property2;
  end;

Then having an instance of type T ,  we can access that attributes
directly by using ":=" operator.
If the property is a right hand operand then Get_Propery is involved.
If the property is a left hand operand then Set_Propery is involved.

program
Var
   obj      :  T;
   p1, p2  : Integer;
begin
   p1 := obj.Prop_1;
   p2 := obj.Prop_2;
{ or }
   obj.Prop_1 := 2;
   obj.Prop_2 := 10;
end;

In Ada it seems that we can do something like that  by
overloading ":=" operator.
But we can do that only for distinct types but not for
the particular  property instance/field.
So this is not perfect solution.

On the other hand I see that current Ada representation
syntax perfectly fits here.

We can just declare:

package P is

  type T is tagged private;

   type T1 is new T with record
        --  public properties A and B;
        --  they are public views of some internal  states
        --  which in turn could be fields of some complex
        --  "Black Box" internal  structures;
        A : [property]  constant Integer;
        B : [property]  Integer;
   end record;

private
   type T is tagged record
       < some fields>
   end record;

   function  Get_Property1 (obj: in out T ) : Integer;
   function  Get_Property2 (obj: in out T ) : Integer;
   procedure Set_Property2 (obj: in out T; prop: Integer);

   -- and then representation clause:
   for T.A'Get use Get_Property1 (obj: in out T ) : Integer;
   for T.B'Get use Get_Property1 (obj: in out T ) : Integer;
   for T.B'Set use Set_Property1 (obj: in out T; prop: Integer);

end P;

No need to introduce any new keywords.
May be only the  PROPERTY keyword could be introduced for
clarity but generally there  is no need to do that at all.

Everything fit perfectly into current Ada syntax.

It would be very interesting to hear different  opinions
regarding this  "objects properties" issue and it's
prospective of being implemented in future Ada revisions.
As was shown this could be done without changing current
Ada syntax.


Regards,
Vladimir Olensky

Re: Objects properties - Ada design issues question

[Matthew Heaney]

In article <s9ljhv6jdh127@corp.supernews.com> , "Vladimir Olensky" 
<vladimir_olensky@yahoo.com> wrote:

> This is due to the fact that Ada does not allow to have constant
> fields in record types.

But you can so that by using discriminants:

type RT
  (X : XT;
   Y : YT) is record
   Z : ZT;
end record;

Components X and Y are read-only, and component Z is read-write.

--
Celebrate Darwin Day on Saturday, 12 February!

<http://www.bbc.co.uk/education/darwin/index.shtml>

Re: Objects properties - Ada design issues question

[Florian Weimer]

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

>         A : [property]  constant Integer;
>         B : [property]  Integer;

Using [] isn't a good idea, because it doesn't fit Ada very well.
(This character isn't used by the language now, perhaps that's why
you chose it.)  In addition, I would preserve [] (and @) for Objective
Ada. ;)

Microsoft patented the [] construct (for preventing clashes with
existing syntax and keywords) several years ago, BTW.

> It would be very interesting to hear different  opinions
> regarding this  "objects properties" issue and it's
> prospective of being implemented in future Ada revisions.
> As was shown this could be done without changing current
> Ada syntax.

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.

Finally, use of properties seems to be rather restricted to visual GUI
design, and there are some technical reasons for it in this region.
For example, in Delphi, they aren't mere syntactic sugar, but they
provide some kind of introspection feature needed by the GUI design tool
(which has to present the properties of, say, a label to the developer
so that he can make adjustments).

Re: Objects properties - Ada design issues question

[Vladimir Olensky]

Florian Weimer wrote in message <877lgklryd.fsf@deneb.cygnus.argh.org>...
>"Vladimir Olensky" <vladimir_olensky@yahoo.com> writes:
>
>>         A : [property]  constant Integer;
>>         B : [property]  Integer;
>
>Using [] isn't a good idea, because it doesn't fit Ada very well.
>(This character isn't used by the language now, perhaps that's why
>you chose it.)  In addition, I would preserve [] (and @) for Objective
>Ada. ;)


I used  [ ] in my example  just to show that the property keyword
is optional in my suggestion. Everything could be done without
using it at all.

Regards,
Vladimir Olensky

Re: Objects properties - Ada design issues question

[Vladimir Olensky]

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

Re: Objects properties - Ada design issues question

[Andy]

Vladimir Olensky wrote:
> 
> 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.
> 
But the fact that you would like declare these as properties in a child
class changes the 'common interface'. If a child class has a new
property 
(as can be done in Delphi) or defines additional Get/Set operations as
is
done in Ada 95 - what's the difference. You cannot access these via the 
common interface defined for the root class.

Or am I missing something?

As do your orginal question. One models Delphi properties with Get and
Set operations. Although syntacically different, they provide
essentially
the same operation.

___________________________________________

   Andy Starritt
___________________________________________

Re: Objects properties - Ada design issues question

[Vladimir Olensky]

Andy wrote in message <389CEEF8.69E7@nospam.com.tj>...
>Vladimir Olensky wrote:
>>
>> 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.
>>
>But the fact that you would like declare these as properties in a child
>class changes the 'common interface'. If a child class has a new
>property  (as can be done in Delphi) or defines additional Get/Set
>operations as  is done in Ada 95 - what's the difference. You cannot
> access these via the common interface defined for the root class.
>
>Or am I missing something?


Adding new fields to the derived [tagged] record type and
adding new public operations to work with these fields is
not the same.  In Ada one need to do both.

The "common interface" is a common set of operations.
Our intent is not  to add any new operations to the public
part of the interface even if we add some new properties
to the derived classes.  What we want is only pair of Get
and  Set operations for any property that could be declared
in any derived class. These pair of Get and Set operations
may be hidden and be used to overload implicitly ":=" operator
as done in Delphi or they may be visible to clients and be
declared in the common root interface.
The idea is that we have only one pair of Get and Set operations
for any kind of property that we may have in the future.
And this means that we have common interface to any kind
of property that we do not know in advance.


In addition to what I have shown in my previous posts Ada have
one more construct that could be used to model this common
interface to any property.


This is  use of  Read and Write attributes as done in Ada.Streams.

So we could just use:

   Value  := Some_Tagged_Type.Property1'Read;

   Some_Tagged_Type.Property1'Write (Value);

All this  means that we have at least two ways  to do what we want
without any change in the current Ada syntax.

The only problem that we have now is that Ada allows to overload
operators only for types  but not for the fields of some [tagged]
record types.
As a result of this  we need to introduce new operations with new
names into the public interface of the derived types/classes and
this  is what I meant when talking about disturbing common
public interface.

But again as I mentioned in my previous posts all that  could be
expressed using current Ada representation syntax:

package P is
    type Some_Tagged_Type is tagged  record
        Property1 : Some_Type;
        <...>
    end record;
private
   for  Some_Tagged_Type.Property1'Read  use Some_Function ... ;
   for  Some_Tagged_Type.Property1'Write  use Some_Procedure ... ;
end P;

We do not even have a need to use "property" keyword.
If for some field exists such representation clause that means that
this is a property field.
Of course use of "property" modifier could make everything more clear
for the client of that package.

>
>As do your original question. One models Delphi properties with Get and
>Set operations. Although syntacically different, they provide
>essentially  the same operation.

As I explained above in Ada we can not do that without introducing new
operations with new names into public interface as Ada does not allow
to overload operators for the fields of [tagged] records (only for types).
On the other hand in  Delphi one need to overloads READ and (or)  WRITE
operations for any class field that is declared as property using syntax
surprisingly close to Ada syntax.
In the public interface these READ and WRITE operations implicitly
overload  common ":=" operator.

Regards,
Vladimir Olensky

Re: Objects properties - Ada design issues question

[Andy]

Vladimir Olensky wrote:
> 
> Adding new fields to the derived [tagged] record type and
> adding new public operations to work with these fields is
> not the same.  In Ada one need to do both.

I don't think so.

package X is
   type X is tagged .....;
end X;

with X;
package Y is
   type Y is X.X with record
       Attribute : Some_New_Attriutes;
   end record;
end Y;

with Y;
package Z is
   type Z is new Y.Y with null record;
   procedure M1 (Item : in Z);
end Z;

This is legal Ada. Package Y extends X by just adding fields.
Package Z extends Y by just adding new public methods.

  
> The "common interface" is a common set of operations.
> Our intent is not  to add any new operations to the public
> part of the interface even if we add some new properties
> to the derived classes.  What we want is only pair of Get
> and  Set operations for any property that could be declared
> in any derived class. These pair of Get and Set operations
> may be hidden and be used to overload implicitly ":=" operator
> as done in Delphi or they may be visible to clients and be
> declared in the common root interface.

> The idea is that we have only one pair of Get and Set operations
> for any kind of property that we may have in the future.
> And this means that we have common interface to any kind
> of property that we do not know in advance.
> 

[snipped]

> But again as I mentioned in my previous posts all that  could be
> expressed using current Ada representation syntax:
> 
> package P is
>     type Some_Tagged_Type is tagged  record
>         Property1 : Some_Type;
>         <...>
>     end record;
> private
>    for  Some_Tagged_Type.Property1'Read  use Some_Function ... ;
>    for  Some_Tagged_Type.Property1'Write  use Some_Procedure ... ;
> end P;
> 
> We do not even have a need to use "property" keyword.
> If for some field exists such representation clause that means that
> this is a property field.
> Of course use of "property" modifier could make everything more clear
> for the client of that package.
> 

But even if Ada allowed this, how can you address a new Property by name
on
a child class, if you want to restrict yourself to the common (parent) 
interface???

> >As to your original question. One models Delphi properties with Get and
> >Set operations. Although syntacically different, they provide
> >essentially  the same operation.
> 
> As I explained above in Ada we can not do that without introducing new
> operations with new names into public interface as Ada does not allow
> to overload operators for the fields of [tagged] records (only for types).
> On the other hand in  Delphi one need to overloads READ and (or)  WRITE
> operations for any class field that is declared as property using syntax
> surprisingly close to Ada syntax.
> In the public interface these READ and WRITE operations implicitly
> overload  common ":=" operator.

If I read you write, you want the Ada equivilent of this Delphi:

type
   Root = class 
   private
      function Get : Integer; virtual;
   public;
      property X : Integer read Get;
   end;


   Child = class (Root)
   private
      function Get : Integer; override;
   end;
      
var
   A : Root;
   B : Root;
   K : Integer;

begin

   A := Root.Create;
   B := Child.Create;

   K := A.X;  // this calls the Get function in Root.
   K := B.X;  // this calls the Get function in Child.

end.

If yes, it's easy - read on. If no please elaborate...

package Root is
   type Item is tagged ...;
   function X (I : in Item) return Integer;
end Root;

with Root;
package Child is
   type Item is tagged ...;
   function X (I : in Item) return Integer;  -- this overrides Root.X
end Child;

with Root, Child;

A : Root.Item'Class := some Root value;
B : Root.Item'Class := some Child value;
K : Integer;

begin

  K := Root.X (A);  -- this calls the X 'property' function in Root
  K := Root.X (B);  -- this calls the X 'property' function in Child

end;

Regards,
Andy

Re: Objects properties - Ada design issues question

[Florian Weimer]

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

Re: Objects properties - Ada design issues question

[Samuel T. Harris]

Florian Weimer wrote:
> 
> "Vladimir Olensky" <vladimir_olensky@yahoo.com> writes:
> 
> >         A : [property]  constant Integer;
> >         B : [property]  Integer;
> 
> Using [] isn't a good idea, because it doesn't fit Ada very well.
> (This character isn't used by the language now, perhaps that's why
> you chose it.)  In addition, I would preserve [] (and @) for Objective
> Ada. ;)
> 
> Microsoft patented the [] construct (for preventing clashes with
> existing syntax and keywords) several years ago, BTW.

Well, Microsoft seems to patent practically anything anyone
thinks up. And the US patent office does a dismal job of
prior art research. IMO most software related patents
are not enforcible and are just waiting for someone to
"infringe" and defend to blow them out of the water.


-- 
Samuel T. Harris, Principal Engineer
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"

Re: Objects properties - Ada design issues question

[Vladimir Olensky]

Vladimir Olensky wrote in message ...
>Objects properties -  Ada design issues question:


Noticed that my example was a little bit incorrect so
below is  a small correcton:

It was:
>
>package P is
>
>  type T is tagged private;
>
>   type T1 is  new T with record
>        --  public properties A and B;
>        --  they are public views of some internal  states
>        --  which in turn could be fields of some complex
>        --  "Black Box" internal  structures;
>        A : [property]  constant Integer;
>        B : [property]  Integer;
>   end record;
> private
<   ...>
> end P;


Should be:

package P is
   type T is abstract tagged record
        --  public properties A and B;
        --  they are public views of some internal  states
        --  which in turn could be fields of some complex
        --  "Black Box" internal  structures;
        A : [property]  constant Integer;
        B : [property]  Integer;
   end record;

  type T1 is new T with   private;

 private
    <   ...>
    for  T1.A'Get ...
    for  T1.B'Get ..
    for  T1.B'Set ..

 end P;

Sorry for not having checked it prior to sending.

Regards,
Vladimie Olensly