dotgnu-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[DotGNU]ECMA compatible pnetlib


From: Rhys Weatherley
Subject: [DotGNU]ECMA compatible pnetlib
Date: Fri, 14 Feb 2003 16:20:49 +1000
User-agent: KMail/1.4.3

One of the most important features of pnetlib is its ECMA-compatibility mode.  
This allows us to build a C# library that adheres to the API's that are 
defined in the ECMA specifications.

To build pnetlib in ECMA-compatible mode, use the following:

    ./configure --with-profile=ecma

In your code, use "#if !ECMA_COMPAT" to detect features that are not part of 
the ECMA specification.  It is possible to remove entire files and 
directories from the ECMA build in the csant build files, but I don't really 
recommend doing that.  I'd prefer that people use "#if" instead, as it more 
clearly marks what is happening.

Sometimes a non-ECMA class is needed to provide the internal implementation of 
another ECMA class (e.g. XmlNode), and the csant mechanism isn't flexible 
enough.  The csant mechanism should only be used when importing third party 
code and it is advantageous from a maintainence standpoint to preserve the 
original code as-is.

In a few cases, it is necessary to implement a non-ECMA API as though it was 
ECMA because it is otherwise impossible to implement other features.  e.g. 
one of the System.Decimal constructors, System.MulticastDelegate, etc.  They 
should be clearly commented to explain the reason for going outside the 
specification.

I've fixed a few ECMA issues in the build today (some of them my fault, and 
some of them not).  I'd like to urge all pnetlib developers to regularly 
build and "make check" in ECMA mode.  Developers of other C# components (e.g. 
DGEE and Qt#) should also test-compile against the ECMA-compatible library 
from time to time.

A few people have noticed discrepancies lately between the ECMA specifications 
and the .NET Framework SDK as to the behaviour of certain API's.  Sometimes 
these discrepancies are due to bugs in the ECMA specification and other times 
they are due to ECMA not needing the full SDK functionality.

Normally these issues will be resolved in the direction of being more 
interoperable with the with other CLI implementations, not less.  The ECMA is 
not infalliable - bugs in the spec are not unheard of.  If in doubt, ask me 
and I'll make a determination as to which way we should jump.

Cheers,

Rhys.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]