thomas.beale's blog

blog Annoying basics that should work better

thomas.beale's picture

There are some basic problems with serialisation of basic data types that need compensating classes and dependencies that make it hard to separate out and share library code.

I have in a utility class the following code, which compensates for missing / broken functionality right at the data types level of Eiffel:

serialise_primitive_value (a_prim_val: ANY): STRING
        -- generate a correctly serialised string for any primitive value, making corrections for
        -- broken serialisations of DATE_TIME, DATE_TIME_DURATION and REAL
    do
        -- FIXME: duration.out does not exist in Eiffel, and in any case would not be ISO8601-compliant
        if attached {DATE_TIME_DURATION} a_prim_val as a_dur then
            Result := (create {ISO8601_DURATION}.make_date_time_duration(a_dur)).as_string
        elseif attached {DATE_TIME} a_prim_val as a_dt then
            Result := (create {ISO8601_DATE_TIME}.make_date_time(a_dt)).as_string
        else
            Result := a_prim_val.out
            -- FIXME: REAL.out is broken (still the case in Eiffel 6.6)
            if (attached {REAL_32} a_prim_val or attached {REAL_64} a_prim_val) and then Result.index_of ('.', 1) = 0 then
                Result.append(".0")
            end
        end
    end
The first two branches compensate for the wrong behaviour of DATE_TIME_DURATION and DATE_TIME 'out' feature, which return respectively a non-ISO8601 duration string, and a (useless) US-style date/time string. In both cases, I think it's pretty much globally accepted these days that the output should be ISO8601-based. At the moment I have to suck in my ISO8601 library to do this.

The 3rd branch deals with the problem that when a REAL is serialised to string, if it happens to be integral in value, there is no '.0' included. I rely in the ODIN library on consistent syntax of basic types, both on input and output. So ODIN parses values like 3.14 and 3.0 as Reals, but it will parse 3 as an Integer. I can't remember what the Eiffel compiler does, but I think it's the same. In ODIN, any Real is output to string form with a decimal point and a digit to the right, which means the round-trip is symmetric. Eiffel's 'out' routine for Real doesn't, and that breaks ODIN.

These hacks are needed quite deep in my libraries, not just in ODIN. For example, I have a some Interval library classes, based on a parent class INTERVAL [G->PART_COMPARABLE] which are commonly used with Reals and date/times. INTERVAL has an out routine that would serialise instances of types like INTERVAL [REAL] and INTERVAL [DATE], if only the 'out' routines of those types were not broken.

Problems like this force me to have annoying extra classes and dependencies I don't want, thus gluing up libraries that could otherwise be separated out and shared freely. I can't be the only one in this situation.

Is there any prospect of things like this ever being fixed?

blog Object Data Instance Notation - ODIN library

thomas.beale's picture

In the openEHR (EHR = Electronic Health Record) project, we use a serialisation that is called ODIN, an alternative to JSON, XML etc. It was developed before JSON existed, and is more comprehensive (particularly in terms of leaf types). It is also (in my view) easier to read. It's certainly easier to write (in JSON, [] and "" will eventually drive you crazy).

blog New Eiffel Technology Community - getting started

thomas.beale's picture

I am leading a workshop on Monday 27 June 2011, at TOOLS 49 in Zurich on the idea of developing a worldwide New Eiffel Technology Community. The idea is that languages that survive like Java and Ruby today don't depend on the qualities of the language, but on the qualities of the 'technology stack', i.e.

Syndicate content