design changes per Ada 2005/12?

design changes per Ada 2005/12?

[tmoran]

Randy,
A lot of Claw used/tested new Ada 95 features.  What would you *design*
differently with Ada 2005 or 2012?  (Not syntactic sugar).

Similar question to other folks.

Re: design changes per Ada 2005/12?

[Lucretia]

On Apr 22, 12:05 am, tmo...@acm.org wrote:
> Randy,
> A lot of Claw used/tested new Ada 95 features.  What would you *design*
> differently with Ada 2005 or 2012?  (Not syntactic sugar).
>
> Similar question to other folks.

Interfaces if the FSF GNAT doesn't produce an ICE.

Luke.

P.S: The containers should've used interfaces!

Re: design changes per Ada 2005/12?

[Shark8]

On Apr 21, 8:10 pm, Lucretia <Lucretia9...@yahoo.co.uk> wrote:
> On Apr 22, 12:05 am, tmo...@acm.org wrote:
>
> > Randy,
> > A lot of Claw used/tested new Ada 95 features.  What would you *design*
> > differently with Ada 2005 or 2012?  (Not syntactic sugar).
>
> > Similar question to other folks.
>
> Interfaces if the FSF GNAT doesn't produce an ICE.
>
> Luke.
>
> P.S: The containers should've used interfaces!

Indeed they should have.
It really is too bad that they chose to emulate Java-style interfaces
rather than
Delphi-style interfaces; with Delphi's properties you can have a
'field' of an
object which can be calculated (a procedure or function) or a renaming
of an
internal field, for both reading and writing to the property. Read-
only and
write-only properties are also do-able.

Re: design changes per Ada 2005/12?

[Randy Brukardt]

<tmoran@acm.org> wrote in message news:ioqd7m$vtt$1@speranza.aioe.org...
> Randy,
> A lot of Claw used/tested new Ada 95 features.  What would you *design*
> differently with Ada 2005 or 2012?  (Not syntactic sugar).

Well, obviously we would have used overriding indicators from the beginning. 
(No surprise there, the indicators were one the first Ada 2005 features --  
they got added in part because of a hard push I made because of my Claw 
experience.) We would have used "private with" a lot, too. Both of these are 
time-comuming to retrofit, but they wouldn't have changed the design a lot.

I would have liked to have been able to make some or all of the types 
limited; one reason we didn't do that was the loss of the function syntax. 
Had we done that, we would have spent less time trying to get finalization 
to work right (the "clone" semantics is complicated to implement, and not 
that easy to work with, either).

For Ada 2012, I would have definitely used the iterators to walk lists. 
Probably also would have used some of the contract features (preconditions, 
etc.) although they don't work well in the Claw model (where objects can 
change state asynchronously to the program).

I'm sure there is other stuff that would have helped in specific cases (null 
exclusions come to mind), but I don't think the design would have been 
wildly different. I don't think we would have used any interfaces, for 
instance.

                         Randy.

Re: design changes per Ada 2005/12?

[Randy Brukardt]

"Lucretia" <Lucretia9000@yahoo.co.uk> wrote in message 
news:49b85caa-700c-44c8-8a11-2f512083aca5@r6g2000vbz.googlegroups.com...
...
>P.S: The containers should've used interfaces!

We tried that with the new Queue containers, and IMHO it is a disaster. You 
have to use an extra instantiation and extra formal parameters for a feature 
that you are not going to use on 90% of the programs. (Typically, you only 
use one kind of queue in a program.)

The introduction of the interfaces also forced a horrible structure which 
requires the implementation to declare all of its internal data structures 
in a *visible* nested package. (This is partially the fault of protected 
types, which don't allow nested types for good reasons -- but if we didn't 
have the interface we could hide the protected type in the private part.)

Some of this could be fixed with substantial violence to the Ada visibility 
and implementation models, but it is not clear that what you would end up 
with be Ada. Not likely to happen, and surely not before Ada 2020.

                                   Randy.

Re: design changes per Ada 2005/12?

[Dmitry A. Kazakov]

On Fri, 22 Apr 2011 19:41:59 -0500, Randy Brukardt wrote:

> "Lucretia" <Lucretia9000@yahoo.co.uk> wrote in message 
> news:49b85caa-700c-44c8-8a11-2f512083aca5@r6g2000vbz.googlegroups.com...
> ...
>>P.S: The containers should've used interfaces!
> 
> We tried that with the new Queue containers, and IMHO it is a disaster. You 
> have to use an extra instantiation and extra formal parameters for a feature 
> that you are not going to use on 90% of the programs. (Typically, you only 
> use one kind of queue in a program.)

Yes, I have same experience. Interfaces do not work good with generics,
which should not surprise anybody.

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

Re: design changes per Ada 2005/12?

[Maciej Sobczak]

On Apr 23, 8:44 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> Yes, I have same experience. Interfaces do not work good with generics,
> which should not surprise anybody.

Agree here. This approach seems to be bearable in Java, where standard
collections (java.util.*) are all both generics and interface-based,
but I think this is because all this Java stuff is more dynamically
than statically typed. On the user perspective, the benefits of these
interfaces are close to zero and the very few potential advantages
(like the ability to change the concrete collection type without
modifying all user code) are more results of Java not having type
aliasing (typedefs or renamings) features.

C++ uses non-interface approach and I have never seen a situation
where this was an issue. Ada got it right, too.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: design changes per Ada 2005/12?

[Lucretia]

On Apr 23, 1:41 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> "Lucretia" <Lucretia9...@yahoo.co.uk> wrote in message
>
> news:49b85caa-700c-44c8-8a11-2f512083aca5@r6g2000vbz.googlegroups.com...
> ...
>
> >P.S: The containers should've used interfaces!
>
> We tried that with the new Queue containers, and IMHO it is a disaster. You
> have to use an extra instantiation and extra formal parameters for a feature
> that you are not going to use on 90% of the programs. (Typically, you only
> use one kind of queue in a program.)

Things like iterators could be implemented with interfaces ok.

Luke.

Re: design changes per Ada 2005/12?

[Randy Brukardt]

"Lucretia" <Lucretia9000@yahoo.co.uk> wrote in message 
news:524ddf9b-2727-461a-b14b-e2171cf61190@dn9g2000vbb.googlegroups.com...
On Apr 23, 1:41 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> "Lucretia" <Lucretia9...@yahoo.co.uk> wrote in message
...
>> We tried that with the new Queue containers, and IMHO it is a disaster. 
>> You
>> have to use an extra instantiation and extra formal parameters for a 
>> feature
>> that you are not going to use on 90% of the programs. (Typically, you 
>> only
>> use one kind of queue in a program.)
>
>Things like iterators could be implemented with interfaces ok.

And indeed they are (see AI05-0139-2). But it is interesting that iterators 
were the only example where interfaces worked. We tried and discarded models 
using interfaces for both implicit dereferencing and indexing, because they 
either ended up as nothing more than a marker (which can be accomplished in 
a straightforward way without using any interfaces), or because they 
required violating visibility/overloading rules.

                                        Randy.