Re: SmartEiffel shortcomings?

Lothar Scholz wrote:
> I would put my GUI library which is the fundation of Arachno Ruby
> into the support, also my patches for the exception handling (yes i
> fixed it - not elegant but i can see the stack trace before the
> rescue handling) and integration of a type hinted Boehm Weisser GC.

Those are very worthwhile things. Let's look at your previous list of
desirable improvements:
[1:] Better exception handling 
[2:] Better standard library
[3:] Better garbage collector
[4:] A "storage" implementation.
[5:] A useable (not that slow) debugger.
[6:] Multi Threading.
[7:] Faster compiler speed for large projects
[8:] Compatibility for years
...and mine...
[9:] A decent GUI library
[10:] Smooth support for dynamic library generation and use

Of these, you have already done some work towards [1], [3] and [9].
Items [2], [5], [7] and [8] are well-suited to continual improvement in
small increments by multiple people over a period of time (as one tends
to get in an open-source project). Items [4], [6] and [10] need a lot of
work to be done by a hard-working well-motivated individuals or small
group - but such people do exist.

So maybe we can achieve "SmartEiffel - industrial edition" after all.

But we can't possibly achieve it within the existing infrastructure,
because:
  (1) We don't even have _read_ access to the development repository
  (2) We don't have access to the test suite
I think everyone involved with any kind of open source project would
agree that those constraints are show-stoppers, even before we start to
consider such things as research directions.

I can think of two major open questions:
   (1) Would it be best to start from 1.1 or 2.x?
   (2) What would be the broad development goals?

I'll explore these a little more in separate messages.
-- 
Roger Browne <[email protected]>