And other things useful, but not implemented yet in the current api.h, is something to be done according to necessity.
I think that if something useful externally is not accesible via dwg.h, then it should be moved there. For example, version_codes, which is in common.h for now. 2013/8/23 Felipe Castro <[email protected]> > The problem of the user accessing things out of the API is that internal > struct representation could be changed by us, developers, and break > compatibility. The API allows us to work in the internals without affecting > the external layer of interaction, ok? > > > > 2013/8/23 gagan <[email protected]> > >> On Fri, Aug 23, 2013 at 3:11 AM, Felipe Castro <[email protected]> wrote: >> > Hum, I think I see the problem. Because api is an interface, it has to >> see >> > both sides. Then, for now keep dwg.h in the include_HEADERS, but the >> user >> > should not have to include it by himself, api.h makes that for him. But, >> > this way, the user could use anything there in dwg.h. I really don't >> know >> > how to encapsulate dwg.h, need to see some other's codes around... >> >> But I guess the person should be able to use everything that is out of >> DWG also( Please correct me if wrong ). >> @Others please if you have any idea how to do so please reply. >> >> -- >> Thanks >> Gaganjyot >> http://codeify.wordpress.com >> "Jai Sai Naath" >> >> >
