Backward compatibility (Was: Re: global_name_server question.)

patrickdlogan@REDACTED patrickdlogan@REDACTED
Thu Jun 3 11:32:48 CEST 1999

Peter Olin writes:
 > There are many places in OTP where errors are "signalled" this
 > way...
 > "Backwards compatibility" has been the often mentioned reason for
 > keeping a lot of the inconsistencies in the OTP libraries, but I
 > really don't think that's an argument.
 > What's the "public opinion" on revising and rewriting interfaces so
 > that functions have some consistent use of "types", return values,
 > EXIT reasons, etc.? There are many ways of keeping the system
 > backwards compatible, without actively preventing improvements
 > where there is a need for them. (New names for revised modules,
 > forwarding of calls, compiler warnings, etc)

I don't have a lot of legacy code yet, so I am not too concerned
either way. In general I am willing to put up with some cruft in the
name of backward compatibility, as long as the fix is available
alongside the older stuff one way or another. I'd rather we not all
fix it ourselves N different ways.

That said, here is one cute way to fix it for now...

Assert = fun({ok, Result}) -> Result end.

copy1(File1, File2) ->
    file:write_file("dot_login", Assert(file:read_file(".login"))).

Patrick D. Logan        mailto:patrickdlogan@REDACTED

More information about the erlang-questions mailing list