From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Ada-Win32 bindings
Date: Tue, 7 Aug 2018 17:02:40 -0500
Organization: JSA Research & Innovation
Message-ID: <pkd4u0$a67$1@franka.jacob-sparre.dk>
References: <27b53953-36f2-4efe-b877-2e316b176d80@googlegroups.com>
 <pkah2p$umc$1@franka.jacob-sparre.dk>
 <5c836355-2938-4cde-a03f-f7ee9f3ff2ee@googlegroups.com>
Injection-Date: Tue, 7 Aug 2018 22:02:40 -0000 (UTC)
Injection-Info: franka.jacob-sparre.dk;
 posting-host="rrsoftware.com:24.196.82.226";
	logging-data="10439"; mail-complaints-to="news@jacob-sparre.dk"
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246
Xref: reader02.eternal-september.org comp.lang.ada:54086
Date: 2018-08-07T17:02:40-05:00
List-Id: <comp.lang.ada>

<alby.gamper@gmail.com> wrote in message 
news:5c836355-2938-4cde-a03f-f7ee9f3ff2ee@googlegroups.com...
...
> With respect to your last comment/paragraph I get the impression that you 
> think
> these bindings were NOT built by a tool?

I was commenting on MAWB (won't have needed help if spending months on a 
tool was a serious option - since such a thing requires essentially building 
half of a C compiler). I had no idea how you made your bindings.

> In fact they were, and the underlying
> technology behind it makes it feasible to implement some if not all of 
> your
> and Dmitry's suggestions/points. My only concern with this (if fully 
> implemented)
> would be the resulting size of the bindings blowing out from 100K lines of 
> code
> to something much bigger (and the impact of usage from clients of the 
> bindings)

90% of Microsoft's bindings are of little interest to anyone. They tend to 
introduce a new API frequently, often for purposes that never get any 
traction with anyone. So long as your bindings are well-organized, the sheer 
volume is rather irrelevant, since most users will stick with just a handful 
of packages.

For a low level binding like this (which is going to be used mainly as a 
foundation for better things), probably the most important feature is 
compatibility. That is, newer versions of the binding need to change as 
little as possible about existing APIs, because breaking things all the time 
will make one no friends. (Ask Dmitry about GTK versions. :-) That's likely 
to be a struggle with a tool-generated binding.

                                   Randy.