Cook Computing

Eiffel classes are grouped in clusters. These seem to roughly correspond to .NET assemblies. To enable the classes in a project to be packaged in an assembly for use from other .NET languages a cluster namespace is defined in the project properties. The classes in the assembly then belong to this namespace.

The contents of an assembly is more complicated than you would initially expect. Because of the difference in object models between Eiffel and the CLR, for each Eiffel class there are two classes and an interface in the generated assembly. For example if you implement an Eiffel class called Quux, the assembly contains an interface called Quux and classes Create.Quux and Impl.Quux.

The interface is the type by which the Eiffel class is referred to, for example when defining a variable to refer to an instance of the class or defining a method parameter:

Quux quux;
void UseQuux(Quux q) { /* ... */ }

Creation of a class instance in Eiffel involves creating an instance of the class and then initializing it via a creation procedure. There can be more than one creation procedure for a class and they do not have special names. Therefore it is not possible to generate overloaded constructors as in the CLR. To handle this the Create class generated in the assembly contains a static method for each of the creation procedures. For example if the Eiffel class Quux contains a creation procedure called make it would be called like this in C#:

Quux quux = Create.Quux.Make();

The second class Impl.Quux is, as the name suggests, the implementation of Quux. This is the type that is actually instantiated by the Create method. It also is the type to derive from, for example:

class ChildQuux : Impl.Quux
{
// ...
}

Its not surprising that RSS 2.0 has been a bit of a fiasco over the last few days. The spec does not mention anything about the http://backend.userland.com/rss2 namespace although the linked sample 2.0 file includes it. Normally I would tend to give more weight to the actual specification than sample files but its anyone's guess in this case.

On the other hand the spec doesn't mention backwards compatibility so there's no reason to expect that aggregators expecting 0.91 or 0.92 RSS files should have continued to work. This suggests it would have been more appropriate for Userland to set up separate feeds for 2.0 than to suddenly starting outputting completely incompatible XML documents on the existing feeds.

I don't understand why the new namespace is required (if backwards compatiblity is important). An XML document can have some elements affiliated to namespaces yet with others unaffiliated to any namespace. My aggregator works fine with the RSS 2.0 format without the namespace and would continue to work even if elements with namespaces were added to the document. This is because it uses a fully compliant XML parser and ignores any elements it is not interested in, which includes any elements in namespaces. Maybe the default namespace was just a whimsical decision on the grounds of "if RSS 1.0 uses a default namespace, then 2.0 must also have one" without thinking through the consequences.

The whole thing about parsers not been able to cope with the default namespace was a complete red herring. It surprises me that any unmodified aggregators continued to work. They must have been ignoring that the fact that the names of all the elements had effectively been changed.

Winer is now saying: the spec is imperfect in regards to namespaces. we anticipated a 2.0.1 and 2.0.2 in the Roadmap for exactly this purpose. Really? Something as fundamental as this should have been thought through before outputting the RSS 2.0 files. This apparent lack of concern for the soundness of the spec flies in the face of his latest pronouncement: We spend huge resources to make sure that files, scripts and apps built in version N work in version N+1 without modification. Even the smallest change in the core engine can break apps. It's just not acceptable. When we make changes we have to be sure there's no breakage..

I've downloaded and installed Eiffel Envision, the Eiffel plug-in for Visual Studio. I'm planning to write a review of Envision but the first thing I attempted was to implement an XML-RPC client. I had to seek help on how to specify custom attributes but otherwise it was fairly straightforward.

indexing
    attribute: create {XML_RPC_METHOD_ATTRIBUTE}.make 
end

class MATH_PROXY inherit XML_RPC_CLIENT_PROTOCOL

feature

Add(a : INTEGER b : INTEGER) : INTEGER is
indexing
    attribute: 
        create {XML_RPC_METHOD_ATTRIBUTE}.make_from_method(
            ("math.Add").to_cil)
end
local
    args : NATIVE_ARRAY[SYSTEM_OBJECT]
    ret : INTEGER
do
    !!args.make(2)
    args.put(0, a)
    args.put(1, b)
    Result ?= Invoke(("Add").to_cil, args)   
end

end -- class MATH_PROXY

The custom attributes are specified in the indexing clauses of the class and the Add feature

attribute: create {XML_RPC_METHOD_ATTRIBUTE}.make

and

attribute: 
  create {XML_RPC_METHOD_ATTRIBUTE}.make_from_method(
    ("math.Add").to_cil)

There are some points worth noting here. First, when referring to classes in other assemblies, the name is automatically changed from typical .NET style, e.g. XmlRpcMethodAttribute, to the Eiffel style XML_RPC_METHOD_ATTRIBUTE.

Second, Eiffel does not support overloaded methods and so the XmlRpcMethodAttribute constructor taking a string parameter is renamed as "make_from_method", with the default constructor named "make".

Third, because Eiffel has its own rich framework class library, a straightforward string literal cannot be used in the XmlRpcMethodAttribute constructor: this would specify an instance of the Eiffel String class. Instead the ugly construction ("math.Add").to_cil has to be used (although the online help states that this will be unnecessary in a future release because the type of string will be determined from the context of the literal).

Interesting announcement on the Eiffel Software site: the ENViSioN .NET version of Eiffel will be a free download. To quote:

The Free Edition is targeted for students, hobbyists, and non-commercial developers who wish to be able to take advantage of the pleasure of programming in Eiffel, but who cannot justify spending a larger sum of money for features that they wont be using. The Free Edition has most of the features of the Enterprise Edition, except for some productivity-enhancing tools (EiffelBuild and auto-documentation) and commercial licensing (or ability to create a .NET signature for commercial software). Eiffel Software is pleased to provide this version as a service to all those in the world who want to be able to work with the latest from Eiffel Software.

According to the download page the release of ENViSioN is imminent.