Interface to aggregated type

Interface to aggregated type

[ms]

My question is half-ada/half-architectural, I'll explain it on simple HTTP server example.

Imagine HTTP library providing two packages - `Headers` which provides container for HTTP headers (`Header_Container` type) and `Requests` which is a abstraction over HTTP request message (`Request` type).

Clearly `Request` aggregates `Header_Container`, as HTTP requests generally contain some set of headers.

My dilemma is - `Headers` package already provides some sort of `Header_Container` manipulation interface - procedures for inserting and deleting headers and functions to return them, but I want allow these operations also on container aggregated inside `Request` type (which is probably a private record).

Now I have several options such as duplicating header manipulation interfaces entirely (eg. function Header_Value (R : Request, Name : String) in `Requests` package) or making aggregated `Header_Container` field public (can I make only some of the record's fields public and leave others private?). Both have pros and cons, and possibly even more solutions exist.

What would you do?

Re: Interface to aggregated type

[Dmitry A. Kazakov]

On Mon, 6 Aug 2012 11:42:03 -0700 (PDT), ms wrote:

> Clearly `Request` aggregates `Header_Container`, as HTTP requests
> generally contain some set of headers.
> 
> My dilemma is - `Headers` package already provides some sort of
> `Header_Container` manipulation interface - procedures for inserting and
> deleting headers and functions to return them, but I want allow these
> operations also on container aggregated inside `Request` type (which is
> probably a private record).

If Request implements the interface of Header_Container and also aggregates
it, why don't you derive one from another?

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

Re: Interface to aggregated type

[ms]

On Monday, August 6, 2012 9:43:22 PM UTC+2, Dmitry A. Kazakov wrote:
> On Mon, 6 Aug 2012 11:42:03 -0700 (PDT), ms wrote:
> 
> 
> 
> > Clearly `Request` aggregates `Header_Container`, as HTTP requests
> 
> > generally contain some set of headers.
> 
> > 
> 
> > My dilemma is - `Headers` package already provides some sort of
> 
> > `Header_Container` manipulation interface - procedures for inserting and
> 
> > deleting headers and functions to return them, but I want allow these
> 
> > operations also on container aggregated inside `Request` type (which is
> 
> > probably a private record).
> 
> 
> 
> If Request implements the interface of Header_Container and also aggregates
> 
> it, why don't you derive one from another?
> 
> 
> 
> -- 
> 
> Regards,
> 
> Dmitry A. Kazakov
> 
> http://www.dmitry-kazakov.de

This is one of these "how did I missed that" ideas. Thanks!

Re: Interface to aggregated type

[Marius Amado-Alves]

Don't duplicate. Not here. Not needed. Make distinct packages HTTP.Headers, HTTP.Request_Messages, etc. Top package HTTP may have common things e.g. a root type for messages, or may be empty; HTTP.Request_Messages uses (withens) HTTP.Headers; you can make a type T1 with public and private fields easily using type extension(maybe there are other ways):

   type T0 is tagged
      record
         <public fields>
      end record;

   type T1 is new T0 with private;
private
   type T1 is new T0 with
      record
         <private fields>
      end record;