Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!esquire!yost
From: yost@esquire.UUCP (David A. Yost)
Newsgroups: comp.lang.eiffel
Subject: Re: Interesting problems to try in Eiffel
Message-ID: <1733@esquire.UUCP>
Date: 19 Jan 90 15:30:52 GMT
References: <1721@novavax.UUCP> <631@enea.se> <228@eiffel.UUCP> <1731@esquire.UUCP>
Reply-To: yost@esquire.UUCP (David A. Yost)
Organization: DP&W, New York, NY
Lines: 77

In article <1731@esquire.UUCP> yost@esquire.UUCP (David A. Yost) (I) wrote:
>
>  -- a class inheriting from this one is able to
>  -- consume characters from a CHAR_SOURCE and parse
>  -- them into a valid value for the object.
>
>  class HAS_IN_FEATURE export
>     in
>  feature
>
>     in (f: CHAR_SOURCE) is
>           -- get a string of characters from f
>           -- which represent a valid value for the object
>           -- and set the features of the object accordingly
>        deferred
>        end; -- value
>
>  end -- class HAS_IN_FEATURE

>  deferred class INPUT [ T -> HAS_IN_FEATURE ] export
>      value, itsname, read
>  feature
>
>     value: T;
>     itsname: STRING;
>
>     Create (str: STRING, x: T, tbl: HTABLE [INPUT, STRING]) is
>        do
>           value := x;
>           itsname := str;
>           tbl.put (Current, str);
>        end;
>
>     read (f: CHAR_SOURCE) is
>        require
>           not f.Void
>        do
>           value := T.in (f);
>        end; -- read
>
>  end -- class INPUT

>Notes:
>
>1.  The C library has fprintf and sprintf which do
>    the same output formatting to either a file or a
>    string, a rudimentary kind of polymorphism.  My
>    CHAR_SOURCE class proposed here is the input
>    equivalent of that, rendered in an OO context.
>    That is, there is a class of object that can supply
>    characters.  This could be a file or a string or
>    some other data structure.  There should also be
>    a CHAR_DESTINATION (or some other name) class to
>    serve the same purpose on output.  These would
>    greatly facilitate writing reusable code that does
>    I/O.  This approach would lead to some rethinking
>    of the I/O in the Eiffel library.
>
>2.  I don't know offhand how you would implement the
>    'in' feature of class HAS_IN_FEATURE class in my
>    example.

I forgot to mention some other points.

1.  This notion of an "in" function is similar in
    purpose to the recently-added Eiffel "out" feature.

2.  The heirarchy of built-in and library classes
    would have to be changed so that most classes
    inherit it and implement it.  For instance,
    my example assumes that it is implemented in
    INT, REAL, and STRING.

3.  My class INPUT should not have been deferred.

 --dave yost
   yost@esquire.dpw.COM