Laurent Deniau a écrit :
I just put the draft of my paper on the web:
http://cern.ch/laurent.deniau/html/c...la07-draft.pdf
I would be interested by any feedback from C programmers (with little OO
knowledge) to improve the paper quality, even if I don't know yet if the
paper will be accepted. It is not intended to be a manual nor an
introduction to OOP. Just to mention it (not in the paper), my
programming background is 10+ years of C/C++.
Kind regards,
ld.
ABSTRACT:
The C Object System (COS) is a recent framework entirely written in C
which implements high-level concepts available in CLOS, OBJECTIVE-C and
other object-oriented programming languages: uniform object model
(class, metaclass and property-metaclass), generics, multimethods,
delegation, exceptions, contracts and closures. It relies on the
programmable capabilities of C to extend its syntax and to implement the
aforementioned concepts as first-class objects. COS aims at satisfying
several general principles like simplicity, flexibility, extensibility,
efficiency and portability which are rarely met in a single programming
language. Its design is tuned to provide efficient and portable
implementation of message dispatch and message forwarding which are
the heart of code flexibility and extensibility. With COS features,
software should become as flexible and extensive as with scripting
languages and as efficient and portable as expected with C programming.
Likewise, COS concepts should significantly simplify adaptive,
aspect-oriented and subject-oriented programming as well as distributed
systems.
Salut Laurent!
Very interesting paper.
Some comments after a fast first reading:
A: EXCEPTION HANDLING
------------------
1) lcc-win32 implements try/catch exception handling in
a slightly similar way than what you propose.
For instance
void fn(void)
{
char *p=NULL;
unsigned code;
__try {
*p = 0;
printf("No exceptions\n");
}
__except(code=G etExceptionCode (),EXCEPTION_EX ECUTE_HANDLER) {
printf("Ooops, there was a problem with this program.”);
printf("Error code: %#x\n",code);
}
return 0;
}
This could be made functionally equivalent to what you propose with a
switch statement within the __except clause, that would handle the
different values of the exception being thrown.
Of course your exception handler handles not just an integer code but
(apparently) a message to an object/class...
This is easy to do under windows, but very difficult to do in systems
that do not support exception handling natively like linux, for
instance. I have found no easy solution under linux, but it is true
that I haven't researched a lot about how could be done.
2: Another subject, within the exception handling theme is the behavior
concerning traps. Are traps exceptions? As you can see above, for
lcc-win32 the answer is yes. For C++ it is no, as far as I know.
(Please correct me if I am wrong the C++ experts here).
I would like to know the position of COS about this subject.
B: DESIGN BY CONTRACT
------------------
I have developed an extension for lcc-win32 to implement DBC, but after
some thought about it, I can't see the advantage of that with the simple
method of just using assert. Preconditions can be very easily
implemented with asserts before the main body of the function, post
conditions can be done in a similar easy way by adding assertions after
the body of the function.
Since the C Comitee has started examining the Microsoft proposition for
a safer C library, I implemented the "require" macro using that proposed
mechanism, what is surely an improvement over just the assert macro.
The 'require' macro would fit nicely as the precondition part of DBC.
Obviously your proposal is different than that, since you advocate oo
programming, and the preconditions/post conditions are part of the
class hierarchy, and accordingly executed probably from the most
specific to the least specific class constraints (or the other way
around, I do not remember seeing this in your document).
C: GENERICS
--------
It is difficult to understand what do you want from the description of
generics in your document. You refer to objective C behavior as
explanation but with my very limited knowledge of Objective C this
leaves quite a lot of dark places...
Generics within the context of lcc-win32 are understood as a single
function that can have different implementations for different
arguments. This corresponds (more or less, probably less than more) to
the C++ usage. Your definition of generics seems to be a function that
receives an unidentified object as arguments, tests if the object
responds to some message and if it does it sends the message...
I do not see quite the interest of that, and it would be nice if you
would use a more down to earth example for this.
jacob
P.S. I referred above to 'lcc-win32'. That is an experimental
compiler system available at
http://www.cs.virginia.edu/~lcc-win32 
