Re: Type conversion (Was: Brain Dump of Towards FIT 1.0OpenSpace session)

----- Original Message ----- 
From: "Jim Little" <[email protected]>
To: "'FIT Developers'" <[email protected]>
Sent: Friday, August 22, 2003 2:09 PM
Subject: Type conversion (Was: [Fit-dev] Brain Dump of Towards FIT
1.0OpenSpace session)


> From: [email protected]
> > at one point I thought of pushing type conversion to the
> > Fixtures themselves; the fixtures, after all, know what's
> > needed better than some global framework. It's still an
> > idea that has a bit of an appeal.
>
> That's kind of how the C# version works.  Type conversion seems to be
> the area that differs most across languages.  For the C# version, we
> actually ripped out the TypeAdapter class entirely (almost).
>
> In C#, most data types have Parse() and ToString() methods that convert
> between strings and data types.  So what we do in C# is say that the
> fixture has to accept and return data types that will implement Parse()
> and ToString() properly.  Coincidentally, all of the normal types that
> people use do.  We then use reflection to handle the string conversion.
>
> This is a nicely elegant solution.  It takes parsing out of TypeAdapter
> and fixtures and puts it in the data type where it belongs.
>
> But I can't see how this would work in a language without manifest
> types.  How do the other ports deal with type conversion?

The currently distributed Python version (due to Simon Michael)
uses the Python RExec feature, which is a security version of the
eval() function. This quit working (the Python team intentionally
disabled it) in Python 2.2.3 and 2.3. There is a three line fix that
I can distribute until we can get the actual distribution fixed.

The new version I'm working on has an oracle (a dictionary)
in each fixture that the framework can query to find the proper
type for each function.

I like your idea, but it only half works for Python. All of Python's
builtin types and classes have a __str__() method (used by the
str() builtin function) that is supposed to return a human readable
version of the type, so in principle I don't even have to know
the type of what I'm dealing with.

Unfortunately, that doesn't work going the other way. Now that
you mention it, I might write a PEP to add a __parse__ method
to all of the standard functions, but even if everyone thinks it's
a great idea, it would be a while before it happens.

Also, __str__() doesn't always return what's needed. One of
the major issues is, of course, floating point compare precision,
which I have covered with a special entry in my type dictionary.

John Roth

>
> Jim
>