Hi internals!
The mbstring extension supports replacing PHP string functions with
multibyte variants through the mbstring.func_overload ini option.
This ini setting is a real PITA for code compatibility, as it makes it
impossible to rely on the output of even the most basic PHP functions, like
strlen(). Security-critical code in libraries and frameworks typically
handles this issue by conditionally using either strlen() or 8bit
mb_strlen(). Apart from that, the issue is generally ignored.
If we do not wish to drop support for this option in PHP 7, I would at
least suggest to deprecate it.
Thoughts?
Nikita
De : Nikita Popov [mailto:nikita.ppv@gmail.com]
The mbstring extension supports replacing PHP string functions with
multibyte variants through the mbstring.func_overload ini option.This ini setting is a real PITA for code compatibility, as it makes it
impossible to rely on the output of even the most basic PHP functions, like
strlen(). Security-critical code in libraries and frameworks typically
handles this issue by conditionally using eitherstrlen()or 8bit
mb_strlen(). Apart from that, the issue is generally ignored.If we do not wish to drop support for this option in PHP 7, I would at
least suggest to deprecate it.
Probably fine, but how does your suggestion fit in the PHP 7 timeline ? The BC break requires it is introduced in 7.0. And it is too late for this. As everyone seems to be against delaying the timeline, I hope we won't accept exceptions.
Regards
François
Hi
2015-03-24 14:39 GMT+01:00 François Laupretre francois@php.net:
Probably fine, but how does your suggestion fit in the PHP 7 timeline ? The BC break requires it is introduced in 7.0. And it is too late for this. As everyone seems to be against delaying the timeline, I hope we won't accept exceptions.
This is a per extension change, and I don't see any harm in this going
into 7.1, like we deprecated ext/mysql in a minor version too, which
is even bigger than this layer.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Am 24.03.2015 um 14:39 schrieb François Laupretre francois@php.net:
De : Nikita Popov [mailto:nikita.ppv@gmail.com]
The mbstring extension supports replacing PHP string functions with
multibyte variants through the mbstring.func_overload ini option.This ini setting is a real PITA for code compatibility, as it makes it
impossible to rely on the output of even the most basic PHP functions, like
strlen(). Security-critical code in libraries and frameworks typically
handles this issue by conditionally using eitherstrlen()or 8bit
mb_strlen(). Apart from that, the issue is generally ignored.If we do not wish to drop support for this option in PHP 7, I would at
least suggest to deprecate it.Probably fine, but how does your suggestion fit in the PHP 7 timeline ? The BC break requires it is introduced in 7.0. And it is too late for this. As everyone seems to be against delaying the timeline, I hope we won't accept exceptions.
Regards
François
No, he isn't asking for delaying the timeline. He's asking if we can do this without RFC. Minimal self-contained changes don't need a RFC and can go as well into alpha/beta phase without issues.
Nikita, I assume with dropping you meant throwing a warning in case the option is detected and remove its functionality? Removing it completely in 7.0 may cause silent failures...
If yes, I'm fine with dropping that ini switch.
Thanks,
Bob
De : Bob Weinand [mailto:bobwei9@hotmail.com]
No, he isn't asking for delaying the timeline. He's asking if we can do this
without RFC. Minimal self-contained changes don't need a RFC and can go as
well into alpha/beta phase without issues.
Sorry, I don't understand when a change is supposed to require an RFC or not, and when it can come after feature freeze or not. Is it written somewhere ? What is the definition of a 'minimal self-contained' change ? Why is it different if it belongs to an extension ?
I may be wrong but the proposed change is not what I call a 'minimal self-contained' change and there's a clear BC break. I'd love it to be part of 7.0 but I would first appreciate to be sure the rules are the same for everyone.
Regards
François
François Laupretre wrote on 24/03/2015 16:30:
De : Bob Weinand [mailto:bobwei9@hotmail.com]
No, he isn't asking for delaying the timeline. He's asking if we can do this
without RFC. Minimal self-contained changes don't need a RFC and can go as
well into alpha/beta phase without issues.
Sorry, I don't understand when a change is supposed to require an RFC or not, and when it can come after feature freeze or not. Is it written somewhere ? What is the definition of a 'minimal self-contained' change ? Why is it different if it belongs to an extension ?I may be wrong but the proposed change is not what I call a 'minimal self-contained' change and there's a clear BC break. I'd love it to be part of 7.0 but I would first appreciate to be sure the rules are the same for everyone.
Agreed, this is quite a major feature, and pretty much everything in PHP
is an "extension" as far as the architecture is concerned.
While I agree it would be great to phase this functionality out, I don't
see how that can be done without an RFC.
Regards,
Rowan Collins
[IMSoP]
François Laupretre wrote on 24/03/2015 16:30:
De : Bob Weinand [mailto:bobwei9@hotmail.com]
No, he isn't asking for delaying the timeline. He's asking if we can do
this
without RFC. Minimal self-contained changes don't need a RFC and can go
as
well into alpha/beta phase without issues.Sorry, I don't understand when a change is supposed to require an RFC or
not, and when it can come after feature freeze or not. Is it written
somewhere ? What is the definition of a 'minimal self-contained' change ?
Why is it different if it belongs to an extension ?I may be wrong but the proposed change is not what I call a 'minimal
self-contained' change and there's a clear BC break. I'd love it to be part
of 7.0 but I would first appreciate to be sure the rules are the same for
everyone.Agreed, this is quite a major feature, and pretty much everything in PHP is
an "extension" as far as the architecture is concerned.While I agree it would be great to phase this functionality out, I don't see
how that can be done without an RFC.
If we deprecate it I am fine with doing this without an RFC. Removing
it would need an RFC in my opinion.
Levi Morrison wrote on 24/03/2015 20:35:
François Laupretre wrote on 24/03/2015 16:30:
De : Bob Weinand [mailto:bobwei9@hotmail.com]
No, he isn't asking for delaying the timeline. He's asking if we can do
this
without RFC. Minimal self-contained changes don't need a RFC and can go
as
well into alpha/beta phase without issues.
Sorry, I don't understand when a change is supposed to require an RFC or
not, and when it can come after feature freeze or not. Is it written
somewhere ? What is the definition of a 'minimal self-contained' change ?
Why is it different if it belongs to an extension ?I may be wrong but the proposed change is not what I call a 'minimal
self-contained' change and there's a clear BC break. I'd love it to be part
of 7.0 but I would first appreciate to be sure the rules are the same for
everyone.Agreed, this is quite a major feature, and pretty much everything in PHP is
an "extension" as far as the architecture is concerned.While I agree it would be great to phase this functionality out, I don't see
how that can be done without an RFC.
If we deprecate it I am fine with doing this without an RFC. Removing
it would need an RFC in my opinion.
But a decision to "deprecate" just means "remove, but not yet", so either way we're making a decision about what features the language will have, and skipping the established process in the name of convenience.
I wonder if people are confusing the fact that they don't like this feature, and don't need it, with it being a "minor" feature. There are definitely people out there using it, and the impact of removing it may be considerable to them. There is also the question of what we are deprecating it in favour of.
Remember that it's perfectly acceptable to deprecate something in a minor release, so if by the time of 7.1 or 7.2 a new way of working with Unicode or character set aware strings is taking shape, we could deprecate in favour of that.
Or, if we think that the costs of including the feature are too great, and forcing use of mb_* functions directly is appropriate, we can deprecate in 7.1, presumably waiting until 8.0 to make the breaking change of removal.
Once again, the decisions taken are that there is no 5.7 for deprecation, and no more RFCs allowed for 7.0 anyway. If we're going to stick to those decisions, we have to accept that ideas we come up with now will have to wait until 7.1 (next year) or 8.0 (4 to 5 years time).
Regards,
Rowan Collins
[IMSoP]
Levi Morrison wrote on 24/03/2015 20:35:
On Tue, Mar 24, 2015 at 11:30 AM, Rowan Collins rowan.collins@gmail.com
wrote:François Laupretre wrote on 24/03/2015 16:30:
De : Bob Weinand [mailto:bobwei9@hotmail.com]
No, he isn't asking for delaying the timeline. He's asking if we can do
this
without RFC. Minimal self-contained changes don't need a RFC and can go
as
well into alpha/beta phase without issues.Sorry, I don't understand when a change is supposed to require an RFC or
not, and when it can come after feature freeze or not. Is it written
somewhere ? What is the definition of a 'minimal self-contained' change
?
Why is it different if it belongs to an extension ?I may be wrong but the proposed change is not what I call a 'minimal
self-contained' change and there's a clear BC break. I'd love it to be
part
of 7.0 but I would first appreciate to be sure the rules are the same
for
everyone.Agreed, this is quite a major feature, and pretty much everything in PHP
is
an "extension" as far as the architecture is concerned.While I agree it would be great to phase this functionality out, I don't
see
how that can be done without an RFC.If we deprecate it I am fine with doing this without an RFC. Removing
it would need an RFC in my opinion.But a decision to "deprecate" just means "remove, but not yet", so either
way we're making a decision about what features the language will have, and
skipping the established process in the name of convenience.I wonder if people are confusing the fact that they don't like this feature,
and don't need it, with it being a "minor" feature. There are definitely
people out there using it, and the impact of removing it may be considerable
to them. There is also the question of what we are deprecating it in favour
of.
To me it is buggy. It is a partial implementation to begin with. An
app has no idea what is supported or not, custom extensions will call
native APIs without taking care about what the PHP exposed functions
are.
Remember that it's perfectly acceptable to deprecate something in a minor
release, so if by the time of 7.1 or 7.2 a new way of working with Unicode
or character set aware strings is taking shape, we could deprecate in favour
of that.Or, if we think that the costs of including the feature are too great, and
forcing use of mb_* functions directly is appropriate, we can deprecate in
7.1, presumably waiting until 8.0 to make the breaking change of removal.
That's the way to go, to use mb_* directly or even better, ICU related APIs.
Once again, the decisions taken are that there is no 5.7 for deprecation,
and no more RFCs allowed for 7.0 anyway. If we're going to stick to those
decisions, we have to accept that ideas we come up with now will have to
wait until 7.1 (next year) or 8.0 (4 to 5 years time).
I think we will have more of these cases, and some without consensus.
We chose not to have 5.7, so be it.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Pierre Joye wrote on 25/03/2015 13:19:
Levi Morrison wrote on 24/03/2015 20:35:
On Tue, Mar 24, 2015 at 11:30 AM, Rowan Collins rowan.collins@gmail.com
wrote:François Laupretre wrote on 24/03/2015 16:30:
De : Bob Weinand [mailto:bobwei9@hotmail.com]
No, he isn't asking for delaying the timeline. He's asking if we can do
this
without RFC. Minimal self-contained changes don't need a RFC and can go
as
well into alpha/beta phase without issues.
Sorry, I don't understand when a change is supposed to require an RFC or
not, and when it can come after feature freeze or not. Is it written
somewhere ? What is the definition of a 'minimal self-contained' change
?
Why is it different if it belongs to an extension ?I may be wrong but the proposed change is not what I call a 'minimal
self-contained' change and there's a clear BC break. I'd love it to be
part
of 7.0 but I would first appreciate to be sure the rules are the same
for
everyone.Agreed, this is quite a major feature, and pretty much everything in PHP
is
an "extension" as far as the architecture is concerned.While I agree it would be great to phase this functionality out, I don't
see
how that can be done without an RFC.
If we deprecate it I am fine with doing this without an RFC. Removing
it would need an RFC in my opinion.But a decision to "deprecate" just means "remove, but not yet", so either
way we're making a decision about what features the language will have, and
skipping the established process in the name of convenience.I wonder if people are confusing the fact that they don't like this feature,
and don't need it, with it being a "minor" feature. There are definitely
people out there using it, and the impact of removing it may be considerable
to them. There is also the question of what we are deprecating it in favour
of.
To me it is buggy. It is a partial implementation to begin with. An
app has no idea what is supported or not, custom extensions will call
native APIs without taking care about what the PHP exposed functions
are.
I agree with the reasoning, but again, that's justification for its
removal, not justification for skipping the RFC process.
I think there should be a quick RFC collecting this reasoning, and a
formal invitation for contrary opinions, to avoid accusations that it
was slipped in the back door. If there really is no opposition, the RFC
will record that the vote was unanimous, and be a point of reference to
anyone looking for more explanation than the manual provides.
Regards,
Rowan Collins
[IMSoP]
De : Rowan Collins [mailto:rowan.collins@gmail.com]
I think there should be a quick RFC collecting this reasoning, and a
formal invitation for contrary opinions, to avoid accusations that it
was slipped in the back door. If there really is no opposition, the RFC
will record that the vote was unanimous, and be a point of reference to
anyone looking for more explanation than the manual provides.
Quick or not, even deprecations requires an RFC and a formal vote, unless a special rule is written somewhere. And the RFC must clearly describe and plan the next step, because deprecation is temporary.
I asked for an additional delay for 7.0 feature freeze and it was clearly rejected. So, IMO, even deprecation cannot go to 7.0. The best we can do is to deprecate in 7.1 and remove in 8.0, and I'll oppose any attempt to introduce exceptions in 7.0 (just because it would mean that the rules are not the same for everyone).
For those claiming that it is 'merely a deprecation', that it won't 'break anything', and that ' people will have plenty of time to gracefully migrate their codebases', please remember that the coercive STH RFC was rejected mainly because some deprecations were considered as unacceptable BC breaks. So, there's no more permissive rules for deprecations.
Regards
François
-----Original Message-----
From: Nikita Popov [mailto:nikita.ppv@gmail.com]
Sent: Tuesday, March 24, 2015 4:45 AM
To: PHP internals
Subject: [PHP-DEV] Deprecate or remove mbstring function overloads in PHP
7Hi internals!
The mbstring extension supports replacing PHP string functions with
multibyte variants through the mbstring.func_overload ini option.This ini setting is a real PITA for code compatibility, as it makes it
impossible
to rely on the output of even the most basic PHP functions, likestrlen().
Security-critical code in libraries and frameworks typically handles this
issue
by conditionally using eitherstrlen()or 8bitmb_strlen(). Apart from
that, the
issue is generally ignored.If we do not wish to drop support for this option in PHP 7, I would at
least
suggest to deprecate it.Thoughts?
I think we need to understand how it's actually being used before discussing
its deprecation. IIRC it's extremely widely used in Japan, but could be
wrong.
I'd want to hear from our Japanese contributors what their thoughts are.
Zeev
Rui agreed the deprecation and Yasuo gave notice to PHP internal in April
https://bugs.php.net/bug.php?id=65785
http://marc.info/?l=php-internals&m=133548185505478&w=2
2015-03-25 0:25 GMT+09:00 Zeev Suraski zeev@zend.com:
-----Original Message-----
From: Nikita Popov [mailto:nikita.ppv@gmail.com]
Sent: Tuesday, March 24, 2015 4:45 AM
To: PHP internals
Subject: [PHP-DEV] Deprecate or remove mbstring function overloads in PHP
7Hi internals!
The mbstring extension supports replacing PHP string functions with
multibyte variants through the mbstring.func_overload ini option.This ini setting is a real PITA for code compatibility, as it makes it
impossible
to rely on the output of even the most basic PHP functions, like
strlen().
Security-critical code in libraries and frameworks typically handles this
issue
by conditionally using eitherstrlen()or 8bitmb_strlen(). Apart from
that, the
issue is generally ignored.If we do not wish to drop support for this option in PHP 7, I would at
least
suggest to deprecate it.Thoughts?
I think we need to understand how it's actually being used before
discussing
its deprecation. IIRC it's extremely widely used in Japan, but could be
wrong.
I'd want to hear from our Japanese contributors what their thoughts are.Zeev
Rui agreed the deprecation and Yasuo gave notice to PHP internal in April
https://bugs.php.net/bug.php?id=65785
http://marc.info/?l=php-internals&m=133548185505478&w=2
Deprecation is fine and I am sure we will have more until we reach
beta. We should reach a real consensus on that. Case like this one are
rather obvious, no big deal and we discussed that already, nobody
opposed it.
Thaat being said, I do agree with Francois here, bigger changes or
removals require RFC, no matter how good they are. We must not allow
double standards, no matter for who or what.
Cheers,
Pierre
Masaki Kagaya wrote on 25/03/2015 02:47:
Rui agreed the deprecation and Yasuo gave notice to PHP internal in April
https://bugs.php.net/bug.php?id=65785
http://marc.info/?l=php-internals&m=133548185505478&w=2
In that case, it's a shame that wasn't followed through with an RFC at
the time, which would have allowed us to remove it for PHP 7.
As it is, I don't see how we can justify removing it outright with no
warning to end users, and if we're only deprecating, there's no hurry,
because we can deprecate in 7.1.
It might be a reasonable idea for RFCs targeting 7.1 to sit in a list of
drafts for now, and enter full discussion once 7.0 is out the door.
Regards,
Rowan Collins
[IMSoP]
"Zeev Suraski" wrote in message
news:66c0cca2453de53bed0328af2732c7bd@mail.gmail.com...
-----Original Message-----
From: Nikita Popov [mailto:nikita.ppv@gmail.com]
Sent: Tuesday, March 24, 2015 4:45 AM
To: PHP internals
Subject: [PHP-DEV] Deprecate or remove mbstring function overloads in PHP
7Hi internals!
The mbstring extension supports replacing PHP string functions with
multibyte variants through the mbstring.func_overload ini option.This ini setting is a real PITA for code compatibility, as it makes it
impossible
to rely on the output of even the most basic PHP functions, like
strlen().
Security-critical code in libraries and frameworks typically handles this
issue
by conditionally using eitherstrlen()or 8bitmb_strlen(). Apart from
that, the
issue is generally ignored.If we do not wish to drop support for this option in PHP 7, I would at
least
suggest to deprecate it.Thoughts?
I think we need to understand how it's actually being used before
discussing
its deprecation. IIRC it's extremely widely used in Japan, but could be
wrong.
I'd want to hear from our Japanese contributors what their thoughts are.Zeev
I sell my software in several Asian countries, and they regularly use this
ini option. Unless you can point to a fully-supported alternative I am
against dropping this option.
--
Tony Marston
"Zeev Suraski" wrote in message news:66c0cca2453de53bed0328af2732c7
bd@mail.gmail.com...-----Original Message-----
From: Nikita Popov [mailto:nikita.ppv@gmail.com]
Sent: Tuesday, March 24, 2015 4:45 AM
To: PHP internals
Subject: [PHP-DEV] Deprecate or remove mbstring function overloads in PHP
7Hi internals!
The mbstring extension supports replacing PHP string functions with
multibyte variants through the mbstring.func_overload ini option.This ini setting is a real PITA for code compatibility, as it makes it
impossible
to rely on the output of even the most basic PHP functions, like
strlen().
Security-critical code in libraries and frameworks typically handles this
issue
by conditionally using eitherstrlen()or 8bitmb_strlen(). Apart from
that, the
issue is generally ignored.If we do not wish to drop support for this option in PHP 7, I would at
least
suggest to deprecate it.Thoughts?
I think we need to understand how it's actually being used before
discussing
its deprecation. IIRC it's extremely widely used in Japan, but could be
wrong.
I'd want to hear from our Japanese contributors what their thoughts are.Zeev
I sell my software in several Asian countries, and they regularly use this
ini option. Unless you can point to a fully-supported alternative I am
against dropping this option.
With the best will in the world, the fully supported alternative is to
explicitly use the mbstring functions and handle encodings correctly. For
the most part, one could trivially attain identical functionality without
falling foul of the deprecation by means of a simple search/replace. The
purpose of a change like this would be to remove a wtf factor and encourage
people to write more explicit code.
Note also that what is being proposed here is merely a deprecation - it
won't actually break anything, giving people plenty of time to gracefully
migrate their codebases.
That said, in the interests of not causing people using this functionality
issues with logs full of errors and/or error-related performance issues, I
would support having this deprecation set up in such a way that an error is
only issued at most once per request - there's no need to issue a
deprecation warning at every function call.
--
Tony Marston
Chris Wright wrote on 25/03/2015 13:44:
That said, in the interests of not causing people using this functionality
issues with logs full of errors and/or error-related performance issues, I
would support having this deprecation set up in such a way that an error is
only issued at most once per request - there's no need to issue a
deprecation warning at every function call.
I guess the advantage of doing it on each function call is that you see
which areas of code are relying on the feature, rather than just that
it's enabled.
Maybe we need a smarter way of signalling deprecation in general,
because it's very all-or-nothing at the moment. But that could possibly
be implemented as a userland error handler which de-duped errors before
outputting them.
Regards,
Rowan Collins
[IMSoP]
Chris Wright wrote on 25/03/2015 13:44:
That said, in the interests of not causing people using this functionality
issues with logs full of errors and/or error-related performance issues, I
would support having this deprecation set up in such a way that an error
is
only issued at most once per request - there's no need to issue a
deprecation warning at every function call.I guess the advantage of doing it on each function call is that you see
which areas of code are relying on the feature, rather than just that it's
enabled.
Indeed, valid point
Maybe we need a smarter way of signalling deprecation in general, because
it's very all-or-nothing at the moment. But that could possibly be
implemented as a userland error handler which de-duped errors before
outputting them.
In this specific case we could modify the behaviour of the value of the ini
setting to make this configurable. As it stands, the value is treated as a
bit mask with three bits that have meaning, we could make the fourth bit
mean "issue an error on every function call" when set, if it's clear then
issue a warning only once during rinit when the value is non-zero.
I realise this is a slightly horrible solution, just throwing it out there
as a possibility. I'd argue that it's not really any more horrible than
the feature in general, though.
Regards,
Rowan Collins
[IMSoP]
Hi all,
I think we need to understand how it's actually being used before
discussing
its deprecation. IIRC it's extremely widely used in Japan, but could be
wrong.
I'd want to hear from our Japanese contributors what their thoughts are.
I'm +1 for this change.
Having E_DEPRECATE before removing would be nice. Some users may rely on
this.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi!
I was never happy about this particular hack but that said, unless we
know it is not used widely (and I suspect it is in Japan etc. where we
don't have a lot of visibility due to language barrier) we can't really
remove it.
Also, I'm not sure why should we remove it. Yes, it's a PITA for the
code, but looking at it in another direction, it is only a PITA if
people actually turn it on, which means they're using it (otherwise why
turn it on?). Deprecating it may be ok provided we actually have some
proposal as to what people should do instead.
If we have consensus on deprecating it, I don't think it's a problem
have it done in 7.0 since it's not a substantial code/feature change and
beta period provides ample time for people to scream if it's
unacceptable. If there's no consensus yet, I'd go for 7.1.
--
Stas Malyshev
smalyshev@gmail.com
On Fri, Mar 27, 2015 at 11:11 PM, Stanislav Malyshev smalyshev@gmail.com
wrote:
Hi!
I was never happy about this particular hack but that said, unless we
know it is not used widely (and I suspect it is in Japan etc. where we
don't have a lot of visibility due to language barrier) we can't really
remove it.
Also, I'm not sure why should we remove it. Yes, it's a PITA for the
code, but looking at it in another direction, it is only a PITA if
people actually turn it on, which means they're using it (otherwise why
turn it on?). Deprecating it may be ok provided we actually have some
proposal as to what people should do instead.If we have consensus on deprecating it, I don't think it's a problem
have it done in 7.0 since it's not a substantial code/feature change and
beta period provides ample time for people to scream if it's
unacceptable. If there's no consensus yet, I'd go for 7.1.
From this thread, I'd say we have a consensus to deprecate it. From the
Japanese side, both Yasuo and Masaki agree that this should be dropped and
Masaki also linked a bug report where it is stated that the original author
of this functionality agrees that this should be deprecated. It also
contains a link to a discussion on a Japanese PHP dev ML, where, as far as
Google Translate can tell me, everyone agreed that that we should do away
with it.
As to what people should use instead: For the quick hack to make things
work: a sed script. Apart from that, implementing proper multibyte handling
in applications.
Nikita
From this thread, I'd say we have a consensus to deprecate it. From the
Japanese side, both Yasuo and Masaki agree that this should be dropped and
Masaki also linked a bug report where it is stated that the original
author
of this functionality agrees that this should be deprecated. It also
contains a link to a discussion on a Japanese PHP dev ML, where, as far as
Google Translate can tell me, everyone agreed that that we should do away
with it.
Yes, and if it helps, I asked around here (South Eastern Asia) and could
not find anyone using it, not representative but representing quite a lot
of companies.
As to what people should use instead: For the quick hack to make things
work: a sed script. Apart from that, implementing proper multibyte
handling
in applications.Nikita
"Nikita Popov" wrote in message
news:CAF+90c9ZCE4rrdtwoqwnBE=u_s4aSXHU4N_Jia+40OY_gumjaA@mail.gmail.com...
On Fri, Mar 27, 2015 at 11:11 PM, Stanislav Malyshev smalyshev@gmail.com
wrote:Hi!
I was never happy about this particular hack but that said, unless we
know it is not used widely (and I suspect it is in Japan etc. where we
don't have a lot of visibility due to language barrier) we can't really
remove it.Also, I'm not sure why should we remove it. Yes, it's a PITA for the
code, but looking at it in another direction, it is only a PITA if
people actually turn it on, which means they're using it (otherwise why
turn it on?). Deprecating it may be ok provided we actually have some
proposal as to what people should do instead.If we have consensus on deprecating it, I don't think it's a problem
have it done in 7.0 since it's not a substantial code/feature change and
beta period provides ample time for people to scream if it's
unacceptable. If there's no consensus yet, I'd go for 7.1.From this thread, I'd say we have a consensus to deprecate it. From the
Japanese side, both Yasuo and Masaki agree that this should be dropped and
Masaki also linked a bug report where it is stated that the original author
of this functionality agrees that this should be deprecated. It also
contains a link to a discussion on a Japanese PHP dev ML, where, as far as
Google Translate can tell me, everyone agreed that that we should do away
with it.As to what people should use instead: For the quick hack to make things
work: a sed script. Apart from that, implementing proper multibyte handling
in applications.Nikita
But what is "proper" multibyte handling? Where is it documented?
--
Tony Marston
"Nikita Popov" wrote in message
news:CAF+90c9ZCE4rrdtwoqwnBE=u_s4aSXHU4N_Jia+40OY_gumjaA@mail.gmail.com...On Fri, Mar 27, 2015 at 11:11 PM, Stanislav Malyshev smalyshev@gmail.com
wrote:Hi!
I was never happy about this particular hack but that said, unless we
know it is not used widely (and I suspect it is in Japan etc. where we
don't have a lot of visibility due to language barrier) we can't really
remove it.Also, I'm not sure why should we remove it. Yes, it's a PITA for the
code, but looking at it in another direction, it is only a PITA if
people actually turn it on, which means they're using it (otherwise why
turn it on?). Deprecating it may be ok provided we actually have some
proposal as to what people should do instead.If we have consensus on deprecating it, I don't think it's a problem
have it done in 7.0 since it's not a substantial code/feature change and
beta period provides ample time for people to scream if it's
unacceptable. If there's no consensus yet, I'd go for 7.1.From this thread, I'd say we have a consensus to deprecate it. From the
Japanese side, both Yasuo and Masaki agree that this should be dropped and
Masaki also linked a bug report where it is stated that the original
author
of this functionality agrees that this should be deprecated. It also
contains a link to a discussion on a Japanese PHP dev ML, where, as far as
Google Translate can tell me, everyone agreed that that we should do away
with it.As to what people should use instead: For the quick hack to make things
work: a sed script. Apart from that, implementing proper multibyte
handling
in applications.Nikita
But what is "proper" multibyte handling? Where is it documented?
Just to be sure it is clear:
We are not talking about deprecating the mbstring extenson, not at all.
What we refer to is about deprecating the PHP functions overloading in
mbstring. This can be enabled using:
http://php.net/manual/en/mbstring.configuration.php#ini.mbstring.func-overload
and
http://php.net/manual/en/mbstring.overload.php
So far, I know nobody outside the original authors actually using it.
And I asked quite a lot of companies and devs around here (hint,
Asia).
Cheers,
Pierre
@pierrejoye | http://www.libgd.org