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. 201
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,
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,
On Thu, Feb 5, 2015 at 9:22 AM, Stanislav Malyshev wrote:
> 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 happene
Hi Andrea,
On Fri, Feb 6, 2015 at 1:51 AM, Andrea Faulds wrote:
> Hi Dan,
>
>> On 5 Feb 2015, at 23:41, Dan Ackroyd wrote:
>>
>> ...
>>
>> Additionally Andrea, I am disappointed that you opened voting without
>> a option with the 'declare' stuff removed. This is despite myself
>> having asked yo
Hi,
On Mon, Feb 9, 2015 at 2:10 AM, Pierre Joye wrote:
> There is a vote, you do not like the RFC or part of
> it, vote no. But this constant attempt to get exactly what you want
> and do almost everything possible to get it is getting very counter
> productive.
I want to note that this should c
Hi,
On Mon, Feb 9, 2015 at 7:22 PM, Jordi Boggiano wrote:
>
> And that is exactly why this RFC is great, since it lets the
> strict-proponents have their strict types in their files, but those
> preferring weak ones can remain in the default weak mode, never see an ugly
> declare(), and still cal
Hi,
On Wed, Feb 11, 2015 at 12:40 PM, Jordi Boggiano wrote:
> On 09/02/2015 22:29, Anatol Belski wrote:
>>
>> ext/imap
>> ext/mcrypt
>> ext/pdo_dblib
>
>
> Sorry if this was suggested already but if those are not maintained much and
> should not be used further ideally, shouldn't we add E_DEPRECA
Hi,
On Fri, Feb 13, 2015 at 2:33 AM, Netroby wrote:
> For Human type experience, {} is harder than () to type, see your
> keyboard, can you easier type {} or easier type ()
>
> I hate {}
>
> If you like to use {} as the group symbols, i would not like it.
>
> It hurts my fingers.
>
If you look
Hi,
On Mon, Feb 16, 2015 at 8:56 PM, Dmitry Stogov wrote:
>
> I would propose exactly Andrea's 0.1.
> Most people were agree to support weak type hints by default.
> This proposal won't prevent feature addition of optional strict type hints.
Sorry, but I'll have to repeat what has been said over
On Tue, Feb 17, 2015 at 1:30 PM, Leigh wrote:
> On 17 February 2015 at 05:48, Sara Golemon wrote:
We can sigh and tut about this not being "the PHP way", but the script
author was the one who chose to enter into a tight contract, and the
script author, not you, is the one who shoul
Hi,
On Tue, Feb 17, 2015 at 3:33 PM, Zeev Suraski wrote:
>> -Original Message-
>> From: François Laupretre [mailto:franc...@php.net]
>> Sent: Tuesday, February 17, 2015 2:58 PM
>> To: 'Sara Golemon'; 'Zeev Suraski'
>> Cc: 'PHP internals'
>> Subject: RE: [PHP-DEV] Reviving scalar type hint
Hi,
On Tue, Feb 17, 2015 at 5:02 PM, Dennis Birkholz wrote:
> Am 17.02.2015 um 12:30 schrieb Leigh:
>> And you find taking authority over a library away from the library
>> author completely acceptable?
>>
>> If I write an API that works perfectly well in strict mode, why
>> shouldn't I be able t
Hi,
On Tue, Feb 17, 2015 at 6:11 PM, Zeev Suraski wrote:
>> -Original Message-
>> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
>> Sent: Tuesday, February 17, 2015 5:48 PM
>> To: Zeev Suraski
>> Cc: franc...@php.net; Sara Golemon; PHP internals
>> Subject: Re: [PHP-DEV] Reviving scal
Hi,
On Tue, Feb 17, 2015 at 6:50 PM, Zeev Suraski wrote:
>
>> On 17 בפבר׳ 2015, at 18:32, Andrey Andreev wrote:
>>
>> Hi,
>>
>>> On Tue, Feb 17, 2015 at 6:11 PM, Zeev Suraski wrote:
>>>
>>> If it gave both sides exactly what th
Hi,
On Wed, Feb 18, 2015 at 9:00 AM, Zeev Suraski wrote:
>> -Original Message-
>> From: Nikita Popov [mailto:nikita@gmail.com]
>> Sent: Wednesday, February 18, 2015 3:06 AM
>> To: Rasmus Lerdorf
>> Cc: Sara Golemon; PHP internals
>> Subject: Re: [PHP-DEV] Scalar Type Hints v0.4
>>
>>
Hi,
On Wed, Feb 18, 2015 at 11:54 AM, Lester Caine wrote:
> On 18/02/15 09:14, Andrey Andreev wrote:
>> That is especially bad when such identifiers are in fact generated as
>> integers first so that they are incremental, but the
>> program/database/business logic requ
Hi,
On Wed, Feb 18, 2015 at 2:27 PM, François Laupretre wrote:
> Hi Andrey,
>
>> De : Andrey Andreev [mailto:n...@devilix.net]
>>
>> I too am curious about the potential issue with "123" to 123
>> specifically, although it could be seen as a subset o
Hi Zeev,
On Wed, Feb 18, 2015 at 2:31 PM, Zeev Suraski wrote:
>> Consider the following signature:
>>
>> function foo(int $bar) {}
>>
>> In the case of a *string* representation of a hexadecimal number, the
>> following would error only on the last iteration with a weak hint, and on
>> the
>>
Hi François,
On Wed, Feb 18, 2015 at 3:02 PM, François Laupretre wrote:
>> De : Andrey Andreev [mailto:n...@devilix.net]
>>
>> Consider the following signature:
>>
>> function foo(int $bar) {}
>>
>> In the case of a *string* representation of a
Hi,
On Wed, Feb 18, 2015 at 11:23 PM, Leigh wrote:
> I would like a way of enabling strict by
> default, immutable to scripts so that users cannot be forced into this
> mode, and lets the radicals and the weaklings* play together in
> harmony.
>
> For the rest of the RFC, I either agree with or h
Hi,
On Fri, Feb 20, 2015 at 6:01 AM, François Laupretre wrote:
> Hi Levi,
>
> Just my opinion :
>
> Add 'resource', 'object', 'scalar', 'mixed', 'numeric'
>
> Remove 'double' (avoid this alias if we decide to encourage 'float'
> everywhere)
>
> Not sure we'll use Boolean and integer but reserve
Hi,
On Fri, Feb 20, 2015 at 6:00 PM, Levi Morrison wrote:
> On Fri, Feb 20, 2015 at 4:21 AM, Andrey Andreev wrote:
>>
>> Agree on 'double' though ... if we want to discourage its usage, we
>> might even think of deprecating it.
>
> While deprecating it mi
Hi,
On Fri, Feb 20, 2015 at 8:05 PM, François Laupretre wrote:
> Hi Andrey,
>
> I think the question of reserving 'resource' or not is not the main one.
>
> The question of having to reserve keywords is much more fundamental and needs
> to be addressed first. I expect it to be clear for everyone
Hi,
I intended on replying to this thread at a later stage (and probably
will), but I just can't ignore this one:
On Sun, Feb 22, 2015 at 12:02 AM, Zeev Suraski wrote:
>
> Secondly, there you are: http://www.checkmarx.com/ - they've been
> developing pretty amazing static analyzers for PHP for
Hi,
On Tue, Feb 24, 2015 at 8:36 AM, Sammy Kaye Powers wrote:
> The RFC to add a user-land API for an easy-to-use and reliable CSPRNG in
> PHP is up for discussion: https://wiki.php.net/rfc/easy_userland_csprng
>
> This proposes adding two methods: `random_bytes()` and `random_int()` that
> retur
Hi,
On Thu, Feb 26, 2015 at 9:45 AM, Jacob Bednarz wrote:
>> I think it would be good to incitate all the frameworks and projects using
>> Travis CI to add nightly to their testing matrix so as to catch bugs in
>> the
>> upcoming PHP 7 version by testing real code and also so as to have as much
>
Hi,
On Tue, Mar 3, 2015 at 9:25 AM, Yasuo Ohgaki wrote:
> Hi all,
>
> On Sun, Mar 1, 2015 at 1:53 PM, Yasuo Ohgaki wrote:
>
>>
>>
>> https://bugs.php.net/bug.php?id=69127
>>
>> This bug is known fatal bug for session module. I proposed "lazy_destroy"
>> to fix
>> this before, but it declined.
>>
Hi,
On Wed, Jun 24, 2015 at 5:49 AM, Yasuo Ohgaki wrote:
> Hi Xinchen,
>
> On Wed, Jun 24, 2015 at 11:42 AM, Xinchen Hui wrote:
>
>> and for the "age" usage you replied in github, I think the author of
>> such codes should be aware, if it's only number, then instead of
>> htmlespcicalchars($age
Hi,
On Fri, Aug 21, 2015 at 4:36 PM, Anthony Ferrara wrote:
>
> MHO is this is too important of a distinction to simply gloss over.
> Having it return false (or null) will be a problem, as nobody will
> perform the error checks. And returning $x where `$x == 0` in a
> security context could be in
HI,
Not any that I'm aware of, and I personally have never used is_null().
I share your opinion that we don't really need is_null(), but with BC
in mind, I don't think it would get removed.
Cheers,
Andrey.
On Fri, Jul 4, 2014 at 1:47 AM, Kris Craig wrote:
>> $var !== null
>> ! is_null($
Hi,
On Mon, Jul 14, 2014 at 4:12 PM, Alexey Zakhlestin wrote:
> Some people talk about inconsistency, which is introduced by reusing same
> syntax for "strict parameter types" and "scalar parameter casts”. There’s
> some truth there.
> Let’s use different syntax.
>
> This might work:
>
> fu
On Mon, Jul 14, 2014 at 4:27 PM, Rowan Collins wrote:
> Andrey Andreev wrote (on 14/07/2014):
>
>> Hi,
>>
>> On Mon, Jul 14, 2014 at 4:12 PM, Alexey Zakhlestin
>> wrote:
>>>
>>> Some people talk about inconsistency, which is introduced by reusing
On Tue, Jul 15, 2014 at 8:24 PM, Rowan Collins wrote:
> The logical conclusion from that is not to have type hints at all. So far,
> that is in fact the only consensus the PHP community has ever reached - not
> to have scalar type hints.
I'm sorry, I know what you mean here and I'm not criticizi
On Tue, Jul 15, 2014 at 10:48 PM, Andrea Faulds wrote:
>
> On 15 Jul 2014, at 20:43, Andrey Andreev wrote:
>
>> I'm sorry, I know what you mean here and I'm not criticizing you
>> specifically (in fact, I'm intentionally taking it ouf of context),
>
On Tue, Jul 15, 2014 at 11:02 PM, Andrey Andreev wrote:
> On Tue, Jul 15, 2014 at 10:48 PM, Andrea Faulds wrote:
>>
>> On 15 Jul 2014, at 20:43, Andrey Andreev wrote:
>>
>>> I'm sorry, I know what you mean here and I'm not criticizing you
>>> s
On Tue, Jul 15, 2014 at 11:05 PM, Andrea Faulds wrote:
>
> On 15 Jul 2014, at 21:02, Andrey Andreev wrote:
>
>> Unless you really force the camps to pick one by saying "you can't
>> have Y if we've got X" (to which there's no technical limit
On Jul 19, 2014 11:45 AM, "Yasuo Ohgaki" wrote:
>
> Hi Nikita,
>
> On Sat, Jul 19, 2014 at 2:46 PM, Nikita Popov
wrote:
>
> > I'm against adding this notice to password_hash. This will require all
> > applications to ensure that passwords are shorter than 72 chars. I don't
> > think that's a good
Hi,
On Mon, Jul 28, 2014 at 5:58 AM, Yasuo Ohgaki wrote:
> Hi all,
>
> Since we have discussion for Next PHP, "PHP" namespace discussion would be
> nice
> to have.
>
> Currently, PHP module functions/classes/interfaces are using global(root)
> namespace.
> If it is changed to use its own namespac
Hi,
On Mon, Jul 28, 2014 at 10:33 AM, Pierre Joye wrote:
> On Sun, Jul 27, 2014 at 9:47 PM, Nikita Popov wrote:
>> On Sun, Jul 27, 2014 at 9:30 PM, Pierre Joye wrote:
>>>
>>> On Jul 27, 2014 8:17 PM, "Lonny Kapelushnik" wrote:
>>> >
>>> > On Jul 27, 2014, at 1:19 PM, Pierre Joye wrote:
>>> >>
Hi,
On Wed, Jul 30, 2014 at 5:47 AM, Yasuo Ohgaki wrote:
> Hi Andrey,
>
> On Mon, Jul 28, 2014 at 4:42 PM, Andrey Andreev wrote:
>>
>> This would be a major BC break, that couldn't possibly happen in PHP
>> 5.x and IMO is way too radical even for PHP 6/7.
&g
Hi,
I don't really have anything new to say about this, just couldn't
resist another +1.
This RFC is an example to follow - well thought and written, detailed,
implementation ready in spite of it being a real challenge,
non-controversial, and even as a userland developer, I can see the
benefits.
Hi,
I'd personally find it horrible if $foo[$i] = $bar[$i++]; is executed
right-to-left, but given that your examples are a bit weird, I'm not sure
if mine is affected. Is it?
Cheers,
Andrey.
On Aug 13, 2014 10:05 PM, "Nikita Popov" wrote:
>
> On Wed, Aug 13, 2014 at 7:18 PM, guilhermebla...@gm
On Fri, Aug 15, 2014 at 6:58 PM, Christoph Becker wrote:
> Andrey Andreev:
>
>> I'd personally find it horrible if $foo[$i] = $bar[$i++]; is executed
>> right-to-left, but given that your examples are a bit weird, I'm not sure
>> if mine is affected. Is it?
>
Hi,
On Fri, Aug 29, 2014 at 1:14 AM, Johannes Schlüter
wrote:
> On Thu, 2014-08-28 at 20:55 +0200, Julien Pauli wrote:
>> Looking at git branches, 5.0, 5.1 and 5.2 still have their respective
>> main branches (which is all right and good).
>>
>> However, they dont have their release branch refere
On Fri, Aug 29, 2014 at 3:03 AM, Johannes Schlüter
wrote:
> On Fri, 2014-08-29 at 00:12 +0100, Andrea Faulds wrote:
>> I don’t see the need, though. For cases where we added stuff after release,
>> just make an extra tag.
>
> $ git tag | wc -l
> 937
> $ git branch -r | grep origin | wc -l
> 128
>
On Tue, Sep 9, 2014 at 3:07 AM, Andrea Faulds wrote:
>
> On 8 Sep 2014, at 23:58, Adam Harvey wrote:
>
>> +1 on ?? — there's precedent for it, and it means we don't have to
>> explain why the shorthand form of an operator behaves differently to
>> the long form, which is just going to confuse use
Hi,
As a userland guy, I'm against this one.
It seems a bit political ... A lot of people want either strict type
hints or type casting hints, but because the people on this list can't
get to agree on any of the two, this RFC tries to make a compromise
that, IMO, satisfies nobody. It's done not f
Hi,
On Sun, Sep 14, 2014 at 6:09 PM, Andrea Faulds wrote:
>
> On 14 Sep 2014, at 15:56, Andrey Andreev wrote:
>
>> It seems a bit political ... A lot of people want either strict type
>> hints or type casting hints, but because the people on this list can't
>>
On Sun, Sep 14, 2014 at 6:47 PM, Andrea Faulds wrote:
>
> On 14 Sep 2014, at 16:40, Andrey Andreev wrote:
>
>> ... and I responded to this in the next paragraph. Userland doesn't
>> case about internal differences, that's why they're called internal
>&g
On Sun, Sep 14, 2014 at 7:17 PM, Andrea Faulds wrote:
>
> On 14 Sep 2014, at 17:09, Andrey Andreev wrote:
>
>> I'm aware of that, hence why I said 'php-internals' to refer to the
>> mailing list. Again, userland devs don't care about that - PHP is
>>
Hi,
On Sun, Sep 21, 2014 at 3:12 AM, Tjerk Meesters
wrote:
>
>> On 20 Sep, 2014, at 11:35 pm, Florian Margaine wrote:
>>
>> Hi list,
>>
>> I saw this interesting bug: https://bugs.php.net/bug.php?id=68063
>>
>> Basically, if `session_id('')` is run before `session_start()`, weird
>> things happe
On Mon, Sep 22, 2014 at 3:10 PM, Andrea Faulds wrote:
>
> On 22 Sep 2014, at 12:32, Derick Rethans wrote:
>
>> On Sat, 20 Sep 2014, Andrea Faulds wrote:
>>
>>> Perhaps I’m being unfair and overthinking things, but I wonder if it
>>> is really fair for people who have no karma, i.e. not contributo
On Tue, Sep 23, 2014 at 12:29 PM, Andrea Faulds wrote:
>
>> On 23 Sep 2014, at 10:15, Leigh wrote:
>>
>>> On 23 September 2014 09:51, Michael Wallner wrote:
>>>
>>> Yes, it was removed intentionally (quite a long time ago), like using
>>> resources as array keys, to avoid hard-to-trace bugs for
On Tue, Sep 23, 2014 at 4:13 PM, Ferenc Kovacs wrote:
> On Tue, Sep 23, 2014 at 10:27 AM, Florian Anderiasch
> wrote:
>
>> On 09/22/2014 08:56 PM, Zeev Suraski wrote:
>> > The first bullet is the one this thread deals with so far. It clearly
>> > states that having an SVN account isn't enough -
On Tue, Sep 23, 2014 at 7:36 PM, Park Framework
wrote:
>> Not really, not because it is not good but because there is always be a
>> better one. We can't break format in every release.
>
> If you do not update in PHP 7 serialization method, it will never be
> updated, the default serialization in
On Fri, Sep 26, 2014 at 6:20 PM, Derick Rethans wrote:
> On Fri, 26 Sep 2014, Ferenc Kovacs wrote:
>
>> On Fri, Sep 26, 2014 at 1:29 PM, Florian Margaine
>> wrote:
>>
>> > The question is in the title :-)
>> >
>> > As far as I know, most projects follow this convention: develop on
>> > the master
On Tue, Sep 30, 2014 at 12:28 AM, Sharon Levy wrote:
>
> ...
>
> I think in all fairness, users should be required to learn C and pass a test
> demonstrating basic knowledge of PHP's internals in order to acquire voting
> privileges.
So, in order to vote, users should become (capable of being) co
On Tue, Sep 30, 2014 at 10:31 PM, Sharon Levy wrote:
>
>
> From: Andrey Andreev
> Sent: Sep 29, 2014 3:01 PM
> To: Sharon Levy
> Cc: Zeev Suraski , Derick Rethans , Andrea
> Faulds , PHP internals
> Subject: Re: [PHP-DEV] Is it fair that people with no karma can vote on
On Wed, Oct 1, 2014 at 1:17 AM, Leigh wrote:
> On 30 September 2014 23:05, Kalle Sommer Nielsen wrote:
>>
>> And anyone with a wiki account can vote too, meaning everyone who
>> wrote an RFC can in theory vote on anything, take for example fabpot,
>> who does not have an VCS account but can vote
On Tue, Oct 14, 2014 at 4:09 PM, Kris Craig wrote:
> On Tue, Oct 14, 2014 at 5:54 AM, Andrea Faulds wrote:
>
>>
>> On 14 Oct 2014, at 13:47, Kris Craig wrote:
>>
>> > Hey guys,
>> >
>> > Does anybody know why we have $_GET and $_POST, but not $_PUT and
>> > $_DELETE? As far as I can tell, the o
Hi,
On Tue, Oct 14, 2014 at 6:56 PM, Rasmus Lerdorf wrote:
> On 10/14/2014 06:29 AM, Andrea Faulds wrote:
>>
>> On 14 Oct 2014, at 14:27, Kristopher wrote:
>>
>>> $_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake.
>>
>> Ew, non-superglobals.
>>
>> But $_REQUEST_BODY and $_QUERY_ST
Hi,
On Sat, Oct 18, 2014 at 10:20 AM, Stas Malyshev wrote:
> Hi!
>
>> resurrecting this thread in the hope of getting a bit more feedback.
>
> About removing functions - I don't really see any particular win in it.
> I mean, we'd have enough BC concerns in PHP 7 without having to worry
> about mi
Hi,
On Thu, Oct 23, 2014 at 1:01 AM, Zeev Suraski wrote:
> The RFC itself makes an assertion that fundamentally contradicts the notion
> that these are 'just functions'. The RFC reads 'They also prevent any
> suggestion of strict type hinting for scalar types, because if that were to
> be added,
On Thu, Oct 23, 2014 at 1:34 AM, Zeev Suraski wrote:
>> -Original Message-
>> From: Andrey Andreev [mailto:n...@devilix.net]
>> Sent: Thursday, October 23, 2014 1:15 AM
>> To: Zeev Suraski
>> Cc: Andrea Faulds; Stas Malyshev; Dmitry Stogov; PHP Internals
Hi,
On Fri, Oct 24, 2014 at 2:36 AM, Andrea Faulds wrote:
> Good evening once again,
>
> Here’s another RFC: https://wiki.php.net/rfc/readonly_properties
>
> It proposes, with a working implementation, a modifier for properties that
> makes them readable and writeable from different scopes.
>
>
Hi,
On Fri, Oct 24, 2014 at 12:34 PM, Pierre Joye wrote:
> hi Andrea,
>
> On Fri, Oct 24, 2014 at 6:36 AM, Andrea Faulds wrote:
>> Good evening once again,
>>
>> Here’s another RFC: https://wiki.php.net/rfc/readonly_properties
>>
>> It proposes, with a working implementation, a modifier for prop
Hi all,
On Wed, Nov 5, 2014 at 9:52 PM, Ferenc Kovacs wrote:
>
> Hi,
>
> thanks for the report.
> first let me clarify a couple of things:
>
> 1, neither of https://wiki.php.net/rfc/session-lock-ini or
> https://wiki.php.net/rfc/session-read_only-lazy_write made into 5.6 in their
> proposed forms
Hi,
On Wed, Nov 5, 2014 at 11:30 PM, Yasuo Ohgaki wrote:
>
> BTW, anyone know the reason why the user need to call
> session_write_close()/session_commit()
> unconditionally? Accounting, perhaps?
Releasing locks is one example. In userland implementations though, it
could be all kinds of applica
Hi,
On Wed, Nov 5, 2014 at 11:57 PM, Kévin Dunglas wrote:
>
> - Added a new FILTER_VALIDATE_DOMAIN filter validating domain names
> - Added a FILTER_FLAG_HOSTNAME flag to allow checking hostnames (_ are
> forbidden in hostname but not in domains)
This doesn't make any sense. A domain *is* a host
Hi Yasuo,
On Thu, Nov 6, 2014 at 3:42 AM, Yasuo Ohgaki wrote:
> Hi Andrey,
>
> On Thu, Nov 6, 2014 at 8:23 AM, Andrey Andreev wrote:
>>
>> Short-term fix for 5.6 is obviously to revert the commit. I was vocal
>> mostly because of principle at the time, but this
Hi,
On Thu, Nov 6, 2014 at 4:02 AM, Yasuo Ohgaki wrote:
> HI all,
>
> On Thu, Nov 6, 2014 at 6:30 AM, Yasuo Ohgaki wrote:
>
>> On Wed, Nov 5, 2014 at 10:54 AM, Damian Wadley wrote:
>>
>>> Apparently this caused
>>> problems for some people as they made 68331 a few days ago.
>>>
>>
>> Just a qui
Hi,
On Thu, Nov 6, 2014 at 8:19 AM, Kévin Dunglas wrote:
> Hi Andrey,
>
> Sorry but I think you're wrong. Domain != hostname. Underscore are allowed
> in domains (RFC 2181) but not in hostnames (RFC 1123 and next). To quote
> Wikipedia:
>
> "While a hostname may not contain other characters, such
Hi,
On Thu, Nov 6, 2014 at 3:39 PM, Kévin Dunglas wrote:
> FILTER_VALIDATE_DOMAIN checks conformance with DNS RFCs : total length,
> label length and allowed characters (_ are allowed in domain names but many
> other characters are forbidden such as ~/+...). I'll add IDN support too
> when IDN su
Hi,
On Wed, Nov 19, 2014 at 4:33 PM, Alain Williams wrote:
> On Wed, Nov 19, 2014 at 02:27:12PM +, Rowan Collins wrote:
>
>> PEAR is not a single organisation who can mass update all the
>> modules; the guidelines could be updated, if they haven't been
>> already, but there would still be a w
Hi,
On Thu, Nov 20, 2014 at 4:25 PM, Xinchen Hui wrote:
>
> leave it there doesn't hurt anybody. but remove it will. why we need to ?
>
Leaving it does hurt. Most developers with no PHP4 experience don't
know that such a feature exists and spend hours trying to figure out
why a parent class' co
Hi,
Just wanted to say: +1 on this and thank you for proposing a patch.
I myself created a feature request for it on bugs.php.net some time
ago, now closed as duplicate: https://bugs.php.net/bug.php?id=62315
Cheers,
Andrey.
On Fri, Jan 9, 2015 at 2:08 AM, François Laupretre wrote:
> Hi,
>
> I
Hi,
On Sat, Jan 10, 2015 at 1:53 PM, Nikita Popov wrote:
> But if I see this (taken from the tests) as the search & replacement values...
>
> $search=array('[?]',array('(?)','d','e'),'a','R');
> $repl=array(
> array('ap(?)z[?]',"b[?](?)v",null,37,"[?]n[?]"),
> array('a',array('b',null)),
Hello,
On Wed, Jan 14, 2015 at 12:22 PM, Andrea Faulds wrote:
>
> Hi Julien,
>
>> On 14 Jan 2015, at 10:14, Julien Pauli wrote:
>>
>> Using declare() IMO, is a PITA.
>> Everything that can be done without the use of declare(), must be done
>> without declare().
>>
>> I would have prefered diffe
Hi again,
On Wed, Jan 14, 2015 at 1:21 PM, Andrea Faulds wrote:
> Hi Andrey,
>
>> On 14 Jan 2015, at 11:10, Andrey Andreev wrote:
>>
>> I don't understand why it should be a bad thing that the API author
>> forces rules on the consumer. The opposite is IMO
Hi,
On Thu, Jan 15, 2015 at 5:31 PM, Pavel Kouřil wrote:
> On Thu, Jan 15, 2015 at 4:19 PM, Jordi Boggiano wrote:
>>
>> Right now, or with only weak hints, if a library decides to implement strict
>> typing, they'll skip the scalar hints and check types with something like
>> the assert lib [1].
Hi,
On Thu, Jan 15, 2015 at 7:13 PM, Andrea Faulds wrote:
>
>> Now from that perspective I cannot rely that I am in strict and would have
>> to handle the default weak even although I declared in my class that i
>> wanted strict mode which only affected the code inside of that file. That's
>
Hi Andrea,
On Thu, Jan 15, 2015 at 9:52 PM, Andrea Faulds wrote:
>
> Sure, weak typing is much poorer than strict typing for error checking. Does
> that mean the user should be prevented from having the choice?
>
> Are you simply opposed to the idea of weak types in general?
>
I am opposed to t
Hi,
On Fri, Jan 16, 2015 at 2:29 PM, Rowan Collins wrote:
> Mike Willbanks wrote on 15/01/2015 16:55:
>>
>> It also means that then a library developer would
>> need to handle conditions on both sides (when in weak vs. strict). So I
>> don't really understand where the gains of this would come
Hi again,
On Fri, Jan 16, 2015 at 4:52 PM, Rowan Collins wrote:
>
> Specifically, I don't think a library author should be able to tell me that,
> just because they're feeling picky, '42' and 42 are not equivalent when
> calling their function. It does very little to protect me from genuine
> mis
Hi,
On Mon, Jan 19, 2015 at 5:01 PM, Tony Marston wrote:
>>> But the only benefits with the removal of old features is a smaller code
>>> base for the core developers. The only "benefit" which is experienced in
>>> userland is that applications which have run for over a decade suddenly stop
>>> w
On Mon, Jan 19, 2015 at 6:42 PM, Tony Marston wrote:
Ah, so you admit there may be benefits? Again, I do not say that those
benefits are definitely enough to justify the change in this case, but
they
are real, and I would like you to stop dismissing them.
>>>
>>> There is
Hi,
I agree that the low-level details of different session handlers makes
the SessionHandler class a bit weird. However, I disagree that it is
useless.
We've discussed this before and I want to re-iterate my suggestion to
simply provide a separate class for each underlying save_handler, like
Fil
Hi,
On Sat, Jan 24, 2015 at 2:24 AM, Yasuo Ohgaki wrote:
> Hi Stas,
>
> On Sat, Jan 24, 2015 at 8:49 AM, Stanislav Malyshev
> wrote:
>
>> > This is the only reasonable use I know. I would to write user
>> > serializer(read/writer)
>> > handler for it.
>>
>> So we went from no reasonable use to
Hi,
On Sat, Jan 24, 2015 at 7:05 PM, Yasuo Ohgaki wrote:
> Hi Andrey,
>
> On Sat, Jan 24, 2015 at 6:34 PM, Andrey Andreev wrote:
>>
>> > Let's keep SessionHandler class. However,
>> > PHP_FUNCTION(session_set_save_handler)
>> > should be cleaned up
Hi again,
On Sat, Jan 24, 2015 at 7:48 PM, Yasuo Ohgaki wrote:
> Hi Andrey,
>
> On Sat, Jan 24, 2015 at 6:34 PM, Andrey Andreev wrote:
>>
>> > This is because session module lacks user defined serializer. Save
>> > handler
>> > handles session data stor
HI,
On Wed, Jan 28, 2015 at 12:34 PM, Rowan Collins wrote:
> Benjamin Eberlei wrote on 28/01/2015 08:43:
>>
>> I think this is too big a BC break.
>>
>> The usage of $array[key] = 0 instead of "key" is widespread.
>
>
> As I mentioned, the advice *not* to write that has been in the manual since
>
Hi,
On Wed, Jan 28, 2015 at 10:46 PM, Matteo Beccati wrote:
> On 28/01/2015 20:19, Michael Wallner wrote:
>>
>> On 28/01/15 20:07, Matteo Beccati wrote:
>>>
>>> As Nikita mentions, PSR-7 is under way and currently gaining some
>>> traction. At the moment the PSR-7 interfaces are designed to be
>>
Hi,
On Thu, Jan 29, 2015 at 9:48 AM, Matteo Beccati wrote:
> Hi Andrey,
>
> On 28/01/2015 23:50, Andrey Andreev wrote:
>>
>> You're voting "no" because the FIG can't agree yet?
>> They've been discussing this for *at least* an year and iirc the
Hi,
On Thu, Jan 29, 2015 at 12:52 PM, Matteo Beccati wrote:
> Hi Andrey,
>
> On 29/01/2015 10:41, Andrey Andreev wrote:
>>
>> It's not about whether we like the FIG's direction or what "PSR"
>> stands for (which doesn't make sense btw) - that i
Hi,
On Thu, Jan 29, 2015 at 11:32 PM, Yasuo Ohgaki wrote:
> Hi all,
>
> I came across with bug #68947 https://bugs.php.net/bug.php?id=68947
> and realized small inconsistency.
>
> http://3v4l.org/ldZKl
>
> $obj->${array[$key]}; // Syntax error
> $obj->{$array[$key]}; // Works
>
> $obj->${key}; //
Hi,
On Fri, Jan 30, 2015 at 12:49 AM, Yasuo Ohgaki wrote:
> Hi Andrea,
>
> On Fri, Jan 30, 2015 at 7:17 AM, Andrea Faulds wrote:
>>
>> I would expect that anything within ${} works the same as it does outside
>> it. Having $obj->${array[$key]} do something different to $key =
>> array[$key], $ob
Hi,
On Mon, Feb 2, 2015 at 10:41 AM, Andrea Faulds wrote:
> Hi Dmitry,
>
>> On 2 Feb 2015, at 07:02, Dmitry Stogov wrote:
>>
>> As I already told, in my opinion, version 0.1 was the perfect solution that
>> fit into PHP semantic very well.
>
> I don't like the original. Weak types work to a degr
Hi Andrea,
On Mon, Feb 2, 2015 at 11:05 AM, Andrea Faulds wrote:
>
> Hi Andrey,
>
>> On 2 Feb 2015, at 08:55, Andrey Andreev wrote:
>>
>> Hi,
>>
>>> On Mon, Feb 2, 2015 at 10:41 AM, Andrea Faulds wrote:
>>> Hi Dmitry,
>>>
>&g
Hi,
On Mon, Feb 2, 2015 at 6:17 PM, Andrea Faulds wrote:
> Hi Markus,
>
>> On 2 Feb 2015, at 14:25, Markus Fischer wrote:
>>
>> - Since consensus on the strict mode does part the community (or, the
>> greater community also outside @internals) my impression is that the
>> current best way to mov
1 - 100 of 258 matches
Mail list logo
