[Uim] Re: Suggestion: Renaming new API functions

[YamaKen]

At Sat, 9 Oct 2004 05:52:20 +0900,
tkng at xem.jp wrote:
> 
> On Thu, 07 Oct 2004 10:06:41 +0900
> YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> 
> > At Thu, 7 Oct 2004 06:26:51 +0900,
> > tkng at xem.jp wrote:
> > > 
> > > On Fri, 01 Oct 2004 17:48:52 +0900
> > > YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> > > 
> > > > In your view, an input context HAS an input method as slave. So
> > > > each input context also has the concept 'current input context'.
> > > 
> > > Yes, but it's not my view. A uim_context keeps a list of available
> > > input methods as a struct member actually.
> > 
> > I can't find such member in struct uim_context_. What are you
> > referring to?  In my view, uim_im_array[] keeps a list of
> > available IMs in C-side.
> 
> 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?

> > uim_get_nr_im() uses uim_im_array[] to count the number of
> > available IMs. uim_context does nothing about it.
> 
> As I described above, that's very confusing. uim_get_nr_im should not
> take a uim_context as an argument. (But it's another story.)

Me too. It caused my first confusion about the uim API 2 years
ago. See you again in the another story.

> > 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.

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.

To release uim 0.4.4 sooner, I suggest a compromise which hides
the problem (for me) instead of resolving the problem. See
bottom of this mail.

> > Simply to say, the name uim_get_current_im_name() is too
> > specific about its purpose. So I want to rename it to a more
> > generic name uim_get_im_name_of_context().

> Maybe I understand your opinion.
> 
> The brief of your opinion is 'uim_get_current_im_name' is not
> appropriate because some bridges like IMKit-uim doesn't use uim's im
> switch mechanism except the function to get a name of input method,
> right?

It's *a* problem but not all. The problem source is 'The name
uim_get_current_im_name() does not reflect the internal model',
as I said above.

> 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.

>  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?

-------------------------------
YamaKen  yamaken at bp.iij4u.or.jp