Hi,
The proposed patch completely removes ext/mbstring compile-time
dependencies. As result the same php binaries may be used for Asian and
European languages without performance degradation. ext/mbstring now may
be compiled as a DSO. I'm going to commit the patch on Wednesday.
Any comments a
On Mon, Dec 6, 2010 at 09:31, Dmitry Stogov wrote:
> Hi,
>
> The proposed patch completely removes ext/mbstring compile-time
> dependencies. As result the same php binaries may be used for Asian and
> European languages without performance degradation. ext/mbstring now may be
> compiled as a DSO.
Hi,
How about using the value of mbstring.script_encoding to determine
whether to enable the encoding conversion feature? If the value is
the same as that of mbstring.internal_encoding, then no conversion
should be needed in the first place. Besides we can define some
singular value like "none"
Thanks. Already removed it.
Dmitry.
On 12/06/2010 01:21 PM, Hannes Magnússon wrote:
On Mon, Dec 6, 2010 at 09:31, Dmitry Stogov wrote:
Hi,
The proposed patch completely removes ext/mbstring compile-time
dependencies. As result the same php binaries may be used for Asian and
European language
Hi Moriyoshi,
On 12/06/2010 01:31 PM, Moriyoshi Koizumi wrote:
Hi,
How about using the value of mbstring.script_encoding to determine
whether to enable the encoding conversion feature? If the value is
the same as that of mbstring.internal_encoding, then no conversion
should be needed in the fi
On 5 December 2010 16:47, wrote:
> If I have an object called "PiggyBank", with the property "dollars" set to
> 5, "dimes" set to 4 and "nickles" set to 1, then I get the contents of the
> property "Total", I can predict it will give me the value 5.45. That is
> what properties are really for.
> On 5 December 2010 16:47, wrote:
>> If I have an object called "PiggyBank", with the property "dollars" set
>> to
>> 5, "dimes" set to 4 and "nickles" set to 1, then I get the contents of
>> the
>> property "Total", I can predict it will give me the value 5.45. Â That
>> is
>> what properties a
>> > The "original purpose" being, specifically, "smarter class members",
>> > correct? (The internal syntax to define them we can bikeshed later;
>> > determining the external syntax and semantics has to come first.)
>>
>> Well when saying "original purpose" I was referring to exactly this:
>>
>>
On Mon, Dec 6, 2010 at 7:49 PM, Dmitry Stogov wrote:
> Hi Moriyoshi,
>
> On 12/06/2010 01:31 PM, Moriyoshi Koizumi wrote:
>>
>> Hi,
>>
>> How about using the value of mbstring.script_encoding to determine
>> whether to enable the encoding conversion feature? If the value is
>> the same as that of
Hi,
The patch almost looks good to me, but we should be more careful about
introducing a set of hook points into the API. I think it'd be great
if the multipart parser portion was rewritten so that it would only
call the Zend multibyte API's despite a slight performance drawback.
Regards,
Moriyo
Whether you are purchasing a new subscription, renewing an old one, or
advertising with us all purchases allow you to choose one of many wonderful
holiday gifts.
It's our way of thanking you for your business.
Visit our Holiday Special Page and look around. There are some great gifts for
RFC __autodefine / spl_autodefine
This proposal proposes to introduce one function for automagically
defining missing definitions at run time.
The reader should have a reasonable level of PHP knowledge and
computer languages when reading this proposal.
Note: Whenever __autodefine is used, also spl
hi,
Please put it in the wiki :)
On Mon, Dec 6, 2010 at 8:38 PM, Loon, Reinier van
wrote:
> RFC __autodefine / spl_autodefine
>
> This proposal proposes to introduce one function for automagically
> defining missing definitions at run time.
> The reader should have a reasonable level of PHP know
On 12/06/2010 08:38 PM, Loon, Reinier van wrote:
Note: Whenever __autodefine is used, also spl_autodefine is meant.
__autoload() should die (as in get deprecated ASAP and later removed),
please do not add new __auto*() functions. Note that this does not mean
that I agree or disagree with the
On 12/06/2010 08:38 PM, Moriyoshi Koizumi wrote:
Hi,
The patch almost looks good to me, but we should be more careful about
introducing a set of hook points into the API. I think it'd be great
if the multipart parser portion was rewritten so that it would only
call the Zend multibyte API's desp
On 12/06/2010 08:25 PM, Moriyoshi Koizumi wrote:
On Mon, Dec 6, 2010 at 7:49 PM, Dmitry Stogov wrote:
Hi Moriyoshi,
On 12/06/2010 01:31 PM, Moriyoshi Koizumi wrote:
Hi,
How about using the value of mbstring.script_encoding to determine
whether to enable the encoding conversion feature? If
On Tue, Dec 7, 2010 at 5:57 AM, Dmitry Stogov wrote:
> On 12/06/2010 08:25 PM, Moriyoshi Koizumi wrote:
>>
>> On Mon, Dec 6, 2010 at 7:49 PM, Dmitry Stogov wrote:
>>>
>>> Hi Moriyoshi,
>>>
>>> On 12/06/2010 01:31 PM, Moriyoshi Koizumi wrote:
Hi,
How about using the value of mb
Hi Sebastien,
> __autoload() should die (as in get deprecated ASAP and later removed)
I couldn't find anything about your opinions on this so I was wondering if
you could elaborate. Do you consider autoloading as a bad practice or just
that spl_autoload_register should be used to add relevant
On Monday, December 06, 2010 6:59:08 pm Ross Masters wrote:
> Hi Sebastien,
>
> > __autoload() should die (as in get deprecated ASAP and later removed)
>
> I couldn't find anything about your opinions on this so I was wondering if
> you could elaborate. Do you consider autoloading as a bad pract
The very simple attached patch adds an option to disable POST data
processing, which implies the data can only be read in a stream fashion
through php://input.
As far as I know, PHP offers no way to inhibit processing RFC 1867 data
and one has to use very hacky means to accomplish that. Thi
Am 07.12.2010 05:44, schrieb Larry Garfield:
> spl_autoload() does not suffer from this short-sighted problem but
> accomplishes the same goal in a much more robust fashion.
Exactly.
--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/
On 12/07/2010 03:32 AM, Moriyoshi Koizumi wrote:
On Tue, Dec 7, 2010 at 5:57 AM, Dmitry Stogov wrote:
On 12/06/2010 08:25 PM, Moriyoshi Koizumi wrote:
On Mon, Dec 6, 2010 at 7:49 PM, Dmitry Stogovwrote:
Hi Moriyoshi,
On 12/06/2010 01:31 PM, Moriyoshi Koizumi wrote:
Hi,
How about usi
22 matches
Mail list logo
