DStep - Bindings Generator 0.0.1
Dmitry Olshansky
dmitry.olsh at gmail.com
Sun Jul 8 15:27:01 PDT 2012
On 09-Jul-12 02:13, Roman D. Boiko wrote:
> On Sunday, 8 July 2012 at 20:01:07 UTC, Jacob Carlborg wrote:
>> On 2012-07-08 20:42, Walter Bright wrote:
>>> Since OC is a proper superset of C, this shouldn't be a problem. Just
>>> run the OC converter as your "C" compiler.
>>
>> That is not completely true if one is picky. The following code is
>> legal C, but not legal Objective-C :
>>
>> int id;
>> int nil;
>>
>> In Objective-C "id" is a type.
> I suppose this symptom will repeat in the future. I mean, for a
> particular file extension there may be several code importers. An
> (exotic?) example might be when some existing code uses one converter,
> but for some reason new code should use a different one.
>
> What about using the something like this:
>
> mixin convertImport!"header.h";
>
Ineffective even in distant future. Fixed functionality (=compiled,
native, etc.) is faster and more practical.
E.g. the above was possible already for something like a year (no less)
the exact magic is:
mixin(translate(import("file.ext"));
But it never scaled to reasonably sized inputs/amounts of files like
translating headers.
> with ability to specify a particular converter as second template
> parameter?
However something like :
import "file.ext", FancyImporter; could work and call some
'FancyImporter' for compiler's tools directory to produce file.di
I think extra syntax could be added easily WHEN the need arrives, so far
1:1 converters to extension feels fine.
--
Dmitry Olshansky
More information about the Digitalmars-d-announce
mailing list