CLIM mail archive
[Prev][Next][Index][Thread]
features
Date: Thu, 28 Oct 1993 13:02 EDT
From: Peter Karp <pkarp@ai.sri.com>
I'd like to suggest that the CLIM vendors put some effort into
establishing a more standard, more useful features list (i.e.,
*features*) in the interest of facilitating portability among
platforms.
Obviously, :CLIM should be on the features list for all CLIM
implementations. It is version information that I want to address.
I suggest that all vendors ensure that symbols naming both the major
and minor version are on the features list, and that alpha/beta
designations be encoded separately.
For example, I suggest the following symbols be defined for the
following releases:
CLIM 1.1 :CLIM :CLIM-1 :CLIM-1.1
CLIM 2.0 alpha :CLIM :CLIM-2 :CLIM-2.0 :CLIM-2.0-alpha
CLIM 2.1 :CLIM :CLIM-2 :CLIM-2.1
I am quite certain that CLIM 1.1 has :CLIM and :CLIM-1 and maybe even
:CLIM-1.1 on *FEATURES*.
The sysdcl for CLIM 2.0 pushed :CLIM, :CLIM-2, and :CLIM-2.0 onto
*FEATURES*. There is no conditionalization for alpha/beta, etc, at
least not to my knowledge.
My reasoning is that there will be certain systematic differences
between all the CLIM 1.X versions and all the CLIM 2.X versions, and
that we should be able to use #+CLIM-2 or #-CLIM-1 to designate such
dependencies in our code once, for all time. If I were to use
#+CLIM-2.0, or #-CLLIM-1.1 my code would do the wrong thing when I
tried to use it under CLIM-2.1 or CLIM-1.0.
I would specifically request that vendors NOT include symbols for
previous versions, e.g., a CLIM 2.0 implementation should not include
:CLIM-1.1. (I have seen this case occur, which is why I point this
out.)
I am pretty sure that it is the case that CLIM 2 does not have CLIM 1
features on *FEATURES*.
This type of planning in the feature list will let us conditionalize
code at a much more accurate level of granularity. Code will be
portable across different sites and different platforms.
Peter
References:
Main Index |
Thread Index