Thomas Lockhart wrote:
>
> > Ah, I see --- more or less make all of utils/adt/ available to be
> > linked into clients.
> > > That is a Good Idea in principle. In practice, ...
> > Yeah, it'd be a huge amount of work. For starters, all that code
> > relies on the backend environment for error
> Ah, I see --- more or less make all of utils/adt/ available to be
> linked into clients.
> > That is a Good Idea in principle. In practice, ...
> Yeah, it'd be a huge amount of work. For starters, all that code
> relies on the backend environment for error handling and memory
> management...
I
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> That is one possibility, but I think the proposal is to expose the
> *support* for the data types to client-side apps.
Ah, I see --- more or less make all of utils/adt/ available to be
linked into clients.
> That is a Good Idea in principle. In pract
> > a) The client-side programmer has to be responsible for parsing the
> > returned string, which could cause problems if the output format of the
> > ADT is changed, and
> You seem to be proposing that we instead expose the internal storage
> format of the ADT, which seems to me to be much more
At 01:49 PM 6/20/02 +0100, Tony Griffiths(RA) wrote:
>a) The client-side programmer has to be responsible for parsing the
>returned string, which could cause problems if the output format of the
>ADT is changed, and
>
>b) The impedance mismatch is much greater than that of the built-in types.
"Tony Griffiths(RA)" <[EMAIL PROTECTED]> writes:
> a) The client-side programmer has to be responsible for parsing the
> returned string, which could cause problems if the output format of the
> ADT is changed, and
You seem to be proposing that we instead expose the internal storage
format of t
