About 0Y interfaces

About 0Y interfaces

[Alex R. Mosteo]

Hi,

I hope someone can clarify some aspects of interfaces to me. I've read 
the description in several places but there are some things I'm not sure 
about.

Firstly, interfaces are purely abstract, right? There's no way to 
provide a default/partial implementation except creating an object type 
which implements that interface.

Secondly, we can create an object type which implements two or more 
interfaces. But I guess there's no multiple inheritance from classes, so 
you couldn't use two implementations of two different interfaces 
directly when creating a new type. Is this right? You'd need to use, for 
example, member objects and use proxy calls.

I think I'm not forgetting anything. Thanks in advance,

Alex.

Re: About 0Y interfaces

[Dmitry A. Kazakov]

On Tue, 18 Oct 2005 14:49:04 +0200, Alex R. Mosteo wrote:

> I hope someone can clarify some aspects of interfaces to me. I've read 
> the description in several places but there are some things I'm not sure 
> about.
> 
> Firstly, interfaces are purely abstract, right? There's no way to 
> provide a default/partial implementation except creating an object type 
> which implements that interface.
> 
> Secondly, we can create an object type which implements two or more 
> interfaces. But I guess there's no multiple inheritance from classes, so 
> you couldn't use two implementations of two different interfaces 
> directly when creating a new type. Is this right? You'd need to use, for 
> example, member objects and use proxy calls.

I think the answer depends on what is meant under "implementation":

1. Implementation of the values
(data implementation)

2. Implementation of the primitive operations
(type interface implementation)

3. Implementation of class-wide operations
(class interface implementation)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: About 0Y interfaces

[Alex R. Mosteo]

Dmitry A. Kazakov wrote:
> On Tue, 18 Oct 2005 14:49:04 +0200, Alex R. Mosteo wrote:
> 
> 
>>I hope someone can clarify some aspects of interfaces to me. I've read 
>>the description in several places but there are some things I'm not sure 
>>about.
>>
>>Firstly, interfaces are purely abstract, right? There's no way to 
>>provide a default/partial implementation except creating an object type 
>>which implements that interface.
>>
>>Secondly, we can create an object type which implements two or more 
>>interfaces. But I guess there's no multiple inheritance from classes, so 
>>you couldn't use two implementations of two different interfaces 
>>directly when creating a new type. Is this right? You'd need to use, for 
>>example, member objects and use proxy calls.
> 
> 
> I think the answer depends on what is meant under "implementation":

I was refering to implementation of the primitive operations.

> 1. Implementation of the values
> (data implementation)

I'm not sure what this means. I'd say that you're not refering to data 
initialization, since one can't provide record definition for an interface?

> 2. Implementation of the primitive operations
> (type interface implementation)

This is what I had in mind. Let's say for example that you want a 
primitive operation to always make a dispatching call on another 
operation. You can't model this in the interface, right?

> 3. Implementation of class-wide operations
> (class interface implementation)

I don't see any issue here. Just provide the subprograms you consider 
necessary taking classwide objects?

Re: About 0Y interfaces

[Pascal Obry]

Alex,

> Firstly, interfaces are purely abstract, right? There's no way to
> provide a default/partial implementation except creating an object type
> which implements that interface.

Right.

> Secondly, we can create an object type which implements two or more
> interfaces.

Right.

> But I guess there's no multiple inheritance from classes, so
> you couldn't use two implementations of two different interfaces
> directly when creating a new type. 

There is no notion of interface implementation. Interfaces are inherited
by a tagged object and implemented at this point.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: About 0Y interfaces

[Dmitry A. Kazakov]

On Tue, 18 Oct 2005 16:34:08 +0200, Alex R. Mosteo wrote:

> Dmitry A. Kazakov wrote:
>> On Tue, 18 Oct 2005 14:49:04 +0200, Alex R. Mosteo wrote:
>> 
>>>I hope someone can clarify some aspects of interfaces to me. I've read 
>>>the description in several places but there are some things I'm not sure 
>>>about.
>>>
>>>Firstly, interfaces are purely abstract, right? There's no way to 
>>>provide a default/partial implementation except creating an object type 
>>>which implements that interface.
>>>
>>>Secondly, we can create an object type which implements two or more 
>>>interfaces. But I guess there's no multiple inheritance from classes, so 
>>>you couldn't use two implementations of two different interfaces 
>>>directly when creating a new type. Is this right? You'd need to use, for 
>>>example, member objects and use proxy calls.
>> 
>> I think the answer depends on what is meant under "implementation":
> 
> I was refering to implementation of the primitive operations.
> 
>> 1. Implementation of the values
>> (data implementation)
> 
> I'm not sure what this means. I'd say that you're not refering to data 
> initialization, since one can't provide record definition for an interface?

Yes

>> 2. Implementation of the primitive operations
>> (type interface implementation)
> 
> This is what I had in mind. Let's say for example that you want a 
> primitive operation to always make a dispatching call on another 
> operation. You can't model this in the interface, right?

Right. This is not how it works in Ada independently on interface/concrete
type issue. From a primitive operation you call another operation
*consistent* to the view (contract) of the caller. This view is fixed, and
already at the compile time you know the target.

In other words: implementations of a primitive operation are [by default]
defined in terms of their types. If you wanted to have an operation defined
in terms of the class, that should be a class-wide operation.

>> 3. Implementation of class-wide operations
>> (class interface implementation)
> 
> I don't see any issue here. Just provide the subprograms you consider 
> necessary taking classwide objects?

These can be implemented in terms of abstract primitive operations. I
presume it is allowed.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: About 0Y interfaces

[Randy Brukardt]

"Pascal Obry" <pascal@obry.net> wrote in message
news:43552495.2050300@obry.net...
> Alex,
>
> > Firstly, interfaces are purely abstract, right? There's no way to
> > provide a default/partial implementation except creating an object type
> > which implements that interface.
>
> Right.

Correct. Interfaces are cheaper than full multiple inheritance, because
nothing concrete comes from them. You cna almost think of them as a
"property" of a tagged type -- it either has the interface (and thus
promises to have implementations of the primitive operations of the type) or
it doesn't.

> > Secondly, we can create an object type which implements two or more
> > interfaces.
>
> Right.
>
> > But I guess there's no multiple inheritance from classes, so
> > you couldn't use two implementations of two different interfaces
> > directly when creating a new type.
>
> There is no notion of interface implementation. Interfaces are inherited
> by a tagged object and implemented at this point.

You mean "tagged type". They also can be implemented by a task type or a
protected type. In all cases, the concrete operations either or are declared
at this point, or (in the case of a tagged type) are inherited from the
parent.

Personally, I find implementation inheritance to be more useful than
interface inheritance, but obviously others feel differently. And, in any
case, interfaces allow using OOP with tasks and protected types, which
wasn't a possibility in Ada 95.

                           Randy.

Re: About 0Y interfaces

[Brian May]

>>>>> "Randy" == Randy Brukardt <randy@rrsoftware.com> writes:

    Randy> Personally, I find implementation inheritance to be more
    Randy> useful than interface inheritance, but obviously others
    Randy> feel differently. And, in any case, interfaces allow using
    Randy> OOP with tasks and protected types, which wasn't a
    Randy> possibility in Ada 95.

How?

(yes... ok... my imagination is limited tonight...)
-- 
Brian May <bam@snoopy.apana.org.au>

Re: About 0Y interfaces

[Pascal Obry]

Randy,

>>There is no notion of interface implementation. Interfaces are inherited
>>by a tagged object and implemented at this point.
> 
> 
> You mean "tagged type". 

Right.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: About 0Y interfaces

[Randy Brukardt]

"Brian May" <bam@snoopy.apana.org.au> wrote in message
news:sa4irvtlvr3.fsf@snoopy.microcomaustralia.com.au...
> >>>>> "Randy" == Randy Brukardt <randy@rrsoftware.com> writes:
>
>     Randy> Personally, I find implementation inheritance to be more
>     Randy> useful than interface inheritance, but obviously others
>     Randy> feel differently. And, in any case, interfaces allow using
>     Randy> OOP with tasks and protected types, which wasn't a
>     Randy> possibility in Ada 95.
>
> How?
>
> (yes... ok... my imagination is limited tonight...)

Task types and protected types can inherit from interfaces. There are rules
for matching operations declared in those types with the primitive
operations of the interfaces (it's called "implemented by..."). And of
course, all of the OOP things work on Interface'Class. In addition,
dispatching procedure calls can be used as an entry in timed and conditional
entry calls, and ATC. This gives the effect of dispatching entry calls
without having to have such a construct.

In addition, there are specific kinds of interfaces (task interfaces,
protected interfaces, synchronized interfaces [for which the implementation
must be a task or protected type]); they guarentee that the concrete type is
the right kind of thing.Task interfaces can be used as a task (in an abort
statement, the prefix of 'Completed and 'Terminated, and in the task id
package).

What you can't do is derive from a task or protected type that has an
interface. That is, there is no implementation inheritance, only interface
inheritance. We had looked at ways to provide implementation inheritance for
protected types, but they suffered from real problems of composition. We
eventually concluded that interface inheritance works fine, and it is quite
useful by itself, so that's what was provided. The advantage of avoiding any
implementation inheritance is that all of the locking code for a PT is
located in one place -- so analyzing its correctness (and applying
optimizations) can be done simply by reading the code (no hidden magic).
Determining that a PT has the correct behavior is quite difficult without
any inheritance; it would be nearly intractable with it.

How long it will be before compilers provide all of this is another
question. I suspect that it will be a fairly low priority for many
implementers.

                          Randy.

Re: About 0Y interfaces

[Alex R. Mosteo]

Randy Brukardt wrote:
> "Brian May" <bam@snoopy.apana.org.au> wrote in message
> news:sa4irvtlvr3.fsf@snoopy.microcomaustralia.com.au...
> 
>>>>>>>"Randy" == Randy Brukardt <randy@rrsoftware.com> writes:
>>
>>    Randy> Personally, I find implementation inheritance to be more
>>    Randy> useful than interface inheritance, but obviously others
>>    Randy> feel differently. And, in any case, interfaces allow using
>>    Randy> OOP with tasks and protected types, which wasn't a
>>    Randy> possibility in Ada 95.
>>
>>How?
>>
>>(yes... ok... my imagination is limited tonight...)
> 
> 
> Task types and protected types can inherit from interfaces. There are rules
> for matching operations declared in those types with the primitive
> operations of the interfaces (it's called "implemented by..."). And of
> course, all of the OOP things work on Interface'Class. In addition,
> dispatching procedure calls can be used as an entry in timed and conditional
> entry calls, and ATC. This gives the effect of dispatching entry calls
> without having to have such a construct.
> 
> In addition, there are specific kinds of interfaces (task interfaces,
> protected interfaces, synchronized interfaces [for which the implementation
> must be a task or protected type]); they guarentee that the concrete type is
> the right kind of thing.Task interfaces can be used as a task (in an abort
> statement, the prefix of 'Completed and 'Terminated, and in the task id
> package).
> 
> What you can't do is derive from a task or protected type that has an
> interface. That is, there is no implementation inheritance, only interface
> inheritance. We had looked at ways to provide implementation inheritance for
> protected types, but they suffered from real problems of composition. We
> eventually concluded that interface inheritance works fine, and it is quite
> useful by itself, so that's what was provided. The advantage of avoiding any
> implementation inheritance is that all of the locking code for a PT is
> located in one place -- so analyzing its correctness (and applying
> optimizations) can be done simply by reading the code (no hidden magic).
> Determining that a PT has the correct behavior is quite difficult without
> any inheritance; it would be nearly intractable with it.
> 
> How long it will be before compilers provide all of this is another
> question. I suspect that it will be a fairly low priority for many
> implementers.

I already implemented an interface using tasks and protected types with 
Gnat GAP. I was quite surprised that it worked already...