Re: File chicken counts eggs

[eachus@spectre.mitre.org (Robert I. Eachus)]

In article <5kqku3$bch$1@netty.york.ac.uk> mek100@york.ac.uk (Mark Kambites) writes:

  > It seems that the size of my node must be known to the compiler
  > before direct_io can be instantiated, and the size of the node is
  > dependant upon the size of 'count', which is unknown UNTIL
  > direct_io HAS BEEN instantiated.

  > Surely there must be a better way of handling this than trying to
  > effectively cast backwards and forwards between count and integer
  > -- exactly the kind of thing Ada was designed to eliminate?

  First, why is this seen as such a problem?  You can use Integer, a
type with a range you specify, or Unsigned_32 or whatever make sense
to you, and the file system gets to use a unit approprite for it's
purposes.  Using a system specific index size in your code would limit
portability.

  Since the conversions needed should all be in the body of your
B-tree package, I assume that the user of the package never has to
care.  You do, but the conversion only occur in a (very) few places,
right?

   If they don't define disk and internal data structures, one before
the Direct_IO instantiation, and one after.  Now write your own Get
and Put for the internal data structures, which do the mapping then
call the Direct_IO routines.  This should run to about ten lines of
code.  Now forget about those, and write the B-tree code.

   Secnnd, imagine that Direct_IO were defined to take Count as a type
parameter.  (You can experiment with this using the GNAT version.)
The specification change is trivial and the changes in the body will
probably take only an hour or two.  But are you, or anyone, happy with
the result?  You can't supply a default, which might acutally be
useful in this case, and if the user chooses a type too small, he gets
lots of errors with no discernable benefit.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...