[Top][All Lists]
[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.
- [DotGNU]ECMA compatible pnetlib,
Rhys Weatherley <=