As part of the typed zip experiment I've started to play around with the structure of headers and source files, mainly for two reasons.
- Instead of passing
Dynamic handles through the _hx_ c functions the underlying classes are now exposed. But to avoid implementation details being leaked an abstract class of pure virtual functions is exposed (see include/hx/zip/ folder).
- I moved the zlib implementation of the zip api into
src/hx/zip/zlib instead of where it use to be so it matches the header folder more closely.
There's another thing I want to do which is to more formally expose those implementations, this would be especially useful for more fundamental types such as files and sockerts where you may want to get at the underlying OS handle to do stuff not exposed via the haxe api.
So would it be useful to haxe something like include/hx/sys/File.hpp and then include/hx/sys/win32/Win32File.hpp and include/hx/sys/posix/PosixFile.hpp style setup for this?
As part of the typed zip experiment I've started to play around with the structure of headers and source files, mainly for two reasons.
Dynamichandles through the_hx_c functions the underlying classes are now exposed. But to avoid implementation details being leaked an abstract class of pure virtual functions is exposed (seeinclude/hx/zip/folder).src/hx/zip/zlibinstead of where it use to be so it matches the header folder more closely.There's another thing I want to do which is to more formally expose those implementations, this would be especially useful for more fundamental types such as files and sockerts where you may want to get at the underlying OS handle to do stuff not exposed via the haxe api.
So would it be useful to haxe something like
include/hx/sys/File.hppand theninclude/hx/sys/win32/Win32File.hppandinclude/hx/sys/posix/PosixFile.hppstyle setup for this?