🚀 go-pugleaf

In article <18296@cs.yale.edu> jellinghaus-robert@CS.Yale.EDU (Rob Jellinghaus) writes:
>A short while ago, I attempted to post an article in which I decried Eiffel's
>lack of a class which would allow me to store and retrieve objects from 
>memory, rather than to/from a file.  I am attempting to integrate Eiffel with
>a networking utility, and I want to be able to store arbitrary Eiffel objects
>in a structure which can be passed between machines.  The STORABLE class does
>what I want to do, but it can only read or write to disk, not to a buffer in
>memory.

A while back, I proposed that there should be
"CHAR_PRODUCER" and "CHAR_CONSUMER" deferred classes,
and that all I/O should go through them.  So, for
instance, the FILE class would inherit from these,
and all the getint, putint, etc. features of FILE
would be taken out and put where they belong, in
their respective classes (INTEGER, for getint putint),
where they would take a CHAR_PRODUCER or CHAR_CONSUMER
argument as appropriate.  (I think the FILE class needs
a lot of changes.)

This suggestion bears on your point, I think.  It
implies that STORABLE should have only one store
feature instead of the present 3 variants, one each for
storing to a filename, a FILE object, or a unix file
descriptor.  This one store feature would simply take
a CHAR_CONSUMER argument.

It seems clear to me that STRING should inherit from
CHAR_CONSUMER, and either it or another similar class
that acts only as an array of CHARACTERs (without all
the text manipulation features) should be capable of
absorbing your entire STORABLE (growing dynamically
as necessary).

The retrieve features of STORABLE should be changed
along similar lines.

 --dave yost
   yost@dpw.com or uunet!esquire!yost
   Please ignore the From or Reply-To fields above, if different.