A couple of Questions

[Tony van der Hoff]

On 26 Jul 2001, in message <E15Psh6-0001eZ-00 at bfg.reinhouse.freeserve.co.uk>,
Timothy Baldwin <tim at reinhouse.freeserve.co.uk> wrote:

[snip]

> > However, it would be nice to see a proper set of C++ classes defined by
> > DefMod. I look forward to your efforts.
> 
> I propose:
> 
Right, now we're going somewhere.

If you're serious about becoming an OSLib developer, you'd be very welcome,
and C++ would be a very positive step. I appreciate that there is no set of
guidelines published on how to become a developer, so I'll just summarise our
current (informal) arrangements now.

You must appreciate that the current OSLib maintainers have a mandate to
safeguard the interface into the future; the last thing we need is for
someone, however enthusiastic, to make a load of possibly unnecessary 
changes, then disappear, leaving the maintainers of the day to sort out the
mess. It is free software, but not a free-for-all. However, genuine, and
competent, contributors are always very welcome.

This forum (oslib-user) is to discuss user problems and requests; the correct
forum to discuss development of OSLib development is OSLib-team. So, I
suggest you subscribe to that; we can follow up on your detailed proposals
there.

The normal procedure would be for potential developers to send a subscription
request to oslib-team.subscribe at compton.nu, and one of the moderators would
then contact them via email to establish their precise interest. This is not
because it's a secret society, or anything, but simply to preserve that
channel from excessive chaff. It also permits more frank and open discussion
on controversial subjects (they do occasionally crop up ;-).

A proposed development will be discussed by the team, prior to any
implementation. Until they become a trusted member of the development team,
whose competence is clear, anyone coming along with a patch, saying "I've
implemented XYZ, please include it in the base distribution" is likely to get
short shrift. We, the maintainers, simply don't have the time to demangle
patch files, try to understand them, and ensure that they are not introducing
problems. If that appears arrogant and inflexible, so be it.

As a general rule, OSLib confines itself to being a very thin veneer between
a given target language, and the RISC OS API. There is a common language
defined (DefMod) which describes the API, and is specifically language
independent. Currently, DefMod (the language) adequately describes the
interface, and it is for DefMod (the interpreter) to produce the appropriate
output.

As a corollary to that, OSLib does not concern itself with anything over and
above providing an interface to the API. Any higher level operations should
be placed in a support library.

The OSLib interface is sacrosanct. No changes (other than bug-fixes) are
allowed to compromise backwards compatibility. This will be our aim at all
times, even if the resulting implementation is not as elegant as it would
have been if the feature had been implemented ab initio. Not everybody has
always agreed with this policy, but I'm sticking to it.

Any new target language will be implemented as a new defmod module. To
implement C++ it will have to be a new module; we will *not* compromise the
existing code generators.

> A new DefMod type .SuperClass [2] which is used like:
> 
No, DefMod does not concern itself with the target language, and in
any case already contains sufficient information to implement a class
structure. It already does so in effect for C by using the *_BASE_MEMBERS.
Something similar could be done for C++. It is also undesirable to change all
the .swi files to implement this target-specific feature.

[snip]
> 
> Implement variable size structures with C99 flexible array members [4] and 
> independentally with C++ templates (100% source compatible with the current
> macro implementation).

Hang on; just stick to one language at a time. We shall *not* be changing the
C implementation as part of the new C++ implementation
> 
> Re-implement OSLibSupport.X with C++ exceptions, as an alternative, to
> allow  interoperation with C++ exceptions.
> 
Forget OSLibSupport for now. It is not OSLib, and has nothing to do
with a generation of C++ headers. Ideally, once C++ OSlib headers are
available, a new support library should be written in C++.

> Make all new preprocessor macros start with OSLIB_ as a precaution against 
> conflicts.
> 
I would hope that you would not be introducing any new preprocessor macros as
part of this project.
 
> Do the above without separate header files for C and C++, the alternative 
> being putting separate header files on different paths and does not allow 
> individual features be selected by macros.
> 
No, we *must* preserve C mode intact. This may fall into the category of a
more elegant implementation being possible, and maybe in the future there is
scope for the two modes to merge, but for now it has to be seperate headers.
I would also oppose the use of macros; they would only serve to make the
user's task more complex.

> Convert Defmod.c.Cheader to using (OSLibSupport.X) exceptions, and remove
> the  code to generate C++ comments, this will make the code easier to
> understand.
> 
Well, I did that when I re-wrote CStrong, but I see no point in changing
CHeader. Again, I don't want this project to affect the current
language modes. I suggest you take a copy of CHeader, call it CPPHeader, and
implement your C++ mode in that. However, be aware that Stewart has changed
DefMod for portability; this will become the base release in the future, so
don't go changing too much on the current version.
> 

Are you proposing to write CPPStrong as well?

> About DefMod:
> 
> > > [1] If you make it case sensitive you will need this patch:
> > >
> > > Index: Source/User/oslib/MimeMap.swi
> >
> > [snip]
> >
> > Hmm, I don't think you picked the right patch there...
> >
> Said patch fixes the only place OSLib breaks with a case sensitive DefMod 
> (apart from multiple definitions of OS_VDULineFeed and Message_PreQuit).
> 
No, I agree it could do with fixing; I meant you sent me a patch for MimeMap.

[snip]
> 
> BTW, putting the distributed assembly files is s;0 and s32;0 directories
> makes writing tests in makefiles difficult to impossible as make (both amu
> and GNU  make) interpret ; as meaning start of commands.
> 
Well, it was the way Jonathan originally implemented it; I don't think
there's a very strong reason for sticking with it, although it's a
traditional version number separator.


Please follow up on OSLib-Team

-- 
Tony van der Hoff         | MailTo:tony at mk-net.demon.co.uk
                          | MailTo:avanderhoff at iee.org
Buckinghamshire, England  | http:www.mk-net.demon.co.uk