Hi!
> You can choose your point of view - I choose the point of view where we
> replace a broken function with a function that does what developers
> would actually *expect*.
Show me developer that expects core engine functions to go away and be
replaced with functions with almost the same, but s
Hi!
> This would entail a BC break against all software currently written
> using libsodium.
> Are you certain that deeper namespacing would be worth that trade-off?
This is certainly a concern. But this is solvable - we can have aliases,
for example, that would be compiled only in PECL build.
>
Hi!
> It's also impossible to write a PHP class with "internal state" - state
> that I can't find at run-time with reflection. That's what makes the
> language reflective. Internal state in this sense is something foreign
> to PHP as well, the only exception being things like resources, but
> thos
Hi!
> My position on the low level nature of libsodium's APIs is as follows:
> That sounds like a call to action for
> https://wiki.php.net/rfc/php71-crypto rather than a point of concern for
> adopting libsodium.
I think there's a bit of misunderstanding here. The low-level nature of
the API
Hi!
> You can choose your point of view - I choose the point of view where we
> replace a broken function with a function that does what developers
> would actually *expect*.
It's not just a point of view. If it is implemented, it will have
consequences for millions of people using PHP. Adding th
Hi!
> You are completely ignoring the fact that the deprecation and removal of
> gettype() is actually part of my proposal. Anyone who continues to use
> gettype() should be informed that this is not the idiomatic way of
> performing this action and to use the new function instead.
That makes it
Hey Richard,
On 4 June 2016 at 18:41, Fleshgrinder wrote:
> 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
> > __
On Sun, Jun 5, 2016 at 9:35 AM, Scott Arciszewski
wrote:
> On Sun, Jun 5, 2016 at 4:31 AM, Fleshgrinder wrote:
> > On 6/5/2016 10:23 AM, Scott Arciszewski wrote:
> >> I'm trying to keep concerns separate. I do want to make the pluggable
> >> crypto API happen, but I barely have time for this lib
On Mon, May 30, 2016 at 8:01 PM, Jakub Zelenka wrote:
> On Mon, May 30, 2016 at 7:28 PM, Nikita Popov
> wrote:
>
>> On Mon, May 30, 2016 at 6:34 PM, Jakub Zelenka wrote:
>>
>>> On Fri, Sep 4, 2015 at 1:41 AM, Yasuo Ohgaki wrote:
>>>
>>> > Hi all,
>>> >
>>> > IEEE 754 double cannot express exac
On 6/5/2016 3:21 PM, Zeev Suraski wrote:
> We're weighing a certain level of inconsistency that exists with
> gettype(), with a different kind of inconsistency - having typeof()
> and gettype() both be members of the language, and behave subtly
> inconsistently with each other. So this is not cons
On 6/5/16 4:31 AM, Scott Arciszewski wrote:
> - memzero, memcmp, hex2bin
>
> I am not totally convinced that memzero and maybe memcmp names are
> good nor they should be there. Both would be very useful as operator
> on variables. Given the simplicity of the implementations, it could be
> very us
> -Original Message-
> From: Rasmus Schultz [mailto:ras...@mindplay.dk]
> Sent: Sunday, June 05, 2016 2:51 PM
> To: Stanislav Malyshev
> Cc: Sara Golemon ; PHP internals
> Subject: Re: [PHP-DEV] [RFC DISCUSSION] typeof
>
> > So let's add more of it by having multiple functions that do
Hi,
Den 2016-06-01 kl. 09:49, skrev Scott Arciszewski:
Hi PHP Internals Team,
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
On 05/06/16 11:56, Fleshgrinder wrote:
> Quick sketch of a ReflectionVariable class:
>
> https://gist.github.com/Fleshgrinder/40d256a4bf44a0e2579b41d6e92e976e
>
> What do you think?
>
> PS: This would definitely be a different RFC!
The one thing that sticks out from this is 'why do I need all t
> -Ursprüngliche Nachricht-
> Von: Ryan Pallas [mailto:derokor...@gmail.com]
> Gesendet: Sonntag, 5. Juni 2016 14:22
> An: Robert Stoll
> Cc: Bob Weinand; Andrea Faulds; internals@lists.php.net
> Betreff: Re: [PHP-DEV] Re: [RFC] [PRE-VOTE] Union types
>
>
>
> On Sun, Jun 5, 2016 at 6:0
On Sun, Jun 5, 2016 at 6:09 AM, Robert Stoll wrote:
> Hi Andrea, Bob
>
> > -Ursprüngliche Nachricht-
> > Von: Bob Weinand [mailto:bobw...@hotmail.com]
> > Gesendet: Sonntag, 5. Juni 2016 01:00
> > An: Andrea Faulds
> > Cc: internals@lists.php.net
> > Betreff: Re: [PHP-DEV] Re: [RFC] [PRE-
Hi Andrea, Bob
> -Ursprüngliche Nachricht-
> Von: Bob Weinand [mailto:bobw...@hotmail.com]
> Gesendet: Sonntag, 5. Juni 2016 01:00
> An: Andrea Faulds
> Cc: internals@lists.php.net
> Betreff: Re: [PHP-DEV] Re: [RFC] [PRE-VOTE] Union types
>
>
> > Am 05.06.2016 um 00:55 schrieb Andrea Fau
> So let's add more of it by having multiple functions that do exactly the same
thing but name null and float differently.
It's a point of view, that's all.
You can choose your point of view - I choose the point of view where we
replace a broken function with a function that does what developers
Quick sketch of a ReflectionVariable class:
https://gist.github.com/Fleshgrinder/40d256a4bf44a0e2579b41d6e92e976e
What do you think?
PS: This would definitely be a different RFC!
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
Scott Arciszewski schrieb am So., 5. Juni 2016 10:13:
> On Sat, Jun 4, 2016 at 6:15 PM, Stanislav Malyshev
> wrote:
> >
> > 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
> ide
On Sun, Jun 5, 2016 at 2:46 PM, Scott Arciszewski wrote:
>
> On Sun, Jun 5, 2016 at 2:20 AM, Pierre Joye wrote:
>>
>>
>> On Jun 5, 2016 5:15 AM, "Stanislav Malyshev" wrote:
>> >
>>
>> > The stated goal is "You shouldn't need a Ph.D in Applied Cryptography to
>> > build a secure web application."
> Of course they are possible. See __get/__set
Not the same thing at all - PDOStatement::$queryString is a read-only
property, which cannot be overridden, not even with __get() as you would be
able to for regular __get() in a regular PHP class.
It's also impossible to write a PHP class with "inte
On 6/5/2016 10:35 AM, Scott Arciszewski wrote:
> All my problems? How do I get non-root users to install it?
>
How is it possible for them to use it now? You mentioned breaking
changes for existing library users. ;) :P
PHP is not meant to support you extending your user base, no offense!
Our goa
On Sun, Jun 5, 2016 at 4:31 AM, Fleshgrinder wrote:
> On 6/5/2016 10:23 AM, Scott Arciszewski wrote:
>> I'm trying to keep concerns separate. I do want to make the pluggable
>> crypto API happen, but I barely have time for this libsodium RFC and I
>> don't want to conflate the two. (Even worse: I
On 6/5/2016 10:23 AM, Scott Arciszewski wrote:
> I'm trying to keep concerns separate. I do want to make the pluggable
> crypto API happen, but I barely have time for this libsodium RFC and I
> don't want to conflate the two. (Even worse: I wouldn't want the mere
> thought of an abstract high-level
Hi Pierre,
On Thu, Jun 2, 2016 at 10:30 AM, Pierre Joye wrote:
> hi Scott,
>
> On Wed, Jun 1, 2016 at 2:49 PM, Scott Arciszewski wrote:
>> Hi PHP Internals Team,
>>
>> 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 t
On Sun, Jun 5, 2016 at 4:12 AM, Fleshgrinder wrote:
> On 6/5/2016 9:46 AM, Scott Arciszewski wrote:
>> Libsodium already knocks it out of the park compared to OpenSSL and
>> Mcrypt. If we want to talk about a higher-level abstraction-- such as
>> what's provided by paragonie/EasyRSA + defuse/php-e
maybe you can add a few examples to the type table in the rfc, so everybody
knows how it actually works:
function test(int | float | string $a) {var_dump($a);}
test(42.0); // float(42)
test('42'); // string(2) "42"
function test2(int $a) {var_dump($a);}
test2(42.0); // int(42)
test2('42'); // in
On Sat, Jun 4, 2016 at 6:15 PM, Stanislav Malyshev wrote:
>
> 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/libsodi
On 6/5/2016 9:46 AM, Scott Arciszewski wrote:
> Libsodium already knocks it out of the park compared to OpenSSL and
> Mcrypt. If we want to talk about a higher-level abstraction-- such as
> what's provided by paragonie/EasyRSA + defuse/php-encryption or
> paragonie/halite-- I wholeheartedly endor
On 6/5/2016 12:25 AM, Stanislav Malyshev wrote:
> We don't really need the uniform part if we don't have the non-uniform
> one. If the only one we get is uniform, and it's the one we actually
> want, we should not spell it out in the name - we should name it
> something like random_int or random_ra
On Sun, Jun 5, 2016 at 2:20 AM, Pierre Joye wrote:
>
> On Jun 5, 2016 5:15 AM, "Stanislav Malyshev" wrote:
> >
>
> > The stated goal is "You shouldn't need a Ph.D in Applied Cryptography to
> > build a secure web application." I fully agree with this goal. I however
> > feel that current impleme
On 6/5/2016 12:36 AM, Stanislav Malyshev wrote:
> Why it should match scalar types? You can't use output of this function
> in a scalar type in any way.
>
To avoid those WTF moments and make it easier for newcomers.
On 6/5/2016 12:36 AM, Stanislav Malyshev wrote:
> So let's add more of it by hav
33 matches
Mail list logo
