On 4 September 2014 12:56, Taras Kondratiuk <[email protected]> wrote:
> On 09/04/2014 07:21 PM, Mike Holmes wrote: > >> I think it obfuscates things, adds overhead to maintainence and to app >> development. >> >> It has to be maintained but it is not strictly necessary, as now, it is >> already out of date and no one noticed >> Implementers accidently use it rather than the internal file - overhead >> to police this. >> Applications no longer advertise the features they use in their include >> list, I like that summary at the top of a file, it clearly says that >> this file deals with crypto for example. >> When hunting for information I have to go from my app.c to odp.h to find >> the name of the real include file wanted to look in. >> I don't like the conceptual coupling, for me coupling is bad when it is >> not needed for execution - as in this case. >> >> The only upside is that apps writers don't wear out their keyboards >> > > I partially agree, but having separate headers exposed to application > makes header names a part of specification. So if let's say in future > we would like to reorganize headers and move all type definitions to a > separate file, then all applications have to be updated. > I would pay that price and call it ODP 3.0, you can't always ensure backwards compatibility or you stagnate. -- *Mike Holmes* Linaro Technical Manager / Lead LNG - ODP
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
