[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MCL 2.1
- To: BUG-MCL@CAMBRIDGE.APPLE.COM
- Subject: Re: MCL 2.1
- From: UK0392@AppleLink.Apple.COM (EHN & DIJ Oakley,BDV)
- Date: 28 Apr 92 17:08 GMT
- Cc: INFO-MCL@CAMBRIDGE.APPLE.COM
In response to Alice Hartley's call for desires for features for MCL 2.1 and
greater, my offerings in order of priority are as follows:
1. Fuller Class Libraries, particularly with support for Mac features which
are currently not so well supported, e.g.
a. (possibly the most important of all) printing - perhaps 20% of all
info-mcl requests for help seem to be for this, which in other OOP systems like
MacApp are *extremely* easy, but are very hard in MCL 2.0.
b. support for resource-based dialog views - I do not think that it
matters whether they are MacApp 2.0 or 3.0 views, or something else, but
something more industrial beyond the procedural dialog support is highly
desirable. A large proportion of vertical market and similar development is
in creating good views, and MCL source swells massively (and probably
inefficiently) with very large numbers of complex procedural dialogs.
2. A book on MCL, akin to those on MacApp (? in the Mac Inside Out series)
which takes a full tutorial approach to MCL development for those with a
grounding in Common Lisp. I rate this so highly because if MCL is to attract
new blood, it must become more accessible, and that means *excellent* tutorial
material. This is MacApp's greatest weakness, although MacApp is very much
better off than MCL.
3. Continuing support for the Common Lisp language standard as it evolves -
CLtL2 and its successors are excellent references, and it is of course vital
that MCL should stick with it.
4. More source. I must confess that when I first bought MCL, I was under the
impression that it came with most of its components, such as Fred, in source,
when as it turned out it was only the Interface Editor and the Inspector.
Source of this kind is not only of excellent tutorial value, but also allows
even greater customisation. However, I accept that this may not be possible
for many reasons!
5. An even fuller Class Library than at 1 above. MacApp is a good parallel,
and although I realise that it *is* different, compare the size and
sophistication of MacApp with the classes supplied in and with MCL. If Apple
will not do it, then others will. I hear the call for CLIM, but although CLIM
does appeal strongly to some MCL users, it is not (in a general sense)
mainstream, nor is it 'real' Mac (we could debate cross-platform Class
Libraries for some time; whilst CLIM is there now, there is no good Class
Library support for the Mac). CLIM will certainly attract and retain some
developers, but I suspect not those that MCL truly deserves.
6. Alpha implementations of Dylan in MCL :-)
Oh - I should also point out that these comments are written before I have seen
MCL 2.0 final, and are thus subject to change when I do!
I sincerely hope that the MCL team can consolidate on a product which they have
lovingly brought to being one of the best development environments on any
system that I have used.
Howard.