[Cython] Utility Codes and templates

[Stefan Behnel]

mark florisson, 26.07.2011 10:57:
> On 26 July 2011 08:46, Robert Bradshaw<robertwb at math.washington.edu>  wrote:
>> On Mon, Jul 25, 2011 at 11:39 PM, Stefan Behnel<stefan_ml at behnel.de>  wrote:
>>> Robert Bradshaw, 26.07.2011 06:29:
>>>>
>>>> On Mon, Jul 25, 2011 at 3:07 AM, mark florisson
>>>>>
>>>>> It's now 'MyUtility' and
>>>>> 'MyUtility.proto'. If there's no objection to the ini-style header
>>>>> (with requirements and other metadata possibly), then I'll implement
>>>>> that one of these days.
>>>>
>>>> One drawback with the ini style is that it detaches the metadata from
>>>> the code block itself (and require duplicating their names).
>>>
>>> The names are duplicated in the file already, since impl and proto are
>>> separated and can be anywhere in the file (e.g., you could put all protos at
>>> the top and all implementation parts further down). The advantages of
>>> putting in a header is that
>>>
>>> a) it's immediately visible from the top of the file what it contains
>>>
>>> b) the dependencies on other files are explicit and clearly visible, again,
>>> from the top of the file
>>>
>>> c) the metadata is easy and quick to parse, as the header is trivially
>>> separated from the rest
>>>
>>> d) only the header needs to be parsed in order to know what can be found in
>>> it or what other files are required to compile it
>>>
>>> e) we don't need to write our own parser, and the overall file format is
>>> trivial to parse
>>
>> I prefer keeping the metadata close, but perhaps that's just a matter
>> of opinion. Slurping in the entire file and parsing the block headers
>> is pretty trivial as well, and with pre-fetching (on so many levels) I
>> don't think there's a technical advantage for files so small. For
>> those (likely common) cases where no metadata is required, I'm -1 on
>> having to manually keep a "table of contents."
>
> Right, you woud only list metadata if there is something worthwhile to
> list. Otherwise you just omit it. (Perhaps that was not what Stefan
> had in mind though, I'm not sure).

I don't care so much here, but I consider the file header an interface 
description. I.e. you could also include utility code in a file that is 
only available as dependencies to other utility code, simply by not listing 
it in the header. Allowing to skip the header makes the semantics a bit 
more ugly here.

But as I said, I wouldn't mind if the header was optional, as long as 
that's easy enough to handle.

Stefan