Re: [gobo-eiffel-develop] integrating UCSTRING to gobo-eiffel

[Eric B. <er...@go...>]

Majkel,

> i think it is getting time to integrate the ucstring-cvs-repository into
> the gobo-eiffel-cvs.

Great. Do you want to give me your SourgeForge username so that
I can add write-access for you in the gobo-eiffel CVS repository?

> in the current state it is relative stable, nearly only minor
> beautifications must be done (eg "indexing"). a lot of people are
> waiting for it, so we should integrate it. the necessary modifications
> can be done if i have a little more time and cvs-access.

Yes, that's what I said in a previous message: as long as
the classes are committed with their proper names in
the proper directories, then we can take care of cosmetics
later on when time permits. Actually if you don't have
time to do it now I can take charge of it if you want.

> who will import the stuff into cvs and 

You or me. If you don't have time to do it I can do it
for you if you want. That way I could take care of the
cosmetics at the same time. Just let me know.

> whereto?

I suggest that we put it as part of the Gobo Kernel library
in cluster gobo/library/kernel/unicode:

  gobo/library/kernel/unicode/uc_string.e
  gobo/library/kernel/unicode/uc_character.e 
  ...

I noticed that you were using a class UC_SPECIFIC in
clusters spec/[ise|se|ve] with the routine: 

 code_to_character (i: INTEGER): CHARACTER

I suggest that we don't commit this class to gobo-eiffel
CVS repository and use KL_INTEGER_ROUTINES.to_character
instead. This is actually the advantage of merging several
packages into Gobo: we can now share classes instead of
duplicating these functionalities in every package. If
I'm the one who commits your unicode classes to gobo-eiffel
I'll take care of changing the code as well so that it
calls KL_INTEGER_ROUTINES.to_character instead of
UC_SPECIFIC.code_to_character.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com