[Mono-dev] Mono.Security + SecureString
Jonathan Pryor
jonpryor at vt.edu
Wed Dec 12 08:26:09 EST 2007
On Wed, 2007-12-12 at 12:59 +0000, Alan McGovern wrote:
> It'd break API compatibility, therefore it's a no-go.
Be more imaginative than that. :-)
It need not be actual new methods on the existing classes, but instead
extension methods in a different assembly.
It might also be possible to make the Mono runtime assemblies
(mscorlib.dll, etc.) "friend" assemblies of some Mono helper assemblies;
this would permit more efficient passing of data between the
standardized assemblies and the Mono extensions w/o using Reflection.
This would be visible to external code -- new attributes on e.g.
mscorlib.dll -- but I'm not sure that this would actually break
compatibility in any meaningful way (unless having added attributes
breaks compatibility, in which case every [MonoTODO] needs to be
removed!).
Certainly, this would make any such extension methods tied to Mono, but
it would also provide ways to try out new API designed before suggesting
them for standardization, in a way that won't break compatibility for
most users.
- Jon
More information about the Mono-devel-list
mailing list