At 6:52 PM -0800 3/10/06, Roger Binns wrote:
Only for some applications. It would be harder to use for
my apps. Specifically manifest typing as currently implemented
in SQLite is a perfect match for apps writen in Python (which
also uses manifest typing). It would require a lot more code
to go through and force the data type for each column.
If that is so, then I would argue that any need to write more code
isn't tied to manifest typed programming languages themselves, but
specific programs themselves; depending on how you code your
applications, it wouldn't require any significant amount more code.
In fact, particularly for queries (and reading data tends to be more
common than writing), there should be less code. Or, looking at this
another way, perhaps the Python bindings for SQLite should be taking
care of this for you. Or, put another way, I would say this is a
small price to pay for what is gained. Or, I doubt there actually is
more work.
(But I don't really want to get into an argument on this point, as
there are many other points in my proposal which I see as being of
greater importance.)
But regardless, I have an additional idea which may help bridge the
gap and work well for people.
That is, while the database itself is strongly typed, you can have a
specific type which is defined to manifestly be able to store values
from any of a variety of simpler types.
So for example, SQLite could have these types:
- Boolean
- Integer
- Real
- Text
- Blob
- Scalar
The first 5 are simple types that store just numbers or text or whatever.
The last, new 1, Scalar, is an actually-strong type which is defined
as being able to store any of the first 5 types (just one at a time),
and hence acts like a weak type.
In a conceptual sense, a Scalar value is like a composite type with 6
member elements, each of the last 5 being strongly typed as one of
the first 5 simple types, and the first element being an enum which
says which of the other 5 holds the over-all current value.
I believe something like this is what manifestly typed languages
actually do behind the scenes, having a multi-element struct where
one element says how to treat the other one(s). I know Perl does
this, with its SV C-struct, and I'm sure other languages do similar.
I know SQLite does something similar, if you look at its design spec.
(Sure, that sounds more complicated, but then the actual work being
done to support manifest typing *is* more complicated. Things look
more like they are.)
So if SQLite does it this way, then you can declare columns to be the
Scalar type when you want them to hold anything, and one of the other
types if you don't. Moreover, the effectively manifest typed Scalar
is what you would get if you don't explicitly declare a type for a
column. This happens already, but now the "what you get" actually
has a name.
The point is that you still get well defined behaviour that is
specific to the declared data type(s) you choose to use, and you can
count on its being consistent.
-- Darren Duncan
