Re: [PHP-DEV] Re: [RFC] [PRE-VOTE] Union types

> Am 05.06.2016 um 00:55 schrieb Andrea Faulds : > > Hi again, > > In an attempt to be constructive, I have implemented an alternative approach > to weak scalar type selection here: > > https://github.com/krakjoe/php-src/compare/multi-types...TazeTSchnitzel:multi-types-roulette >

Re: [PHP-DEV] Re: [RFC] [PRE-VOTE] Union types

Hi! > Where there is no exact scalar type match, this patch uses an algorithm > originally suggested by Nikita, wherein we use rand() to pick which type > to cast to. Random type conversion. For people that are bored with plaid old deterministic code bugs. -- Stas Malyshev smalys...@gmail.com

Re: [PHP-DEV] can't reflection on DateTime properties?

Hi! > I know that things like internal state and read-only properties are > possible for classes written in C, but those features aren't possible in > PHP code - classes that behave this way are inconsistent with classes Of course they are possible. See __get/__set. But yes, internal classes

Re: [PHP-DEV] Re: [RFC] [PRE-VOTE] Union types

Hi again, In an attempt to be constructive, I have implemented an alternative approach to weak scalar type selection here: https://github.com/krakjoe/php-src/compare/multi-types...TazeTSchnitzel:multi-types-roulette Where there is no exact scalar type match, this patch uses an algorithm

Re: [PHP-DEV] [RFC DISCUSSION] typeof

Hi! > The old function is actively causing confusion - the reported type-names > aren't even inconsistent with scalar type-hints, and then you have to go > and read the manual with some explanation about historical reasons why > the function doesn't work like you'd expect. Why it should match

Re: [PHP-DEV] [RFC] Libsodium - Discussion

Hi! > For instance nonce arguments ... > > $nonce = randombytes_buf(CRYPTO_SECRETBOX_NONCEBYTES); > crypto_secretbox(... Speaking of which, what about just passing null there (or make it optional) that would make the function generate a new random nonce of suitable size? It's BTW would be

Re: [PHP-DEV] [RFC] Libsodium - Discussion

Hi! > Let's begin discussing the prospect of adding libsodium as a core extension > in PHP 7.1. I've updated the RFC to explain why this would be a good idea > and the benefits it offers. > > https://wiki.php.net/rfc/libsodium > > If the subsequent discussion goes smoothly, I would like to open

Re: [PHP-DEV] can't reflection on DateTime properties?

On 04/06/16 21:23, Stanislav Malyshev wrote: > In generic case, you can't have internal state of an object, that's why > it's internal. If you need to serialize data, there are > serialize/unserialize handlers for it. This is also why DateTime is useless for many data handling functions since

Re: [PHP-DEV] [RFC DISCUSSION] typeof

> I don't think we need a core function that almost exactly duplicates the > working of existing function but with a slight tweak. I do not think it is a good idea to do such things, it only produces more confusion. I strongly disagree. The old function is actively causing confusion - the

Re: [PHP-DEV] can't reflection on DateTime properties?

On 6/4/2016 11:05 PM, Rasmus Schultz wrote: > I know that things like internal state and read-only properties are > possible for classes written in C, but those features aren't possible in > PHP code - classes that behave this way are inconsistent with classes > written in the language, and it

Re: [PHP-DEV] can't reflection on DateTime properties?

> In generic case, you can't have internal state of an object, that's why it's internal I know that things like internal state and read-only properties are possible for classes written in C, but those features aren't possible in PHP code - classes that behave this way are inconsistent with

Re: [PHP-DEV] [RFC DISCUSSION] typeof

Hi! >> My number one issue with this PR is that it's all PHP code. There's nothing > in here that couldn't be done as a composer installable library > > It's a valid point, but not really a good argument against having it - the > same could after all be said about a lot of PHP functions. Many

Re: [PHP-DEV] [RFC DISCUSSION] typeof

Hi! > I prepared my first contribution to internals: > > https://github.com/php/php-src/pull/1932 I don't think we need a core function that almost exactly duplicates the working of existing function but with a slight tweak. I do not think it is a good idea to do such things, it only produces

Re: [PHP-DEV] can't reflection on DateTime properties?

Hi! > The object clearly has properties corresponding to it's internal state, but > reflection doesn't seem to report them? Reflection reports defined properties, but classes can have dynamic properties that are not pre-defined. var_dump also has a separate handler, so the object can present

Re: [PHP-DEV] can't reflection on DateTime properties?

On Sat, Jun 4, 2016 at 9:42 PM, Jordi Boggiano wrote: > On 04/06/2016 20:36, Rasmus Schultz wrote: > >> I wrote a library that can serialize/unserialize PHP object graphs to JSON >> data. >> >> Somebody reported it doesn't work on the DateTime class. >> >> Does this

Re: [PHP-DEV] can't reflection on DateTime properties?

On Sat, 04 Jun 2016 22:36:19 +0300, Rasmus Schultz wrote: I wrote a library that can serialize/unserialize PHP object graphs to JSON data. Somebody reported it doesn't work on the DateTime class. Does this deliberately not work? $date = new DateTime();

Re: [PHP-DEV] can't reflection on DateTime properties?

On 04/06/2016 20:36, Rasmus Schultz wrote: I wrote a library that can serialize/unserialize PHP object graphs to JSON data. Somebody reported it doesn't work on the DateTime class. Does this deliberately not work? $date = new DateTime(); var_dump($date); outputs:

[PHP-DEV] can't reflection on DateTime properties?

I wrote a library that can serialize/unserialize PHP object graphs to JSON data. Somebody reported it doesn't work on the DateTime class. Does this deliberately not work? $date = new DateTime(); var_dump($date); outputs: object(DateTime)#1 (3) { ["date"]=> string(19)

Re: [PHP-DEV] [RFC DISCUSSION] typeof

> My number one issue with this PR is that it's all PHP code. There's nothing in here that couldn't be done as a composer installable library It's a valid point, but not really a good argument against having it - the same could after all be said about a lot of PHP functions. The problem is that

Re: [PHP-DEV] [RFC DISCUSSION] typeof

On 6/4/2016 7:37 PM, Sara Golemon wrote: > On Sat, Jun 4, 2016 at 5:12 AM, Fleshgrinder wrote: >> I prepared my first contribution to internals: >> > Welcome! > Hi Sara, nice to eventually becoming part of it. :) On 6/4/2016 7:37 PM, Sara Golemon wrote: > I've put a

Re: [PHP-DEV] [RFC DISCUSSION] typeof

On Sat, Jun 4, 2016 at 5:12 AM, Fleshgrinder wrote: > I prepared my first contribution to internals: > Welcome! > https://github.com/php/php-src/pull/1932 > I've put a couple minor notes on the implementation. Nothing technically wrong, just style and micro-perf. > I

Re: [PHP-DEV] [RFC DISCUSSION] typeof

On 6/4/2016 7:09 PM, Rasmus Schultz wrote: > Hi Richard, > > I can't review the implementation, but the RFC looks good - great > initiative! > > The only thing I would comment on, is the idea of packing essentially two > different functions into one - by default, the return value is a >

Re: [PHP-DEV] [RFC DISCUSSION] typeof

Hi Richard, I can't review the implementation, but the RFC looks good - great initiative! The only thing I would comment on, is the idea of packing essentially two different functions into one - by default, the return value is a machine-friendly type-name, but the $extended argument turns it

Re: [PHP-DEV] [RFC DISCUSSION] typeof

On 6/4/2016 6:17 PM, Marco Pivetta wrote: > It would be beneficial to not reduce this to stringly-typed programmer > (again), as Dan mentioned. > > Returning something like a ReflectionType instance (which then implements > __toString) would be much simpler, efficient and easy to use. > > Marco

Re: [PHP-DEV] [RFC DISCUSSION] typeof

It would be beneficial to not reduce this to stringly-typed programmer (again), as Dan mentioned. Returning something like a ReflectionType instance (which then implements __toString) would be much simpler, efficient and easy to use. Marco Pivetta http://twitter.com/Ocramius

Re: [PHP-DEV] [RFC DISCUSSION] typeof

On 6/4/2016 4:34 PM, Dan Ackroyd wrote: > Hello FG, > > Having a standard way to get the type of a variable, that matches the > name of how it appears in PHP is a good idea. > > The 'extended' parameter is not such a good idea, for various reasons > but mainly because it's simpler for people to

Re: [PHP-DEV] [RFC] [PRE-VOTE] Union types

> Am 4.6.2016 um 15:48 schrieb Niklas Keller : > > Massive is a nice hyperbole here... > Sure, you can check it manually… but why not just always check it manually > then? > You then loose possibilities to reflect on it, have static analysis rely on > code only [currently you

Re: [PHP-DEV] [RFC] [PRE-VOTE] Union types

> Am 4.6.2016 um 16:17 schrieb Christoph Becker : > > On 04.06.2016 at 14:15, Bob Weinand wrote: > >>> Am 04.06.2016 um 13:45 schrieb Niklas Keller : >>> >>> For Aerys\Host it could also be solved with an interface that just doesn't >>> have any methods.

Re: [PHP-DEV] [RFC DISCUSSION] typeof

On 4 June 2016 at 13:12, Fleshgrinder wrote: > Hi all! > > I prepared my first contribution to internals: > > https://github.com/php/php-src/pull/1932 > Hello FG, Having a standard way to get the type of a variable, that matches the name of how it appears in PHP is a good

Re: [PHP-DEV] [RFC] [PRE-VOTE] Union types

On 04.06.2016 at 14:15, Bob Weinand wrote: >> Am 04.06.2016 um 13:45 schrieb Niklas Keller : >> >> For Aerys\Host it could also be solved with an interface that just doesn't >> have any methods. With the disadvantage of callable not being in the same >> signature anymore. > >

Re: [PHP-DEV] [RFC] [PRE-VOTE] Union types

> > Massive is a nice hyperbole here... > Sure, you can check it manually… but why not just always check it manually > then? > You then loose possibilities to reflect on it, have static analysis rely > on code only [currently you always have to check docblocks when it's not > declared; definitely

Re: [PHP-DEV] [RFC] [PRE-VOTE] Union types

> Am 04.06.2016 um 13:45 schrieb Niklas Keller : > > Bob Weinand > schrieb am > Fr., 3. Juni 2016 23:31: > > > Am 3.6.2016 um 18:49 schrieb Larry Garfield > >: > > > >

[PHP-DEV] [RFC DISCUSSION] typeof

Hi all! I prepared my first contribution to internals: https://github.com/php/php-src/pull/1932 I would like to discuss the proposed new function here. I directly went on and implemented it for the learning experience. I also prepared the RFC, but as a Gist because I do not have Karma yet:

Re: [PHP-DEV] [RFC] [PRE-VOTE] Union types

Bob Weinand schrieb am Fr., 3. Juni 2016 23:31: > > > Am 3.6.2016 um 18:49 schrieb Larry Garfield : > > > > On 06/03/2016 10:16 AM, Jordi Boggiano wrote: > >> On 03/06/2016 15:58, Thomas Bley wrote: > >>> To me type declarations help to make my code

[PHP-DEV] Issues with AIX and PHP packaging - should I bother with a bug report?

Hi, yesterday I mentioned an old issue re: an issue on AIX - that probably only occurs when not using gcc. Further, because it was time - I am still using php 5.2 because of all the little irritations when it comes to packaging PHP - I went through the process of building the "generic" php