Proposal for Internationalization::I18N_UnicodeNormalizer

Michel Corne (http://pear.php.net/u
ser/mcorne) proposes
Internationalization::I18N_UnicodeNormalizer.

You can find more detailed information here:
 http://pear.php.net/pepr/pepr-proposal-show.php?id=494


-- 
Sent by PEPr, the automatic proposal system at http://pear.php.net

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

David Sanders (http://pear.php.ne
t/user/shangxiao) has commented on the proposal for
Internationalization::I18N_UnicodeNormalizer.

Comment:

Instead of commenting on the usual tech stuff I'm just going
to say:  As a
dev who work on database systems, especially on the
comparison of people's
names, etc, I quite like this idea.

Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=494


-- 
Sent by PEPr, the automatic proposal system at http://pear.php.net

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Lukas Smith (http://pear.php.net/u
ser/lsmith) has commented on the proposal for
Internationalization::I18N_UnicodeNormalizer.

Comment:

Have you looked at the following .. http://pecl.php.
net/package/translit ..
without knowing what all the jargon words mean in your
proposal, I guess it
handles parts of your feature set in C. So maybe integrating
it as an
optional backend for those parts would be a good idea.

Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=494


-- 
Sent by PEPr, the automatic proposal system at http://pear.php.net

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Michel Corne wrote:
> Michel Corne (http://pear.php.net/u
ser/mcorne) proposes
Internationalization::I18N_UnicodeNormalizer.
> 
> You can find more detailed information here:
>  http://pear.php.net/pepr/pepr-proposal-show.php?id=494


Well tested and documented and definitely useful.

Arnaud.

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Till Klampaeckel (http://pear.php.net/use
r/till) has commented on the proposal for
Internationalization::I18N_UnicodeNormalizer.

Comment:

In general I like this a lot as well, since it looks like
what I've been
looking for in PHP. 

I am not sure I like the __construct($root='') part where
you prepend a
root directory to constant (a path) which is defined inside
the class and
not adjustable (through a set()).

Instead I'd remove the constant and only use the $root (and
probably call
it something else). Not sure if you have to since this
doesn't improve
performance but it wouldn't hurt to test if the directory
exists and so on
and throw an Exception.

In general, some of your code is hard to read (lines are
pretty long) and
some of the if()'s seem a bit complicated - for example,
exit early,
instead of long code inside the condition and exit in the
else part.

Then, I'd (personally) always use empty() to test instead
of, if ($foo !=
'').

But I guess that's called CS or maybe "IMHO". 

Also, you shoud list the multibyte extension as a
dependency.

Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=494


-- 
Sent by PEPr, the automatic proposal system at http://pear.php.net

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

On 11 Jun 2007 21:33:14 -0000, Till Klampaeckel <tillphp.net> wrote:
>
> Till Klampaeckel (http://pear.php.net/use
r/till) has commented on the proposal for
Internationalization::I18N_UnicodeNormalizer.
>
> Comment:
>
> In general I like this a lot as well, since it looks
like what I've been
> looking for in PHP. 

In general, and of course I forgot to add this in my comment
- great
documentation.

Cheers,
Till

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Michel Corne (http://pear.php.net/u
ser/mcorne) has commented on the proposal for
Internationalization::I18N_UnicodeNormalizer.

Comment:

Thanks for your comments. Please read my own comments below.

I would be interested to have some feedback from other
folks, especially
those who have an interest in internationalization stuff.
Also, feedback
from QA folks would be very much appreciated to let me know
if the testing
suite and the API doc is in line with PEAR's standards.
MC

[pear-dev] "...Have you looked at the following ..
http://pecl.php.
net/package/translit .."
[MC] Actually transliteration is very different from
normalization so I
doubt that there is much that I could leverage. I have not
checked that
package yet. There are 2 only methods that I wrote that are
somewhat
similar to other packages.

[pear-dev] "... not sure I like the
__construct($root='') part where you
prepend a root directory to constant (a path) which is
defined inside the
class and not adjustable..."
[MC] The $root is not meant to be used in production. This
is just a way
to trick the class to include a set of files similar to the
production ones
but customized for some of the testing. I will make this
clearer in the API
doc.

[pear-dev] "... some of your code is hard to read
(lines are pretty
long)..."
[MC] The lines are long because there is the code itself and
a comment
right after. I comment each line because it is easier for me
to maintain
the code when I go back to it weeks/months after. Also, we
have large
screens these days and editors with smart highlighting which
I believe
makes the whole things pretty readable. We also all have
different styles
to program I guess 

[pear-dev] "... some of the if()'s seem a bit
complicated - for example,
exit early, instead of long code inside the condition and
exit in the else
part..."
[MC] Good point regarding exiting early. I used to do as you
say for
years. Then I changed things more recently. I may have to
change that
back... The normalization rules are not easy to understand
nor to implement
which may reflect in the code. This requires many conditions
tests and
recursive programing. I am open to simplifying what I wrote,
please be more
specific so I can take a look at it again.

[pear-dev] "...I'd (personally) always use empty() to
test instead of, if
($foo != '')..."
[MC] Yeah, yeah... I use empty() too... depends on the day
 Note
that
it is not strictly the same thing.

[pear-dev] "...you should list the multibyte extension
as a
dependency..."
[MC] I did not know that we had to list extensions as
dependencies. No
problem. Where should I list that?

Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=494


-- 
Sent by PEPr, the automatic proposal system at http://pear.php.net

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Hi,

On 15 Jun 2007 17:26:29 -0000, Michel Corne <mcorneyahoo.com> wrote:
> [pear-dev] "... some of your code is hard to read
(lines are pretty
> long)..."
>
> [MC] The lines are long because there is the code
itself and a comment
> right after. I comment each line because it is easier
for me to maintain
> the code when I go back to it weeks/months after. Also,
we have large
> screens these days and editors with smart highlighting
which I believe
> makes the whole things pretty readable. We also all
have different styles
> to program I guess 

I am all for big screens and IDEs with fancy code
highlighting. Truth
to be told, I do not always have the luxery which is why I
really like
certain standards. But maybe that's just me.

Also, please check here:
http://pe
ar.php.net/manual/en/standards.php

In terms of line length, my number one reason to keep a line
on a
certain length is, to be able to print code later on - which
is
necessary sometimes.  Then as
I stated above, sometimes the tools
you work with are not the best.

Other reasons as of why I like "it" fixed are that
a long line really
tends to attract more errors and makes it (even for the
original
author) harder to grasp what's being done there when you
look at it a
couple weeks from now.

Also, try to keep in mind that others will look at your code
or that
maybe one day, you don't have time to update it and someone
else would
take over.

> [pear-dev] "... some of the if()'s seem a bit
complicated - for example,
> exit early, instead of long code inside the condition
and exit in the else
> part..."
>
> [MC] Good point regarding exiting early. I used to do
as you say for
> years. Then I changed things more recently. I may have
to change that
> back... The normalization rules are not easy to
understand nor to implement
> which may reflect in the code. This requires many
conditions tests and
> recursive programing. I am open to simplifying what I
wrote, please be more
> specific so I can take a look at it again.

Well, my recommendation is not a rule and I wasn't going to
suggest
that you have to do it everywhere. Just do it where it's
appropriate.

> [pear-dev] "...I'd (personally) always use empty()
to test instead of, if
> ($foo != '')..."
>
> [MC] Yeah, yeah... I use empty() too... depends on the
day 
Note that
> it is not strictly the same thing.

Not sure what you are getting at, but for what I saw in your
code,
empty() should work. I know that 0 is also empty, false,
NULL etc. as
well. So anyway, use as you see it fits, it was just a
though.

> [pear-dev] "...you should list the multibyte
extension as a
> dependency..."
>
> [MC] I did not know that we had to list extensions as
dependencies. No
> problem. Where should I list that?

On the proposal. 


Cheers,
Till

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php