Przemyslaw Czerpak wrote:
I think that's not the question, but rather if we want to
keep the RTE in hb_HGet() at all.

Exactly.

xhb compatibility is not a concern BTW, because it uses
different function names anyway.

Because you asked to translate most of them. At the beginning
this implementation was using xHarbour compatible API. Anyhow
I do not think we have to be strictly compatible with RTE in
such functions.


Hi,


if you feel that some hash's properties or internals are heritage of xHarbour, and it would be better to implement it another way, please do it. I'm always for better implementation even with a little cost of backward compatibility. I've changed HB_HGet() to aHash[...] in my code, and have nothing against changes related RTE behavior of this function.


One more remainder about i18n. We had a large discussion about i18n internals, but that about it's public API? We have __*() functions:
__I18N_SAVE()
__I18N_LOADFROMMEMORY()
__I18N_LOAD()
__I18N_GETTEXT()

xHarbour has:
HB_I18NLOADTABLE()
HB_I18NSORTTABLE()
HB_I18NSAVETABLE()
I18N()
HB_I18NSETPATH()
HB_I18NGETPATH()
HB_I18NSETLANGUAGE()
HB_I18NGETLANGUAGE()
HB_I18NGETLANGUAGENAME()
HB_I18NGETBASELANGUAGE()
HB_I18NGETBASELANGUAGENAME()
HB_I18NSETBASELANGUAGE()
HB_I18NINITIALIZED()

Current __*() prefix makes me understand, it is not the final version. I would like to have final implementation of it. What should be the final public API for i18n?



Best regards,
Mindaugas

_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to