C Object System

[Laurent Deniau]

I just put the draft of my paper on the web:

http://cern.ch/laurent.deniau/html/cos-oopsla07-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.

 

[klaushuotari]

I just put the draft of my paper on the web:

http://cern.ch/laurent.deniau/html/cos-oopsla07-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.

Very interesting paper and lots of mind-food. I'm not sure if C is
suitable for re-decoration as we have C++, but nevertheless it's a
thing to consider. I have to study this one.

 

[jacob navia]

Laurent Deniau a écrit :

I just put the draft of my paper on the web:

http://cern.ch/laurent.deniau/html/cos-oopsla07-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=GetExceptionCode(),EXCEPTION_EXECUTE_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

 

[Ian Collins]

I just put the draft of my paper on the web:

http://cern.ch/laurent.deniau/html/cos-oopsla07-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++.

Given your background, I have to ask why? The features you describe in
the paper have already been added to C, in the form of C++.

 

[CBFalconer]

.... snip ...

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=GetExceptionCode(),EXCEPTION_EXECUTE_HANDLER) {
printf("Ooops, there was a problem with this program.”);
printf("Error code: %#x\n",code);
}
return 0;
}

This has nothing to do with standard C, the subject of this
newsgroup.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

 

[CBFalconer]

Given your background, I have to ask why? The features you describe
in the paper have already been added to C, in the form of C++.

C++ is another language, and off-topic here.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

 

[Ian Collins]

C++ is another language, and off-topic here.

So? I was asking the OP why he proposes to reinvent a wheel, not
discussing C++.

 

[CBFalconer]

So? I was asking the OP why he proposes to reinvent a wheel,
not discussing C++.

Probably because he wants to use that language on a system that
doesn't sport a C++ compiler. I think you use what you can get.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

 

[Laurent Deniau]

Given your background, I have to ask why? The features you describe in
the paper have already been added to C, in the form of C++.

<OT>
In fact, this is the usual answer I get when I am talking about OOP in
C. But the object model of COS has nothing to do with the one of C++.

COS is very close to CLOS from the point of view of the object model
with many similarities to ObjC due to the fact that it is built on top
of C. But it is very far from C++. As an example, one can look at the
GoF patterns and check for each one why it is needed. Most of them are
there to solve either a problem related to static typing and/or coupling
and/or dynamic behavior and/or missing meta-knowledge. As soon as you
jump on the dark side (i.e. dynamic typing, dynamic dispatch,
meta-classes), they become much less useful. Code and design become
simpler but more permissive.

My point of view is that all the paradigms (SI, MI, template, overload,
override, namespace) introduced by C++ provide (powerful) static glue
(coupling) except dynamic_cast which is not the heart of C++
programming. C++ can be very flexible with meta-programming which is the
modern approach of libraries design (i.e. STL, Boost). But this
flexibility exists only statically at the code level and often makes
unforeseen extension very difficult and/or complex to add. To achieve
flexibility and extensibility in C++ at the level of frameworks, one
need to think in term of roles and components (see ref 21 and 22 of the
paper). Pushing this reasoning to the limits (i.e. one method per role)
and the roles become generics. For a global approach to the problem but
specific to C++, one can read the book of John Lakos "Large-Scale C++
Software Design".

To conclude on C++, I knew that it would be a major concern for many C++
programmers. Earlier releases of the paper had a full section discussing
of pros and cons of main stream languages with a special attention for
C++ (with 14 references which are still in the latex version ;-) ). But
I had to suppress it, due to the limits of 18 pages. My believe is that
on one hand, programmers to who COS doesn't look attractive don't need
its features to solve the problems they encounter. On the other hand,
programmers to who COS does look attractive already faced the same
problems I had to solve and understand the motivation.
<OT>

 

[Laurent Deniau]

Probably because he wants to use that language on a system that
doesn't sport a C++ compiler. I think you use what you can get.

I hope that people will not see COS as yet-another C++ since it has
nothing to do with C++ and it is not intended to replace it when it is
not available. If this is the conclusion of the paper readers, it would
mean that I completely failed to explain the interest of COS (sic!).

a+, ld.

 

[Ian Collins]

<OT>
In fact, this is the usual answer I get when I am talking about OOP in
C. But the object model of COS has nothing to do with the one of C++.

In that case, I will study the paper in greater depth than I did this
morning. I just shudder when I see all those macros!

 

[llothar]

This has nothing to do with standard C, the subject of this
newsgroup.

Sorry but i don't see that this newsgroup is bound to ANSI-C or K&R-C
only.
It's name is "comp.lang.c" and this is a whole ranges of different C
languages.

I'm reading here for a few weeks and i'm really getting pissed off
from people like
you and Mr. Heatfield. You might not want to discuss this but others
like. Sorry
but you seem to be dogma addicted in the same way as for example the
Pope or
Al-Sadr.

Why isn't it possible to discuss evolution of the language?
At least if there is a precompiler that converts an extended C into
ANSI-C.

I must say, i liked to read this paper.

 

[Ian Collins]

llothar wrote:

Please don't snip attributions.

Sorry but i don't see that this newsgroup is bound to ANSI-C or K&R-C
only.
It's name is "comp.lang.c" and this is a whole ranges of different C
languages.

Which doesn't include lcc-win32, a compiler with its own group. The bit
of lcc-win32 specific code you snipped was OT, it wasn't standard C or
even a common extension.

 

[Laurent Deniau]

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=GetExceptionCode(),EXCEPTION_EXECUTE_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).

You are right.

I would like to know the position of COS about this subject.

COS is only C and therefore it has to rely on whether the C compiler
supports signaling traps or not. What COS provides is a service which
converts automatically registered signals into exceptions.

http://cos.cvs.sourceforge.net/cos/COS/src/cos/signal.h?view=markup

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.

Except if the body does return in the middle, you still need to run
post-condition. You can always rewrite the code to avoid this but then
you put the burden on the programmer shoulders.

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).

pre-conditions are bottom-top, post-conditions are top-bottom which is
the natural way of thinking of an average programmer (like me).
Invariant is a special case intrinsic to the class.

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.

This is overloading which is usually resolved by mangling the function
name with some signature encoding (not including the return type in
C++). Overloading is resolved statically at link time.

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.

Generics work like overloading with dynamic resolution (i.e. virtual
member functions in C++). This is just the merge of both concepts in one
at the same time. Paragraph "Method ranks" (p.11) explains how the
specialization is selected. Generics are also explained for CLOS in the
ref. 9 of the paper.

Example of multimethods in pseudo C++:

class Number { .. };
class Integer : Number { .. };
class Double : Number { .. };

// defgeneric OBJ operator+(OBJ,OBJ);

Double operator+(Integer &a, Double &b) { .. } // (1)
Double operator+(Double &a, Integer &b) { .. } // (2)

int main() {
// concrete instances.
Integer a(10);
Double b(5.5);

// abstract representation.
Number &n1 = a;
Number &n2 = b;

// double dispatch
Number &c = n1+n2; // call (1)
Number &d = n2+n1; // call (2)

return 0;
}

With static typing but late binding, this is a nightmare to implement
and use because of the object-dependent covariant and contravariant
typing rules (google for the Scala language for more info).

hope this help to clarify the points.

a+, ld.

 

[jacob navia]

Sorry but i don't see that this newsgroup is bound to ANSI-C or K&R-C
only.
It's name is "comp.lang.c" and this is a whole ranges of different C
languages.

Exactly.

This group has no chart, and nobody can tell you with any authority
that something is "off topic". The people around Heathfield
should be just ignored

They have nothing to say, their only "argument" is "off topic"
"off topic"...

jacob

 

[Ian Collins]

Exactly.

This group has no chart, and nobody can tell you with any authority
that something is "off topic".

I'm not a card carrying member of the topicality police, but you have to
admit your lcc-win32 specific exception code wasn't what most reasonable
people would call C.

No one is bashing the OP, the paper describes a system based on standard C.

 

[CBFalconer]

I hope that people will not see COS as yet-another C++ since it has
nothing to do with C++ and it is not intended to replace it when it is
not available. If this is the conclusion of the paper readers, it would
mean that I completely failed to explain the interest of COS (sic!).

This has nothing to do with your post, just Mr. Navia's off-topic
addition (and somebody snipped the attribution).

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

 

[llothar]

So? I was asking the OP why he proposes to reinvent a wheel, not

discussing C++.

Because it is not the same wheel. Your posting would make more sense
if you asked why he reinvent Object-C.
And it is a nice addition which is easy enough to describe it in 18
pages - something you surely can't say about
C++.

Or why does he reinvent D ?

 

[Al Balmer]

Please don't snip attributions, and retain enough to make sense of
what you do include. I had to chase the header references to find out
that this sentence had nothing whatsoever to do with the subject, but
was a reply to Jacob Navia, regarding something *he* wrote.

Sorry but i don't see that this newsgroup is bound to ANSI-C or K&R-C
only.
It's name is "comp.lang.c" and this is a whole ranges of different C
languages.

I'm reading here for a few weeks and i'm really getting pissed off
from people like
you and Mr. Heatfield. You might not want to discuss this but others
like. Sorry
but you seem to be dogma addicted in the same way as for example the
Pope or
Al-Sadr.

I suggest that you use Google Groups to research the topic of
topicality in c.l.c. It may help you understand why we attempt to keep
the group's focus narrowly on standard C.

Why isn't it possible to discuss evolution of the language?

There is another group which discusses the C standard itself and its
evolution, comp.std.c.

At least if there is a precompiler that converts an extended C into
ANSI-C.

I must say, i liked to read this paper.

And of course the paper is based on standard C and probably topical
here.

 

[llothar]

There is another group which discusses the C standard itself and its
evolution, comp.std.c.

So it is now even more clear that you, Ian, and Mr. Heatfield are
in the wrong group. If there is a standart C group then this here is
the right place for all the mutant-C's.

I'm not saying that jacob's and other persons changes should go into
the standart but they need to be discussed and if are good we can
move the topic up to "comp.std.c" (which is nobody reading).