A non-normative tweak involving the type name ICloneable

[RexJaeschke]

There is a CLI library type ICloneable, and the CLI declares System.Array, System.Delegate, and System.String as implementing that interface. However, the C# spec does not declare any of this. OK, no problem.

The C# spec contains 18 uses of a type of the name ICloneable, all of them in (non-normative) examples. Again, OK, no problem!

However, the first use of that type (§18.5, Qualified interface member names) contains the following:

When an interface is part of a namespace, a qualified interface member name can include the namespace name.

Example:

namespace System
{
    public interface ICloneable
    {
        object Clone();
    }
}

Within the System namespace, both ICloneable.Clone and System.ICloneable.Clone are qualified interface member names for the Clone method.

end example

The fact that this type is declared in namespace System, that supposedly sacred place for non-user-defined types, seems wrong. In any event, this section has nothing whatsoever to do with cloning, so why not remove the potential confusion that there is/might be a standard library type of this name?

(All other occurrences of this type are not used in the context of namespace System.)

How about we use instead an interface type that is required by the C# spec, as follows?

Example:

namespace System
{
    public interface IDisposable
    {
        object Dispose();
    }
}

Within the System namespace, both IDisposable.Dispose and System.IDisposable.Dispose are qualified interface member names for the Dispose method.

end example

[Nigel-Ecma]

Yes & no ;-)

Changing the example from IClonable is a good idea, but why change it to another defined type at all? It is an example, just make up names for the namespace, interface and method so there is no reason to read anything else into the example.

I’m no imagineer as my brain straightway came up with Materials, Cardboard & Recycle showing a clear (green) link to Dispose; I’m sure others will do better!