On Fri, Jan 2, 2015 at 2:30 PM, Kalle Sommer Nielsen wrote:
> 2015-01-02 20:41 GMT+01:00 Sara Golemon :
>> So instead you have to do:
>> #if defined(ZEND_ENGINE_2) || defined(ZEND_ENGINE_3)
>>
>
> #ifdef ZEND_ENGINE_3
> # define ZEND_ENGINE_2
> #endif
>
Yeah, obviously I can do that. I'm not actu
On Fri, Jan 2, 2015 at 9:54 PM, Stanislav Malyshev wrote:
> Hi!
>
>> I am not sure about that. Parameters handling is one specific case,
>> userland parameter handling even more. It could be a good move to do
>
> Making internal and userland parameters work differently and having
> scalar type err
Hi!
> I am not sure about that. Parameters handling is one specific case,
> userland parameter handling even more. It could be a good move to do
Making internal and userland parameters work differently and having
scalar type errors behave differently from object type errors by having
one throw ex
On Fri, Jan 2, 2015 at 9:05 PM, Stanislav Malyshev wrote:
> Hi!
>
>> I am also not a fan of errors, exception, at least for methods, make
>> much more sense. I know it is relatively easy to handle errors as
>> exception but still, let do it right now.
>
> Then we need to convert all parameter mism
Hi!
> I am also not a fan of errors, exception, at least for methods, make
> much more sense. I know it is relatively easy to handle errors as
> exception but still, let do it right now.
Then we need to convert all parameter mismatch errors (or at least all
fatal ones) to exceptions. Which I don'
hi Andrea,
On Wed, Dec 31, 2014 at 12:27 PM, Andrea Faulds wrote:
> Good evening,
>
> Parameter type hints for PHP’s scalar types are a long-requested feature for
> PHP. Today I am proposing an RFC which is a new attempt to add them to the
> language. It is my hope that we can finally get this
2015-01-02 20:41 GMT+01:00 Sara Golemon :
> So instead you have to do:
> #if defined(ZEND_ENGINE_2) || defined(ZEND_ENGINE_3)
>
#ifdef ZEND_ENGINE_3
# define ZEND_ENGINE_2
#endif
in php_ext.h, like we had the following for 5.2 compatibles:
#if PHP_VERSION_ID < 503000
# define zend_parse_parameter
Am Thu, 1 Jan 2015 14:41:06 +0200
schrieb Zeev Suraski :
Hallo,
> † Numeric strings with trailing characters and non-numeric strings are
> accepted, but produce a notice.
Why Scalar Type Hints? What is the goal?
- Hints for IDEs - autocompletion?
- Find bugs with static program analysis?
- Find
Syntax forced cast, it makes sense not only for scalar types, but also for
instances of classes.
Is a syntactic sugar can be realized
Hello Jordi,
On 02.01.2015 15:01, Jordi Boggiano wrote:
> Looking at it from an OSS maintainer perspective, introducing strict
> hints in code would be a huge BC break as I don't know how people use my
> code, nor if they validate/coerce their user input early or not. If I
> suddenly declare s
hi,
On Fri, Jan 2, 2015 at 8:04 AM, Nikita Popov wrote:
> Hi internals!
>
> Voting on the removal of deprecated functionality in PHP 7 is now open:
>
> https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7#votes
>
> As requested, I've split this up in many individual votes, only so
hi,
On Fri, Jan 2, 2015 at 9:05 AM, Scott Arciszewski wrote:
> Hi PHP Internals,
>
> Right now, the libsodium PECL package is in the beta channel. Would it be
> possible to include libsodium as a core extension in PHP 7? If so, what
> hurdles would need to be cleared before that happens?
>
> http
> It was deliberate, I did it. The reason for getting rid of it was because it
> makes checking ZE2 simpler, actually. I didn't want to have to do #if
> defined(ZEND_ENGINE_2) && !defined(ZEND_ENGINE_3).
>
So instead you have to do:
#if defined(ZEND_ENGINE_2) || defined(ZEND_ENGINE_3)
But cool
So, PHP 8 then?
On Jan 2, 2015 2:23 PM, "Joe Watkins" wrote:
> Evening Scott,
>
> We should only consider moving an extension from PECL to core if that
> extension is in wide use.
>
> In addition to having a properly established user base, it's a good
> idea to have a stable API since the
Evening Scott,
We should only consider moving an extension from PECL to core if that
extension is in wide use.
In addition to having a properly established user base, it's a good
idea to have a stable API since the development workflow (or pace) for core
extensions is restricted by the re
Hi PHP Internals,
Right now, the libsodium PECL package is in the beta channel. Would it be
possible to include libsodium as a core extension in PHP 7? If so, what
hurdles would need to be cleared before that happens?
http://doc.libsodium.org/
http://pecl.php.net/package/libsodium
https://github.
Hey Matthew,
> On 2 Jan 2015, at 16:35, Matthew Leverton wrote:
>
> I'd much prefer if they were strict types. I have a bias toward this
> because I prefer to be as strict as possible. It's not hard to type
> my_func((int) $_GET['foo']) if I want easy conversion. This explicit
> cast serves as a
On Wed, Dec 31, 2014 at 2:27 PM, Andrea Faulds wrote:
>
> Please read the RFC (and specification patch, if you wish) and tell me your
> thoughts.
>
My thoughts as a long time (non-voting) PHP user:
I'd much prefer if they were strict types. I have a bias toward this
because I prefer to be as str
Hi internals!
Voting on the removal of deprecated functionality in PHP 7 is now open:
https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7#votes
As requested, I've split this up in many individual votes, only some
particularly trivial function deprecations are left as a group.
I
Hi,
On Wed, December 31, 2014 23:21, Anatol Belski wrote:
> Hi,
>
>
> related to bug #43525, I see that zend_fetch_resource() still expects a
> default id as int as parameter. After some investigation i think that the
> "int default_id" argument can be surely dropped from the signature. The
> onl
Hi,
I have a pull request for issue 61285 - SSL connections do not
timeout, and have a question about it's status
I created a pull request for this years ago, back in PHP 5.5.20 and
it was never merged into the master. I recently updated my clone of the
repo to the latest and re-wrote my pa
On 02/01/2015 14:06, Marco Pivetta wrote:
Regardless if this RFC gets through or not, changing the signature of a
method IS a BC break in any case, so you shouldn't just move your `int`
declaration from the docblocks into the method signature.
On public methods yes although a lot of internal pu
On 2 January 2015 at 15:01, Jordi Boggiano wrote:
> Looking at it from an OSS maintainer perspective, introducing strict hints
> in code would be a huge BC break as I don't know how people use my code,
> nor if they validate/coerce their user input early or not. If I suddenly
> declare something
Hey Jordi,
> On 2 Jan 2015, at 14:01, Jordi Boggiano wrote:
>
> And I, on the other hand, disagree.
>
> Looking at it from an OSS maintainer perspective, introducing strict hints in
> code would be a huge BC break as I don't know how people use my code, nor if
> they validate/coerce their use
On 02/01/2015 10:54, Markus Fischer wrote:
On 02.01.15 05:36, Levi Morrison wrote:
I don't necessarily have any more insight to provide than has already
been done, but I do want to chime in and say that I personally favor
strict types as Nikita Popov has been advocating.
Same from me. I suppor
> On 2 Jan 2015, at 13:15, Marco Pivetta wrote:
>
> The manual is wrong since it specifies a strict hint for something that is
> `mixed`. It is still useful tho, since it's telling us "it accepts"
> integer-ish values there. It's purely for documentation purposes though, it
> is by far dictat
On 2 January 2015 at 14:00, Andrea Faulds wrote:
> Hi Marco,
>
> > On 2 Jan 2015, at 09:16, Marco Pivetta wrote:
> >
> >
> > I'm not sure why everyone is still taking the PHP manual as a good
> reference about how to write software: PHP internal functions are one of
> the main reason why this la
Hi Alain,
> On 2 Jan 2015, at 11:45, Alain Williams wrote:
>
> There is a 3rd camp: (c)
> These are the language implementors, in particular 3rd parties eg HipHop.
> These
> do care if a variable is int 42 or string "42" because there are optimisations
> to be made if they know that a value is
Hi Marco,
> On 2 Jan 2015, at 09:16, Marco Pivetta wrote:
>
>
> I'm not sure why everyone is still taking the PHP manual as a good reference
> about how to write software: PHP internal functions are one of the main
> reason why this language is under-appreciated.
>
> The manual is pulling th
On Thu, Jan 01, 2015 at 06:53:00PM -0600, Larry Garfield wrote:
> The "end users" of php-src are "people who write PHP code". Those
> are the end users that we should be concerned with. "People who
> visit web sites" are *their* end users. Those people don't care in
> the slightest what happens
Hey Sara,
> On 2 Jan 2015, at 05:24, Sara Golemon wrote:
>
> I realize that ZE3 is not ZE2, but I always saw the ZEND_ENGINE_2
> define as more of a "At least ZE2" so that code of the form:
>
> #ifdef ZEND_ENGINE_2
> newAPI();
> #else /* ZE1 */
> oldAPI();
> #endif
>
> Would continue making
On 02.01.15 05:36, Levi Morrison wrote:
> I don't necessarily have any more insight to provide than has already
> been done, but I do want to chime in and say that I personally favor
> strict types as Nikita Popov has been advocating.
Same from me. I support all arguments so far made by Nikita; th
On 2 January 2015 at 01:01, Stanislav Malyshev wrote:
> Hi!
>
> > The problem is that the current proposed hints/casts are deviating from
> the
> > type-hints that we are used to, therefore this particular feature should
>
> Let's check the manual we're used to.
> http://php.net/manual/en/functio
33 matches
Mail list logo
