On 09/04/2014 08:16 PM, Mike Holmes wrote:
On 4 September 2014 12:56, Taras Kondratiuk <[email protected]
<mailto:[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.
Ok, then IMO before ODP v1.0 we have to revise header names and its
content. Decide which of them are public and add this to specification.
IMO currently we have too many public headers. For example is
odp_packet_flags.h need to be included by application or it can be
implicitly always included by odp_packet.h?
_______________________________________________
lng-odp mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/lng-odp
