Hi all,
On Mon, Aug 22, 2016 at 7:55 PM, Michael Wallner wrote:
> On 22/08/16 12:44, Rowan Collins wrote:
>
>> As far as I can see, these functions exist because the XML parser
>> infrastructure needed them, and someone thought it might be handy to
>> expose them to users. Funnily enough, the int
On 22/08/16 11:55, Michael Wallner wrote:
>> As far as I can see, these functions exist because the XML parser
>> > infrastructure needed them, and someone thought it might be handy to
>> > expose them to users. Funnily enough, the internal versions actually
>> > take a parameter for the target enc
On 22/08/16 12:44, Rowan Collins wrote:
> As far as I can see, these functions exist because the XML parser
> infrastructure needed them, and someone thought it might be handy to
> expose them to users. Funnily enough, the internal versions actually
> take a parameter for the target encoding, but
On 22/08/2016 02:52, Yasuo Ohgaki wrote:
Since these
are XML module functions, the name would be xml_latin1_to_utf8() and
xml_utf8_to_latin1(). Suggestions for names are appreciated.
From a user's point of view, these functions have nothing to do with
XML, so I'm not sure the prefix really mak
On 22/08/16 03:52, Yasuo Ohgaki wrote:
> I'll update the RFC to have aliases rather than removing. Since these
> are XML module functions, the name would be xml_latin1_to_utf8() and
> xml_utf8_to_latin1(). Suggestions for names are appreciated.
+1, I think those are the names to go.
--
Regards,
Hi all,
On Sat, Aug 20, 2016 at 12:24 AM, Rowan Collins wrote:
> On 19/08/2016 16:12, Pierre Joye wrote:
>>
>> I am against removing them, now or in 8.x. this is the kind of things that
>> makes migrations painful. They are broken on some cases? Fix them maybe?
>
>
> The thing that is broken abou
On 19/08/2016 16:12, Pierre Joye wrote:
I am against removing them, now or in 8.x. this is the kind of things that
makes migrations painful. They are broken on some cases? Fix them maybe?
The thing that is broken about the functions is not the functionality,
but the name.
I suppose you could
On Aug 15, 2016 10:18 AM, "Yasuo Ohgaki" wrote:
>
> Hi all,
>
> utf8_decode() and utf8_encode() are not needed and causing problems
> than solving.
>
> https://wiki.php.net/rfc/remove_utf_8_decode_encode
>
> Proposal
> - Document deprecation them now
> - Remove them from 7.2
>
> I think only f
Hi!
>> utf8_decode()/utf8_encode are, at best, extremely misleading names.
>> Many uses of them in my experience go something like this: "I have an
>> encoding problem, it's something to do with UTF-8, I'll try
>> utf8_encode; hm, that didn't work, I'll try utf8_decode instead".
I still think if
On 15/08/2016 06:26, Stanislav Malyshev wrote:
Hi!
Hi all,
utf8_decode() and utf8_encode() are not needed and causing
problems than solving.
Why you think they are not needed?
I'm guessing this came about from their mention on another thread. To
quote myself:
utf8_decode()/utf8_encode ar
Hi!
> Hi all,
>
> utf8_decode() and utf8_encode() are not needed and causing problems
> than solving.
Why you think they are not needed?
Also, the manual says "utf8_encode — Encodes an ISO-8859-1 string to
UTF-8". If somebody uses unknown function without even glancing at the
first line of the m
On github utf8_encode have ~500.000 results and utf8_decode have ~400.000.
I too guess that 7.2 shouldn't introduces a BC like that. Maybe on 8.0.
Currently I guess that it is a good shortcut, but I really don't know
if make senses to keep it (utf16 or others are not implemented, only
utf8, for o
Hi all,
utf8_decode() and utf8_encode() are not needed and causing problems
than solving.
https://wiki.php.net/rfc/remove_utf_8_decode_encode
Proposal
- Document deprecation them now
- Remove them from 7.2
I think only few users are using and they shouldn't have problem using
mbstring/iconv
13 matches
Mail list logo
