On Mon, Feb 2, 2015 at 11:50 PM, Stanislav Malyshev wrote:
> Hi!
>
>> I personally would use spaceship operator often, but only if PHP had
>> operator overloading for classes. So I hope it will pass and operator
>
> PHP has operator overloading for classes, but just for internal ones.
> See: https
Hi!
> True, but obviously, us who want strict typehints want to be able to do this:
Obviously, but it doesn't mean whole language should be changed to serve
one use case, especially the one that goes contrary to what happened in
PHP for decades.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Inte
I completely agree.
Strict typing doesn't fit into PHP. It was already told thousand times.
Check the second requirement in RFC template
https://wiki.php.net/rfc/template
Also, the only really useful case for "strict typing" is the ability to
catch mistakes in user apps.
However, this ability is r
Hi Dmitry,
On 5 February 2015 at 14:31, Dmitry Stogov wrote:
> Hi reeze,
>
> The original "return type" patch was designed to support internal
> functions as well.
> So I think, this is just a good addition.
>
Yes :)
>
> Only one note:
> I'm not sure, if we need the addition check in ZEND_DO_FC
Hi reeze,
The original "return type" patch was designed to support internal functions
as well.
So I think, this is just a good addition.
Only one note:
I'm not sure, if we need the addition check in ZEND_DO_FCALL handler.
On one hand it verifies that internal function returns proper result (but
t
hi,
On Thu, Feb 5, 2015 at 8:53 AM, Yasuo Ohgaki wrote:
> Hi all,
>
> I would like to discuss my "must have it in PHP 7" item.
>
> PHP RFC: script() and script_once()
> https://wiki.php.net/rfc/script_and_script_once
>
> I have proposed similar RFC before.
> Optional PHP tags by php.ini and CLI o
On 5 February 2015 at 13:06, Yasuo Ohgaki wrote:
>> Since script()/script_once() is almost copy of require()/require_once(),
> it could be
>> INI option.
>>
>> require_embed = On/Off
>
> Almost all users use 'require' only for script today, I guess.
> I should have included this option in RFC. I'l
Hi Reeze,
On Thu, Feb 5, 2015 at 1:38 PM, reeze wrote:
> The name seems ambiguous , how about "require_script/once" to match
> "do_sth" pattern?
I thought so at first, too.
How about alternative way that turn 'require' into non embedded mode by INI
switch?
> Since script()/script_once() is al
The name seems ambiguous , how about "require_script/once" to match
"do_sth" pattern?
On 5 February 2015 at 10:03, Yasuo Ohgaki wrote:
> Hi all,
>
> On Thu, Feb 5, 2015 at 10:53 AM, Yasuo Ohgaki wrote:
>
> > I would like to discuss my "must have it in PHP 7" item.
> >
> > PHP RFC: script() and
PS:
There is no enough unit tests to cover all of the branches, if we want then
I have to add a bunch of for testing functions and classes in ZEND_DEBUG,
what is the better way?
On 5 February 2015 at 11:54, reeze wrote:
> Hi all,
>
> RFC: https://wiki.php.net/rfc/internal_function_return_types
Hi all,
RFC: https://wiki.php.net/rfc/internal_function_return_types
I noticed that return types RFC[1] didn't support internal functions, I
just open a PR[2] to support it.
There are some open issues we can discuss:
1. User land return types didn't stop the php, the current implementation
ra
On Feb 5, 2015 7:58 AM, "Stanislav Malyshev" wrote:
>
> Hi!
>
> > Adding another concept, not changing the existing ones. And really,
> > it's just simplifying what is already present via is_()
> > runtime checks, making our lives a little bit easier.
>
> There's a very big difference between allo
Hi all,
On Thu, Feb 5, 2015 at 10:53 AM, Yasuo Ohgaki wrote:
> I would like to discuss my "must have it in PHP 7" item.
>
> PHP RFC: script() and script_once()
> https://wiki.php.net/rfc/script_and_script_once
>
Since script()/script_once() is almost copy of require()/require_once(), it
could b
Hi all,
I would like to discuss my "must have it in PHP 7" item.
PHP RFC: script() and script_once()
https://wiki.php.net/rfc/script_and_script_once
I have proposed similar RFC before.
Optional PHP tags by php.ini and CLI options
https://wiki.php.net/rfc/nophptags
Compare to older proposal, it
Hi Pascal,
> On 5 Feb 2015, at 00:02, Pascal Chevrel wrote:
>
> I am probably going to ask a stupid question, but do we really need the =1
> part in declare?
>
> declare(strict_types=1) couldn't be declare(strict_types)?
>
> Or does it mean that there would be cases when strict typing would b
Hi,
On Thu, Feb 5, 2015 at 2:58 AM, Stanislav Malyshev wrote:
> Hi!
>
>> Adding another concept, not changing the existing ones. And really,
>> it's just simplifying what is already present via is_()
>> runtime checks, making our lives a little bit easier.
>
> There's a very big difference betwee
Hi Hannes,
> On 4 Feb 2015, at 23:58, Hannes Magnusson wrote:
>
> So what it supports "more inputs"?
> It does constitute an LSP violation. "more inputs" is not what the
> guarantee is at all, if that is what you want you'd typehint on a
> interface.
>
>
> It is a LSP failure to allow a string
Hi!
> Adding another concept, not changing the existing ones. And really,
> it's just simplifying what is already present via is_()
> runtime checks, making our lives a little bit easier.
There's a very big difference between allowing to check types (and then
do whatever you wish) and having func
Hi all,
On Thu, Feb 5, 2015 at 2:10 AM, Crypto Compress <
cryptocompr...@googlemail.com> wrote:
> Why not the reserved Php\Http\?
+1
We must have the rule in CONDING_STANDARDS.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi,
On Thu, Feb 5, 2015 at 2:06 AM, Stanislav Malyshev wrote:
> Hi!
>
>> We are talking about adding support for scalars (string, integer, ...)
>> to the list of optional type declarations already supported (array,
>> callable, interface name, class name) by PHP. When a developer chooses
>> t
Hi!
> We are talking about adding support for scalars (string, integer, ...)
> to the list of optional type declarations already supported (array,
> callable, interface name, class name) by PHP. When a developer chooses
> to use a scalar type in the signature of a function or method then it
>
Le 14/01/2015 01:16, Andrea Faulds a écrit :
Good evening,
I’ve made some quite significant changes to my Scalar T ype Hints RFC, and
bumped its version to 0.2.
Here: https://wiki.php.net/rfc/scalar_type_hints
This is a new thread because I’ve made a significant revision to the RFC, so
it’d
On Wed, Feb 4, 2015 at 10:49 AM, Nikita Popov wrote:
> Hi internals!
>
> Currently we do not allow [1] removing a typehint during inheritance. For
> example the following code is not valid:
>
> interface A {
> public function method(Typehint $param);
> }
> class B implements A
Hi!
> Points explicitely marked for discussion in the RFC itself:
>
> * pecl/propro
> Proxies for properties representing state in internal C structs
> https://wiki.php.net/rfc/pecl_http#peclpropro
>
> * pecl/raphf
> (Persistent) handle management within objects instead of resources
> ht
On 2 February 2015 17:09:30 GMT, Alain Williams wrote:
>On Mon, Feb 02, 2015 at 05:00:08PM +, Andrea Faulds wrote:
>> Hi Andrey,
>> ...
>
>Just to give thanks to Andrea on persisting with a highly contentious
>RFC, one
>that has defeated several others over the years. I hope that we will
>end
On 4 February 2015 21:25:49 GMT, Nikita Popov wrote:
>On Wed, Feb 4, 2015 at 10:17 PM, Rowan Collins
>
>wrote:
>
>> On 4 February 2015 21:02:30 GMT, Yasuo Ohgaki
>wrote:
>> >Hi Nikita,
>> >
>> >On Thu, Feb 5, 2015 at 3:49 AM, Nikita Popov
>> >wrote:
>> >
>> >> Currently we do not allow [1] remov
On Wed, Feb 4, 2015 at 10:17 PM, Rowan Collins
wrote:
> On 4 February 2015 21:02:30 GMT, Yasuo Ohgaki wrote:
> >Hi Nikita,
> >
> >On Thu, Feb 5, 2015 at 3:49 AM, Nikita Popov
> >wrote:
> >
> >> Currently we do not allow [1] removing a typehint during inheritance.
> >For
> >> example the followi
On 4 February 2015 21:02:30 GMT, Yasuo Ohgaki wrote:
>Hi Nikita,
>
>On Thu, Feb 5, 2015 at 3:49 AM, Nikita Popov
>wrote:
>
>> Currently we do not allow [1] removing a typehint during inheritance.
>For
>> example the following code is not valid:
>>
>> interface A {
>> public function m
Hi Nikita,
On Thu, Feb 5, 2015 at 3:49 AM, Nikita Popov wrote:
> Currently we do not allow [1] removing a typehint during inheritance. For
> example the following code is not valid:
>
> interface A {
> public function method(Typehint $param);
> }
> class B implements A {
>
On Wed, Feb 4, 2015 at 9:04 PM, Rowan Collins
wrote:
> Nikita Popov wrote on 04/02/2015 18:49:
>
>> Hi internals!
>>
>> Currently we do not allow [1] removing a typehint during inheritance. For
>> example the following code is not valid:
>>
>> interface A {
>> public function method
Nikita Popov wrote on 04/02/2015 18:49:
Hi internals!
Currently we do not allow [1] removing a typehint during inheritance. For
example the following code is not valid:
interface A {
public function method(Typehint $param);
}
class B implements A {
public functi
> -Ursprüngliche Nachricht-
> Von: Robert Stoll [mailto:p...@tutteli.ch]
> Gesendet: Mittwoch, 4. Februar 2015 20:24
> An: 'Nikita Popov'; 'PHP internals'
> Betreff: AW: [PHP-DEV] Allow dropping typehints during inheritance
>
>
> > -Ursprüngliche Nachricht-
> > Von: Nikita Popov
> -Ursprüngliche Nachricht-
> Von: Nikita Popov [mailto:nikita@gmail.com]
> Gesendet: Mittwoch, 4. Februar 2015 19:50
> An: PHP internals
> Betreff: [PHP-DEV] Allow dropping typehints during inheritance
>
> Hi internals!
>
> Currently we do not allow [1] removing a typehint during in
Hi Nikita,
> On 4 Feb 2015, at 18:49, Nikita Popov wrote:
>
> Currently we do not allow [1] removing a typehint during inheritance. For
> example the following code is not valid:
>
>interface A {
>public function method(Typehint $param);
>}
>class B implements A {
>p
Hi internals!
Currently we do not allow [1] removing a typehint during inheritance. For
example the following code is not valid:
interface A {
public function method(Typehint $param);
}
class B implements A {
public function method($param);
}
// Fatal error: De
Hi,
> On 4 Feb 2015, at 18:41, Andrey Andreev wrote:
>
> I didn't want to turn this thread into a re-iteration of the RFC
> discussion one. I'm just completely surprised how relentlessly all
> suggestions about two syntaxes have been waved off by a callee vs
> caller argument like it's a golden
Hi Andrea,
On Wed, Feb 4, 2015 at 8:21 PM, Andrea Faulds wrote:
> Hi again,
>
>> On 4 Feb 2015, at 11:15, Andrey Andreev wrote:
>>
>> On Wed, Feb 4, 2015 at 1:02 PM, Florian Margaine
>> wrote:
>>> Hi Leigh,
>>>
>>> Le 4 févr. 2015 11:50, "Leigh" a écrit :
What was wrong with:
>
Hi again,
> On 4 Feb 2015, at 11:15, Andrey Andreev wrote:
>
> On Wed, Feb 4, 2015 at 1:02 PM, Florian Margaine wrote:
>> Hi Leigh,
>>
>> Le 4 févr. 2015 11:50, "Leigh" a écrit :
>>>
>>> What was wrong with:
>>>
>>> function x(int $y, string $z) { // strict
>>> function x((int) $y, (string)
Hi Robert,
> On 4 Feb 2015, at 09:38, Robert Stoll wrote:
>
> Personally I am not in favour of the declare approach because the user will
> need to switch between strict context and non-strict context which will be
> quite challenging, anti-efficient (in terms of productivity) and most
> prob
On Wed, Feb 4, 2015 at 6:17 PM, Andrea Faulds wrote:
> Hey,
>
>> On 4 Feb 2015, at 17:10, Crypto Compress
>> wrote:
>>
>>> I would go with Http\
>>
>> Why not the reserved Php\Http\?
>
> This sounds good to me. php\ is already reserved, and it’s similar to the
> common community convention of v
Hi,
On Wed, Feb 4, 2015 at 7:26 PM, Andrea Faulds wrote:
> Hey,
>
>> On 4 Feb 2015, at 17:23, Andrey Andreev wrote:
>>
>> I'm not sure about namespacing it in the first place, but otherwise I
>> agree with you - acronyms should be capitalised.
>
> What’s your objection? We either namespace it, o
Hey,
> On 4 Feb 2015, at 17:23, Andrey Andreev wrote:
>
> I'm not sure about namespacing it in the first place, but otherwise I
> agree with you - acronyms should be capitalised.
What’s your objection? We either namespace it, or we have to add some weird
prefix to avoid conflicts. I’d rather w
Hi Dmitry and Sebastian,
> On 4 Feb 2015, at 05:49, Sebastian Bergmann wrote:
>
> Am 04.02.2015 um 06:44 schrieb Dmitry Stogov:
>> What do you think about using only lowercase type names for scalar type
>> hints? In this case we won't have to introduce any limitations.
>
> This would be inconsi
Hi,
On Wed, Feb 4, 2015 at 7:17 PM, Andrea Faulds wrote:
> Hey,
>
>> On 4 Feb 2015, at 17:10, Crypto Compress
>> wrote:
>>
>>> I would go with Http\
>>
>> Why not the reserved Php\Http\?
>
> This sounds good to me. php\ is already reserved, and it’s similar to the
> common community convention
Hey,
> On 4 Feb 2015, at 17:10, Crypto Compress
> wrote:
>
>> I would go with Http\
>
> Why not the reserved Php\Http\?
This sounds good to me. php\ is already reserved, and it’s similar to the
common community convention of vendor\packagename. (e.g. ajf\escapes.) Would
work well with Compo
I would go with Http\
Why not the reserved Php\Http\?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 04/02/15 04:19, François Laupretre wrote:
>> De : Cesar Rodas [mailto:ce...@rodas.me]
>> I have a doubt, is it efficient include/require files from a source
>> different than the "real file system" a stream wrapper class? My
>> question is, would the op-code cache work as it would when reading
On 4 February 2015 at 11:02, Florian Margaine wrote:
> Because it is then the callee who decides, not the caller, whether or not he
> wants strict typing.
>
And that is the way it should be.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.
We all external data convert to native PHP types.
The database we use option MYSQLI_OPT_INT_AND_FLOAT_NATIVE.
HTTP inputs are validated and converted to native PHP types.
In Redis data are stored as serialize string.
Strong typing I like.
--
PHP Internals - PHP Runtime Development Mailing List
T
On 02/04/2015 04:32 PM, Dan Ackroyd wrote:
> btw For your exact example `sin((float)$x).` this is actually a case
> where another scalar type of 'number' which is satisfiable by either a
> float or an int would be useful, but that's definitely a step too far
> before we have any scalar type hints.
On 4 February 2015 at 10:13, Dmitry Stogov wrote:
> This won't fit into "loosely-typed" PHP, and will lead to writing -
> sin((float)$x).
Hi Dmitry,
I think what people miss is that the place where the conversion from
an unknown type to an int takes place, is also the place where you
would put t
Lester Caine wrote on 04/02/2015 00:49:
On 03/02/15 22:35, Andrea Faulds wrote:
>>Currently we have a problem with the size of integers, but simply
>> >ignoring that there are limits is not the may to fix that problem.
>This RFC doesn’t ignore that there are limits. Arbitrary-precision integer
On Feb 4, 2015 8:17 PM, "Michael Wallner" wrote:
>
> On 04/02/15 14:06, Pavel Kouřil wrote:
>
> > Hello,
> >
> > as I mentioned already in the other thread - there are currently no
> > coding standards related to namespace naming in
> > https://github.com/php/php-src/blob/master/CODING_STANDARDS a
On 04/02/15 14:06, Pavel Kouřil wrote:
> Hello,
>
> as I mentioned already in the other thread - there are currently no
> coding standards related to namespace naming in
> https://github.com/php/php-src/blob/master/CODING_STANDARDS and the
> coding standards should probably be updated before voti
On Wed, Feb 4, 2015 at 2:00 PM, Michael Wallner wrote:
> Hi!
>
> Do we want to discuss anything further before I put this to vote again?
>
> https://wiki.php.net/rfc/pecl_http
>
> Points explicitely marked for discussion in the RFC itself:
>
> * pecl/propro
> Proxies for properties representing
Hi!
Do we want to discuss anything further before I put this to vote again?
https://wiki.php.net/rfc/pecl_http
Points explicitely marked for discussion in the RFC itself:
* pecl/propro
Proxies for properties representing state in internal C structs
https://wiki.php.net/rfc/pecl_http#peclpro
I'm not sure if this is often necessary, but sometimes it may be nice to
have.
Actually, this is "logical right shift" operation (>> is "arithmetic right
shift").
LSHR is a well recognizable name, used in assemblers.
Use T_LSHR instead of T_SHRZF.
Thanks. Dmitry.
On Tue, Feb 3, 2015 at 4:20 PM,
On Feb 4, 2015 6:15 PM, "Andrey Andreev" wrote:
>
> Hi,
>
> On Wed, Feb 4, 2015 at 1:02 PM, Florian Margaine
wrote:
> > Hi Leigh,
> >
> > Le 4 févr. 2015 11:50, "Leigh" a écrit :
> >>
> >> What was wrong with:
> >>
> >> function x(int $y, string $z) { // strict
> >> function x((int) $y, (string)
On 04/02/2015 11:58, Leigh wrote:
On 4 February 2015 at 09:03, Stanislav Malyshev wrote:
I'd rather not mangle supplied data in such sensitive area. If it's
wrong, then it's wrong.
Agreed with this approach.
Sure, I pointed it out as it's the alternative the RFC itself suggests
it for any
Hi,
On Wed, Feb 4, 2015 at 1:02 PM, Florian Margaine wrote:
> Hi Leigh,
>
> Le 4 févr. 2015 11:50, "Leigh" a écrit :
>>
>> What was wrong with:
>>
>> function x(int $y, string $z) { // strict
>> function x((int) $y, (string) $z) { // casting
>>
>> This was the best suggestion I've seen that cove
Hi Leigh,
Le 4 févr. 2015 11:50, "Leigh" a écrit :
>
> What was wrong with:
>
> function x(int $y, string $z) { // strict
> function x((int) $y, (string) $z) { // casting
>
> This was the best suggestion I've seen that covers the requirements of
> both camps, and is still very clear how data is g
On 4 February 2015 at 09:03, Stanislav Malyshev wrote:
>
> I'd rather not mangle supplied data in such sensitive area. If it's
> wrong, then it's wrong.
Agreed with this approach.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
What was wrong with:
function x(int $y, string $z) { // strict
function x((int) $y, (string) $z) { // casting
This was the best suggestion I've seen that covers the requirements of
both camps, and is still very clear how data is going to be handled.
Authors who want their APIs to adhered to stri
Hi Dmitry,
On Wed, Feb 4, 2015 at 7:19 PM, Dmitry Stogov wrote:
> If you write draft RFC, and I like it, I'll take care about implementation.
> Most probably implementation may cause some changes in design.
>
> For now, I may just guess, how it should look like from user perspective.
>
Francois
Hi Jan,
On Wed, February 4, 2015 11:13, Jan Schneider wrote:
>
> Zitat von Anatol Belski :
>
>
>> Hi Stas,
>>
>>
>> On Wed, February 4, 2015 07:51, Stanislav Malyshev wrote:
>>
>>> Hi!
>>>
>>>
>>>
And at list this one living native PHP implementation
https://github.com/horde/horde/tree/
Hi Tony,
On Wed, February 4, 2015 10:56, Tony Marston wrote:
> "Pierre Joye" wrote in message
> news:CAEZPtU6au_Fi2bW=e2kiqlerq4h97vhu8nkl-z9katlstef...@mail.gmail.com...
>
>>
>> On Wed, Feb 4, 2015 at 2:09 PM, Stanislav Malyshev
>>
>> wrote:
>>
>>> Hi!
>>>
>>>
Libmcrypt is a dead cow but n
If you write draft RFC, and I like it, I'll take care about implementation.
Most probably implementation may cause some changes in design.
For now, I may just guess, how it should look like from user perspective.
Thanks. Dmitry.
On Wed, Feb 4, 2015 at 12:34 PM, Yasuo Ohgaki wrote:
> Hi Dmitry,
Zitat von Anatol Belski :
Hi Stas,
On Wed, February 4, 2015 07:51, Stanislav Malyshev wrote:
Hi!
And at list this one living native PHP implementation
https://github.com/horde/horde/tree/master/framework/Imap_Client/ (and
more library links in the older thread link above).
This is part o
This won't fit into "loosely-typed" PHP, and will lead to writing -
sin((float)$x).
We have this in PHP sources :) (in C)
Thanks. Dmitry.
On Wed, Feb 4, 2015 at 12:31 PM, Sebastian Bergmann
wrote:
> Am 04.02.2015 um 10:25 schrieb Dmitry Stogov:
> > Do you like the proposal with declare() swi
"Pierre Joye" wrote in message
news:CAEZPtU6au_Fi2bW=e2kiqlerq4h97vhu8nkl-z9katlstef...@mail.gmail.com...
On Wed, Feb 4, 2015 at 2:09 PM, Stanislav Malyshev
wrote:
Hi!
Libmcrypt is a dead cow but not much of a threat for now. On the other
hand cclient is dangerous, it should have been remo
On Wed, Feb 4, 2015 at 8:24 AM, Stanislav Malyshev
wrote:
> Hi!
>
> Our header() function supports multiline HTTP headers, which are allowed
> by RFC 2616. However, newer RFC -
> https://tools.ietf.org/html/rfc7230#section-3.2.4 - deprecates them and
> says:
>
> Historically, HTTP header field va
On Mon, 2 Feb 2015, François Laupretre wrote:
> Opening the vote for :
>
> https://wiki.php.net/rfc/cyclic-replace
There doesn't seem to be a voting option?
In any case, there are no code examples in that RFC. I think they really
ought to be part of it.
cheers,
Derick
--
PHP Internals - PHP
> -Ursprüngliche Nachricht-
> Von: Dmitry Stogov [mailto:dmi...@zend.com]
> Gesendet: Mittwoch, 4. Februar 2015 10:26
> An: Sebastian Bergmann
> Cc: PHP Internals
> Betreff: Re: [PHP-DEV] What do we need strict scalar type hints for?
>
> hi Sebastian,
>
> Do you like the proposal with dec
Hi Dmitry,
On Wed, Feb 4, 2015 at 6:22 PM, Dmitry Stogov wrote:
> I mean a lot of work designing this concept properly, writing RFC,
> discussing, coming to consensus, etc
> The implementation itself may be quite simple.
> If anyone can take care about design, I may help with implementation.
G
Am 04.02.2015 um 10:25 schrieb Dmitry Stogov:
> Do you like the proposal with declare() switch?
No, I do not like that.
We are talking about adding support for scalars (string, integer, ...)
to the list of optional type declarations already supported (array,
callable, interface name, class na
hi Sebastian,
Do you like the proposal with declare() switch?
Don't you afraid of sin(1) break? (it's just an example, telling how many
things may be broken).
Thanks. Dmitry.
On Wed, Feb 4, 2015 at 10:30 AM, Sebastian Bergmann
wrote:
> Am 04.02.2015 um 08:25 schrieb Dmitry Stogov:
> > The idea
I mean a lot of work designing this concept properly, writing RFC,
discussing, coming to consensus, etc
The implementation itself may be quite simple.
If anyone can take care about design, I may help with implementation.
Thanks. Dmitry.
On Wed, Feb 4, 2015 at 12:02 PM, Yasuo Ohgaki wrote:
> Hi
Hi Stas,
On Wed, February 4, 2015 07:51, Stanislav Malyshev wrote:
> Hi!
>
>
>> And at list this one living native PHP implementation
>> https://github.com/horde/horde/tree/master/framework/Imap_Client/ (and
>> more library links in the older thread link above).
>
> This is part of Horde with 9 li
On Wed, Feb 4, 2015 at 4:01 PM, Stanislav Malyshev wrote:
> Hi!
>
>> However, I totally fail to understand your reasoning. We know both
>> libraries are dead. ext/Imap is almost not used anymore by any major
>
>
> What you mean by "major tool relying on imap"? I've used ext/imap
> multiple times i
De : Dmitry Stogov [mailto:dmi...@zend.com]
> The idea of that RFC was an ability to have zero-cost assert().
>
>DbC is a much more bigger feature, it is interesting, but requires significant
>work.
I agree. My suggestion was just to consider assertions as part of this future
work (by using 'db
On 04/02/15 09:52, Stanislav Malyshev wrote:
> Hi!
>
>> Don't we prevent that already?
>> http://lxr.php.net/xref/PHP_5_6/main/SAPI.c#749
>
> I'm not sure what you meant by "that", but the code you linked to allows
> multi-line headers according to RFC 2616 - this is what comment in line
> 750 me
Hi!
> How about replacing \r and \n with spaces and throwing E_DEPRECATED
> instead?
I'd rather not mangle supplied data in such sensitive area. If it's
wrong, then it's wrong.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Hi Dmitry,
On Wed, Feb 4, 2015 at 4:25 PM, Dmitry Stogov wrote:
> The idea of that RFC was an ability to have zero-cost assert().
>
> DbC is a much more bigger feature, it is interesting, but requires
> significant work.
Type check and DbC integration would require significant work, I guess.
I
On 04/02/2015 09:52, Stanislav Malyshev wrote:
Hi!
Don't we prevent that already?
http://lxr.php.net/xref/PHP_5_6/main/SAPI.c#749
I'm not sure what you meant by "that", but the code you linked to allows
multi-line headers according to RFC 2616 - this is what comment in line
750 means. I propo
Hi!
> However, I totally fail to understand your reasoning. We know both
> libraries are dead. ext/Imap is almost not used anymore by any major
What you mean by "major tool relying on imap"? I've used ext/imap
multiple times in the past, and I know others do too. Of course, there
are different l
Hi!
> Don't we prevent that already?
> http://lxr.php.net/xref/PHP_5_6/main/SAPI.c#749
I'm not sure what you meant by "that", but the code you linked to allows
multi-line headers according to RFC 2616 - this is what comment in line
750 means. I propose to remove this (of course, no newline chars
Hi Stas,
On Wed, Feb 4, 2015 at 4:24 PM, Stanislav Malyshev
wrote:
> So, my question is - any objections for dropping this functionality? I'd
> be inclined to drop it in all versions from 5.4 up since it may still be
> confusing some not too smart clients that don't implement full spec, and
> fr
Hi all,
On Wed, Feb 4, 2015 at 5:22 PM, Michael Wallner wrote:
> Don't we prevent that already?
> http://lxr.php.net/xref/PHP_5_6/main/SAPI.c#749
>
I don't expect there is such web server, but \r\r is allowed by this code.
I remember that there was mail server treats \r\r as double end of lines
On 04/02/15 08:24, Stanislav Malyshev wrote:
> Hi!
>
> Our header() function supports multiline HTTP headers, which are allowed
> by RFC 2616. However, newer RFC -
> https://tools.ietf.org/html/rfc7230#section-3.2.4 - deprecates them and
> says:
>
> Historically, HTTP header field values could be
89 matches
Mail list logo
