[Mono-dev] Big Arrays, Many Changes --- Request for Advice

[Paolo Molaro]

On 09/06/07 Luis F. Ortiz wrote:
> 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.

If we have any bug with not supporting arrays with a length up to
Int32.MaxValue we should fix them, at least as far as the code is
concerned, though the GC may not actually be able to allocate them
on 32 bit systems.
If we allow sizes up to Int64.MaxValue on 64 bit system is still very
much up in the air: I haven't seen anybody else request it and my guess
is that this would be very taxing on the GC anyway.
Handling this with a define (but also a libmono soname change) would be
fine I guess. Since this is an incompatible change I would prefer not
having a configure change, though, since apparently some people monitor
our new configure options and enable them even if they don't know what
they mean:)

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better