Re: Ada OOP alternatives?

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"(see below)" <yaldnif.w@blueyonder.co.uk> writes:

> On 17/07/2008 02:36, in article wccy741fg0z.fsf@shell01.TheWorld.com,
> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote:
>
>> "(see below)" <yaldnif.w@blueyonder.co.uk> writes:
>> 
>>> On 17/07/2008 01:05, in article wcc3am9gytt.fsf@shell01.TheWorld.com,
>>> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote:
>>>> I'd still rather eliminate private parts altogether.
>>> 
>>> How would you do that while allowing ADT clients to access objects directly
>>> (i.e. not via a pointer a la Java)?
>> 
>> I'd have the compiler take a peek at the body when compiling the client.
>> After all, that's what Ada compilers already do for pragma Inline.
>
> Good point.
> That does induce a bit more compile-time overhead, though, as all clients
> would have to be recompiled on every update to the body.

That's why I mentioned incremental compilation.

I find that all too often, I have to recompile the world because I
changed a private part, or I changed a generic body.  That shouldn't be
the case.  I shouldn't have to recompile the world if I add a
new procedure to a visible part, either (which is tricky to get
right in the presence of overloading and use clauses!).

Unless computers get a lot faster than they are, any compiler needs at
least two modes:

    debug mode -- fast compilation, poor optimization, good debugging

    production mode -- slow compilation, fast generated code, confused
    debugger

In debug mode, I'd treat sizes of private types as dynamic (i.e. don't
peek at the body).  In production mode, peek at the body.

And I'd redesign generics so they aren't semantically based on macro
expansion.  In debug mode, the compiler would not have to look at
generic bodies when compiling clients that use the generics.  In
production mode, the compiler could duplicate code for some instances --
sort of like the way inlining works in Ada.  Possibly the compiler
could guess when to duplicate code, or possibly have a pragma to
give hints, or possibly both.

>> And I think incremental compilation can be a big win.
>> In fast-compile mode, I might tolerate the "via pointer" way.
>> It doesn't need to be a pointer into the heap, as in Java.
>> 
>> We're just talking about the size of the type, really -- you say
>> "access objects", but clients can't access the record components
>> of a private type -- all they can do is declare objects and
>> pass them around.
>
> And copy them.

Right.  But the compiler doesn't need to know the size to generate the
code for copying.  After all, we already have dynamic sizes:

    X : String (1..Read_From_Keyboard(...));

and ":=" works.

"=" also needs to know the size -- again, not necessarily at compile
time.

> Yes, but to do that well, they need to know at least the size of the
> representation.

Right -- "do that well" = what I called "production mode" above.

In production mode, the compiler would know the size (unless it truly is
dynamic).  But with incremental compilation, it still doesn't mean
recompiling the world when that body changes -- only when the size
actually changes.

Representation clauses and pragma Pack present some
interesting issues. ;-)

>> Java, like many languages, doesn't even _have_ separate specs.
>> (And it _still_ insists on pointers for almost everything!)
>
> I loathe the Java type system's incoherence.
>
>> So it's clearly feasible to have information in bodies used
>> when compiling clients.
>
> Certainly.
>
> To what extent do you think that the (optical) visibility of the
> representation in the Ada private part offsets a need to give the client's
> programmer a more formal statement of the semantics of the ADT?

I think the optical visibility is not a big deal.  But I want all
implementation details (including what's now in the private part) stored
in a separate file from the visible part, so it can be managed
separately in the CM system.  I want to be able to ask "did the
interface of so-and-so change since last week?".

Suppose I need a package that does something different on windows
vs. unix.  Ideally, I'd like the interface to be the same, and hide the
differences in the body -- i.e.  have two versions of that body.  But
Ada forces some of those differences to appear in the private part,
which means two copies of the spec file, which means it's hard to ensure
that the interfaces are indeed identical.  And it causes evil code
duplication.

- Bob