Re: goops/guile doc (was Re: Simple example program to illustrate Goops)

[Gary Houston <ghouston at arglist dot com>]

> From: Jim Blandy <jimb@red-bean.com>
> Date: 27 Feb 2000 22:04:02 -0500
> 
> This has more practical consequences, too.  For example, folks were
> just talking about binary I/O functions, and it was pointed out that
> it makes sense to apply them not only to streams, but also to strings,
> byte arrays, hypothetical pointer types, and so on.
> 
> Well, suppose we defined generic functions `fetch' and `store'.  Then
> suppose we define a GOOPS class <representation>, which has elements
> like 16-bit-be-unsigned-int ("be" == "big-endian"), 32-bit-le-signed-int,
> 64-bit-ieee-float, and so on.

Do you mean 16-bit-be-unsigned-int is a class that inherits from
<representation>?

> Then we could define methods like
> 
>    (fetch <representation> <string>)
> 
> to be one set of fast primitives, written in C, and
> 
>    (fetch <representation> <port>)
> 
> to be another set of fast primitives, written in C.  Then we just let
> the GOOPS dispatch choose the right function for the particular
> representation and data source.

I'm not convinced.  Wouldn't you want an offset argument for the
string/vector version?  Otherwise the doesn't seem to be much
advantage in a separate implementations for these cases: it may be
more convenient to wrap the string/byte-vector in a port than to use
substrings or whatever to select the position.

cf. read-char vs string-ref, which is the same thing.