Giters

wolkykim / qlibc

qLibc is a simple and yet powerful C library providing generic data structures and algorithms.

Home Page:http://wolkykim.github.io/qlibc

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

About next release

darkdh opened this issue · comments

commented

When can we publish next release? I want to integrate the official release to my project.
Because I need the remove_by_idx() API of the changes since 2.2.0.

commented

I'm considering some changes as you suggested as below

  • all containers support binary keys by default in put() method like
    put() - binary key, put_by_name() - strkey, putstrint() - remove
  • introduct treetbl which implements red-black BST algorithm

This will break back-ward api compatibility, so we can release final 2.x as is, then go to 3.0 with new api.
What do you think?

commented

I strongly agree with the backward compatibility. Let's take more time to think about the issue with binary key.
However, I need the final 2.x for deleting record by idx from get_next().

commented

How soon do you need? I guess you can use current code? Do you need a sold release number?

BTW, I'm actually working on tree implementation.

(One way) keep the consistent API with others like

  • put(string key, binary data)
  • putstr(string key, stirng data)
  • put_by_obj(binary key, binary data) <= just introducing new api.

(The other way) make all containers take binary key by default.
This will require changes to existing containers like hashtbl, listtbl

  • put(binary key, binary_data) -> need existing api change, need new major version update.
  • put_by_name(string key, binary data) -> need existing putstr() api change
  • putstr_by_name(string key, string data) -> need existing putstr() api change

What do you think?

commented

I feel option 2 is not something that I can decide by my own so I'm looking forward to feedbacks as many as possible on the above matter. Thanks in advance.

commented

I can wait cause I must specify the release number of 3rd party in my project.

I still think that API consistency is far more important unless some critical conditions are met.

commented

I think we can release it by end of this week or early next week.
I made some standard compliant changes and it's on master, could you please check with your package just to make sure it doesn't break anything?

I still think that API consistency is far more important unless some critical conditions are met.

So you like option 1? just adding put_by_obj, get_by_obj and delete_by_obj which takes binary key. This approach will be made not only for new tree table but also qhashtbl, qhasharr, qlisttbl eventually.

commented

Thanks for the release and I will check the changes. If anything went wrong, I will let you know.

I prefer option 1 for short term consideration in case of someone with the urgent need. However, if it is the major release change like 3.0. I think we should redesign the binary key architecture for these tables. So I agree with either option 1 or 2.

commented

New release 2.3.0 has just came out. Thanks!

commented

I can't wait to integrate. Thank you.