Legal Change in GPC ?_(re)

Fri, 2 May 1997 12:45:03 +0200

Christian Wendt wrote:

> PG>> not "impossible"- you only got to reinvent the wheel and write to
> PG>> $b80000... _big_ loss in portability & comfort (no easy to call writeln.
> PG>Nevertheless this will remain my preferred method in BO5.  The fastest
> PG>thing you can imagine on the DOS platform.
> hmm. is the type of "file" specified in the ISO /Extended?
> would it be possible to define it similar to TP/BP?
> there's a list of procedures inwith the file "record" - they specify the  
> functions to init/flush/writebuffer/readbuffer (theoretical you could do  
> the same with an object...)

I assume you mean BP's TFDD (Text File Device Drivers). BTW: It's for "Text",
not for typed are untyped files (though there's actually no reason why it
shoudln't apply to them, too, except that BP's doesn't).

Indeed, I'd like to have something like this in gpc, too. I'm not at all
familiar with the internals of "Text" files (or other files) in gpc.
(ISTR, it has something to do with "bindable" variables, but I don't know
much about those, either.)

First a short explanation for those not familiar with BP:

Basically, TFDDs allow the programmer to assign procedures with the following
semantics to a "Text" variable to be used instead of file I/O:

Open:  Input:  File mode (Reset / Rewrite / Extend (aka Append))

Read:  Input:  Buffer size
       Output: Actual size read (<= Buffer size); the value 0 signals an
                 EOF -- but perhaps it would be better to have a separate EOF
                 function (e.g. for things like serial ports that may have no
                 data at one time, but get some data later).
               Data that were read (in the buffer)

Write: Input:  Data in buffer
               Size

Flush: (the same as Write, except that it should additionally "physically
        flush the file", as far as that makes sense -- I can't remember any
        examples where this did anything different than Write)

Close: -

All procedures also have an "error code" as Output to signal un-/successful
completion of the operation.

The TFDD can have a local data space (in BP: up to 16 bytes, AFAIR) -- local
to the file to distinguish different "instances" of files assigned to a
particular TFDD. (Here we see the similarities to objects...)

The big advantage is that one can do a Write[ln]/Read[ln] with all its
possibilites and have the data automatically "piped" to certain routines.

Sure, one could achieve the same in gpc with WriteStr/ReadStr and passing
the string to the routines, but

(a) it's not completely as easy (2 statements instead of one),

(b) managing the "local data" would require additional effort everywhere
    this is used,
    
(c) it's not TP compatible...,

(d) a TFDD can be used transparently (e.g. a variable assigned to a TFDD can
    be passed to any procedure that wants a "Text" file).

The particular syntax (and other things) BP uses for this is, IMHO, not very
nice (it was introduced after the "good days" of Borland, but before the
introduction of OOP, which could have simplified things), so I don't vote
for copying BP's mechanism. But any way to do such things would be good.
In fact, many of my units use TFDDs, and I can't see a "good" way of porting
programs that use them to gpc (only perhaps with heavy use of the preprocessor,
but I'd not like to do it like that). I'd not complain at all if it was done
with OOP (i.e. "Text" would be an object type, the "procedure" above would be
methods, the local data would be the fields of the object), the main thing is
that the object could be used in simple Read[ln]/Write[ln] statements.

Any chances to do something like this with reasonable effort?
-- 
Frank Heckenbach, Erlangen, Germany
heckenb@mi.uni-erlangen.de
Turbo Pascal:   http://www.mi.uni-erlangen.de/~heckenb/programs.htm
Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

Frank Heckenbach (heckenb@mi.uni-erlangen.de)