On Wed, Jul 31, 2013 at 3:35 PM, Nick Wellnhofer <[email protected]> wrote:
> On Jul 31, 2013, at 23:50 , Marvin Humphrey <[email protected]> wrote:
>
>> C blocks are a heinous hack that I wish we could do without. For now,
>> they're
>> an essential safety valve for a few features that are too complex to
>> implement directly in the Clownfish header language, but a part of me would
>> like to have them undocumented in the initial release in the faint hope that
>> we could get away with removing them eventually. I anticipate that
>> supporting them will constrain our ability to evolve Clownfish.
>
> I would certainly be nice to get rid of C blocks, but I think every
> non-trivial Clownfish project will need them.
I suspect you're right about that. Perhaps it would be better to invert my
thinking and conceptualize C blocks as the first line of defense against
adding complexity to the Clownfish header language:
* When the need for a feature arises, first we find a way to hack in support
for it using a C block.
* Once a feature has proved its utility, see if it makes sense to implement
it in the header language proper.
> The problem is that the order
> of declarations and definitions is important in header files and C blocks
> provide a straight-forward way guarantee this order.
The way I see it, supporting C blocks gives us things such as preprocessor
macros and conditionals; full inline function definitions; and typedef, struct
and union declarations. Maybe we want to add some of those later, but its nice
that we don't have to rush out syntax for them yet.
> This should work but I prefer the more general fix that I made in commit
> cb609f42. There might be other C blocks which could cause similar problems.
OK, works for me. (We'll probably want to watch that we don't lard up those
parcel.h files now!) Thanks for attending to the problem.
Marvin Humphrey
