[Mono-dev] Big Arrays, Many Changes --- Request for Advice
Luis F. Ortiz
LuisOrtiz at Verizon.Net
Thu Sep 6 07:36:42 EDT 2007
On Sep 5, 2007, at 5:37 AM, Robert Jordan wrote:
> Luis F. Ortiz wrote:
>> But at least now there is only one method to change, though I
>> suspect it
>> will take
>> more than a few minutes for me to get the SVN version to compile from
>> scratch.
>
> The big array support leads to an API breakage on 64 systems:
>
> Unlike other API structs, MonoArray's internals are publicly exposed
> by macros. Since its "max_length" member has to be extended to 64 bit,
> the ABI will change and all applications using libmono have to be
> recompiled.
>
> IMO, this cannot be done before Mono 2.0, especially when the benefits
> are so tiny, but feel free to provide patches.
You are quire correct, API breakage is to be avoided, thanks for
pointing out this issue. I'm not sure what release/branching
structure is used by the mono project, but I suspect it is a live
trunk with branches used to record releases. Thus these changes
could be set up to work off off a ./configure option (say --with-
large-objects) which could result something like MONO_LARGE_OBJECTS
being defined and conditional compiles used while the 1.2.X series is
being worked on. That way, the API breakage will be restricted to
those who want to experiment. Then, when 2.0.0 is in active
development, the default condition for the configure switch can be
flipped to ON and then later, once everyone is comfy with the
changes, the conditional code can be ripped out.
--Luis
More information about the Mono-devel-list
mailing list