Typed zip

[Aidan63]

Haxe side : HaxeFoundation/haxe#12453

There are a few changes here.

"include/hx/zip" contains the hxcpp zip public api headers, "src/hx/zip/zlib" contains the zlib implementation of this api.

The "src/hx/zip/Build.xml" file will select the zlib implementation unless "HXCPP_ZIP_XML" is defined in which case the xml in that file is used instead. This allows providing custom implementations of the zip api without needing to fork hxcpp or shadow the haxe std library types to patch the build xml meta.

I've removed the 500 api level guards from the new View type and updated the old _hx_inflate and _hx_deflate c functions to call the new zip api. This allows us to have haxe 4 compatibility without needing to keep around the old implementation.

I've changed calling close multiple times to just be a no-op instead of throwing, I think this makes more sense.

[Simn]

What's going on with the git history? Doesn't really matter because we're gonna squash it anyway, but this looks like something went wrong.

[Aidan63]

I'm not sure either. I branched this off the value type branch a while ago but merged master in today, maybe because that original value type branch has now been deleted?

[tobil4sk]

It's probably because the value type pr was squashed and merged, so those commits don't actually exist in master (so github can't detect them as already merged). Rebasing the zip changes with master and force pushing to the PR branch should clean it up.

[Aidan63]

I tried a rebase on master, but at the end of it I still had 80 odd commits in the branch.

[tobil4sk]

Does it make sense to move the zlib stuff from hx/libs/zlib to hx/zip? Currently all the haxe library support files are in hx/libs, including hx/libs/std, so may be best to keep it within the hx/libs directory?

I tried a rebase on master, but at the end of it I still had 80 odd commits in the branch.

To do it properly you'll have to drop commits that have already been merged in an interactive rebase.

[Aidan63]

That is one thing I'm not too sure about.

I quite like having it under "src/hx/zip/zlib" since it matches more closely matches the include folder structure (I was thinking about having a "/zlib" folder in the include one as well). But it is different from whats done currently.

Another thing I want to do (which doesn't apply to the zip implementation) is reduce the number of ifdef conditions. Some files (such as Process.cpp) have loads of conditionals since it's really a posix and win32 implementation crammed into one file, it makes things really hard to follow.
For these cases I was thinking of splitting it out into separate files, but I'm not yet sure on how to structure that (dedicated /win32 and /posix folders in libs/std? Process.win32.cpp and Process.posix.cpp files?).

So part of the zip folder change was me seeing how I like it as a structure (I'm still not sure).

[tobil4sk]

I quite like having it under "src/hx/zip/zlib" since it matches more closely matches the include folder structure

I think it would make more sense to adapt the new include structure to the existing source structure. It's helpful to have a clear separation between files that are a integral part of the hxcpp runtime, and wrappers around external libraries that are just there to support haxe std features.

For these cases I was thinking of splitting it out into separate files, but I'm not yet sure on how to structure that (dedicated /win32 and /posix folders in libs/std? Process.win32.cpp and Process.posix.cpp files?).

I suppose folders make sense if there are a lot of platform specific files, and if it's only Process then having a platform suffix on the file might be cleaner. I think usually I've seen stuff like Process_win32.cpp rather than Process.win32.cpp. Separating it out seems sensible, but it might be helpful to have some way to ensure that both implementations will provide a consistent interface.

[Aidan63]

wrappers around external libraries that are just there to support haxe std features

Another thing I want to do (and was why I was thinking of putting a /zlib folder in includes) is that I want these classes to be accessible to external glue code. Not that important to zlib, but being able to get the OS handle from the hxcpp file class would have been helpful in the past.

but it might be helpful to have some way to ensure that both implementations will provide a consistent interface.

That was my idea with the non-implementation specific classes with just pure virtual functions. Was thinking of having something like hx::sys::Process and then a hx::sys::win32::Process and hx::sys::posix::Process which provide the implementation.

[Simn]

Should I merge this or did you want to change anything else?

[Aidan63]

I say merge it, I'll open an issue for the structure stuff mentioned. Easy enough to switch it around later.