For the new CQL driver I need Lz4 support. Now, instead of introducing yet another toplevel Lz4 object, how about moving Bz2 and Gz and Lz4 into:
Compression.Bz2 Compression.Gz Compression.Lz4
Any objections?
For the new CQL driver I need Lz4 support. Now, instead of introducing yet another toplevel Lz4 object, how about moving Bz2 and Gz and Lz4 into:
Compression.Bz2 Compression.Gz Compression.Lz4
If we change location I want them to have the same API so you can switch between them easily. Old locations should have compatibility wrappers of course.
Martin Nilsson (Coppermist) @ Pike (-) developers forum wrote:
Compression.Bz2 Compression.Gz Compression.Lz4
If we change location I want them to have the same API so you can switch between them easily. Old locations should have compatibility wrappers of course.
Same API, of course. Compatibility wrappers, well, since it's the same API, the migration is easy. So if you call up pike in compatibility mode (8.0 and older), it should have the wrappers. But in 8.1+ mode, I could imagine omitting the compatibility wrappers from the getgo.
On Thu, Apr 1, 2021 at 6:18 PM Stephen R. van den Berg srb@cuci.nl wrote:
Martin Nilsson (Coppermist) @ Pike (-) developers forum wrote:
Compression.Bz2 Compression.Gz Compression.Lz4
If we change location I want them to have the same API so you can switch between them easily. Old locations should have compatibility wrappers of course.
Same API, of course. Compatibility wrappers, well, since it's the same API, the migration is easy. So if you call up pike in compatibility mode (8.0 and older), it should have the wrappers. But in 8.1+ mode, I could imagine omitting the compatibility wrappers from the getgo.
I'd prefer the wrappers, since it makes porting a lot easier. I generally prefer to be able to run without compatibility mode, and then have fallbacks in my code where there are actual differences.
ChrisA
On Thu, Apr 1, 2021 at 9:18 AM Stephen R. van den Berg srb@cuci.nl wrote:
But in 8.1+ mode, I could imagine omitting the compatibility wrappers from the getgo.
What's the proposed benefit for not having wrappers? They cost virtually nothing, we can easily carry them for ages to come... why break existing code?
Tobias S. Josefowitz wrote:
But in 8.1+ mode, I could imagine omitting the compatibility wrappers from the getgo.
What's the proposed benefit for not having wrappers? They cost virtually nothing, we can easily carry them for ages to come... why break existing code?
No hard argument there. Cleanliness, mostly. But it's fine. I'll make stubs.
pike-devel@lists.lysator.liu.se
-
Chris Angelico -
Martin Nilsson (Coppermist) ＠ Pike (-) developers forum -
Stephen R. van den Berg -
Tobias S. Josefowitz