[Uim] Re: Suggestion: Renaming new API functions

[TOKUNAGA Hiroyuki]

On Sat, 09 Oct 2004 10:14:42 +0900
YamaKen <yamaken at bp.iij4u.or.jp> wrote:

> > Sorry, that's my misunderstanding. (Though there is another problem,
> > developers would expect number of currently enabled input methods as
> > a return value of uim_get_nr_im, because the function take a
> > uim_context as an argument.)
> 
> I'm not sure what you expect. We can get the number of currently
> available IMs by uim_get_nr_im(). Is 'currently enabled input
> methods' differs from it?

Here available == enable.

But, uim_get_nr_im doesn't return number of currently available input
methods. For example, we cannot use uim-py on uim-xim where our locale
is ja_JP.eucJP, but returned number includes uim-py.


> > > My suggestion does not change any actual codes or behaviors. It
> > > only wants a renaming to avoid confusion.
> > > 
> > > uim_switch_im() actually performs the switching as follows.
> (snip)
> > I think we should not bother internal implementation of libuim,
> > because that make discussion (and conclusion) more difficult.
> 
> Discussion about internal model is the unavoidable procedure to
> resolve the API problem for me. It's not an auxiliary but the
> main subject.

I didn't refered to the model, I refered to the implementation.

What you mean by the word 'internal model'? It's difficult for me to
guess correctly. Model of actual libuim or developer's imagination from
function names?

> My opinion came from a policy 'API function names should reflect
> internal model to avoid misunderstanding and misuse', so I
> attempted the explanation to unify the model different between
> you and me, but it's difficult at now. We tends to consider
> design things from different aspect.

My opinion is:

Bridge developers would expect function's semantics from function's
name, thus functions should behave as developers expect. But bridge
developers should not be bothered by actual internal implementation of
libuim. In an extreme case, I think that bridge developers should not
expect libuim has a scheme interpreter. 

So, I acknowledge if the policy is 'API function names should reflect
actual behavior'.


> > What I want to say here is, do bridge developers like IMKit-uim need
> > uim_get_current_im_name?
> 
> To say fairly, I'm not sure at now.
> 
> > If they need, uim_get_current_im_name is certainly inappropriate. We
> > should change the name of function. But I don't like
> > uim_get_im_name_of_context, because _of_context make me confusing. I
> > propose _uim_get_im_name instead.
> 
> Since C does not support function overloading, we must name it
> as different from preexisting uim_get_im_name(uc, nth). So we
> need some supplemental name fragment. To achieve it, I selected
> '_of_context' suffix with little compromise, and you selected
> '_' prefix. Your selection confuses me like you are confused by
> my selection. We're so different. I don't try understanding each
> other for now to release the new version sooner.

Okay, then let's put the problem on the shelf and concentrate to release
0.4.4.

> >  If not, they should ignore the function as well as uim_switch_im.
> 
> I suggest the compromise as follows.
> 
> - separate uim_get_current_im_name() and uim_switch_im() to
>   independent header file such as uim-im-switch.h dedicated to
>   provide IM-switching API
> 
> - describe a warning about the API into the header file by me
> 
> Although it does not resolve the problem for me, it segregates
> the problem into optional part of libuim. I can accept it as
> reasonable compromise for the release.
> 
> I could do it immediately. Can you compromise?

Yes. Let's discuss again after 0.4.4 released.


Regards,

-- 
TOKUNAGA Hiroyuki
http://kodou.net/