Re: [PHP-DEV] [RFC] Shorter attribute syntax

[Theodore Brown]

On Mon, June 8, 2020 at 1:08 PM Markus Fischer  wrote:

> I noticed that my `@` character did bleed/meld almost with the first 
> character of the attribute name...wide characters like the `M` almost
> touch the `@`.

Hi Markus,

The first question that comes to my mind is, wouldn't this also be an
issue in all the other languages that use the `@Attr` syntax?
Personally I've used TypeScript decorators quite a bit, and the use
of the `@` character hasn't been a readability problem there.

I guess this mostly comes down to the font you use. E.g. here's how
the example looks for me in VS Code with the JetBrains Mono font:

https://imgur.com/a/qWQf6lz

And it's probably safe to say that syntax support/highlighting in
PhpStorm will be improved prior to the release of PHP 8.0. :)

Best regards,  
Theodore

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Shorter attribute syntax

[Rowan Tommins]

Hi Markus,


On 08/06/2020 19:08, Markus Fischer wrote:
Since we humans read source more often then we write, I can only 
suggest to everyone to conduct their own "visual" testing first and 
not just judge on technical merits => I think it makes sense to 
consider both here, since we're already discussing a change here.



I was just thinking about how different fonts would affect this, and 
particularly those with ligatures - a lot of coding fonts already 
include ligatures for << and >> and some have something for #[ as well; 
I wonder how easy it would be to create a "nice" ligature for @@


In doing so, I found this site which lets you compare text in a long 
list of programming fonts, which is interesting to play with how the 
different syntaxes "feel": https://www.programmingfonts.org/


It doesn't have a save/share function, so here's a code sample of the 
main styles discussed so far for people to play with:



// Currently implemented
<>
<>
<>
<>
private $phonenumbers;

// Proposed grouping
<<
  ManyToMany(Phonenumber::class),
  JoinTable("users_phonenumbers"),
  JoinColumn("user_id", "id"),
  InverseJoinColumn("phonenumber_id", "id", JoinColumn::UNIQUE),
>>
private $phonenumbers;

// Rejected alternative in original RFC
@:ManyToMany(Phonenumber::class)
@:JoinTable("users_phonenumbers")
@:JoinColumn("user_id", "id")
@:InverseJoinColumn("phonenumber_id", "id", JoinColumn::UNIQUE)
private $phonenumbers;

// Double-at proposal
@@ManyToMany(Phonenumber::class)
@@JoinTable("users_phonenumbers")
@@JoinColumn("user_id", "id")
@@InverseJoinColumn("phonenumber_id", "id", JoinColumn::UNIQUE)
private $phonenumbers;

// Rust-style
#[ManyToMany(Phonenumber::class)]
#[JoinTable("users_phonenumbers")]
#[JoinColumn("user_id", "id")]
#[InverseJoinColumn("phonenumber_id", "id", JoinColumn::UNIQUE)]
private $phonenumbers;

// Rust-style with grouping
#[
  ManyToMany(Phonenumber::class),
  JoinTable("users_phonenumbers"),
  JoinColumn("user_id", "id"),
  InverseJoinColumn("phonenumber_id", "id", JoinColumn::UNIQUE),
]
private $phonenumbers;


Regards,

--
Rowan Tommins (né Collins)
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Shorter attribute syntax

[Theodore Brown]

On Mon, June 8, 2020 at 10:01 AM Larry Garfield  wrote:

> FWIW, I find both alternatives ugly to my eye. So, there's that.  
>
> Given that `@` is off the table for obvious reasons, my preference
> would frankly be for Rust's `#[]`, which has the nice side effect
> of being a normal comment in earlier PHP versions and so attributes
> can be included as optional without breaking BC. I don't know if
> that's a big deal or not, but it's a benefit. And it should be no
> harder on the parser to differentiate than `@` vs `@@` is.
>
> (The only advantage of `@@` in my mind is another obvious Star Wars
> joke.)

Hi Larry,

>From the perspective of looks I don't have a strong preference
between them. There are two main reasons I decided against borrowing
the `#[]` syntax from Rust:

1. It's a much larger BC break. Disallowing comments from starting
with a certain character could break a lot of code in the wild.
>From a quick search of grep.app, I found two examples on the first
page of results using `#[` as a comment. [1] Is it worth breaking
this code?

2. `#[]` is slightly more verbose, which works against one of the
objectives of the RFC. Rust is the only language I found that uses
three characters for its attribute syntax like this.

I actually starting trying to draft an RFC which would propose the
`#[]` syntax for attributes, but one thing I noticed while doing
so is that (at least on my QWERTY keyboard) `#[` is noticeably
harder to type - I kept typoing it as `#]` or `#\`. This is dependent
on keyboard layout, of course, but being prone to accidental typos
was also one of the arguments against the `@:` syntax in the original
RFC.

> Something that I don't think has been addressed explicitly in this
> thread yet is single line vs separate line attributes.  Vis:
> 
> `<> class Blah {}`
>
> vs.
>
> ```php
> <>
> class Blah {}
> ```
>
> Syntactically both are legal AFAIK; I don't know which most people 
> will do. The separate line version seems more likely, and cleaner 
> to me, but for parameters people may want to inline it in shorter 
> signatures. Or it may push people to always multi-line those
> function definitions, for better or worse. (I find that quite ugly
> myself, but I don't know if I'm in the majority on that view.)
>
> My gut feeling is that `@@` is notably worse inline. It subjectively
> feels messier because there's no clear indication of where the end
> is. On separate lines, `@@` and `<< >>` seem about equally ugly to me.

Personally I have the opposite reaction when it comes to inline
parameter attributes - the closing `>>` always looks like a shift
operator at first glance which makes it harder for me to read. And
for an inline function or class attribute the function/class keyword
already provides a strong indication of where the attribute ends.

But for anything other than very short attributes, I expect most
people will want to put the attribute on a separate line for optimal
readability, regardless of the final syntax:

```php
function foo(
<>
< "val"])>>
Type $myParam,
bool $param2,
) {
...
}

// vs.

function foo(
@@ExampleAttribute("foo", "bar")
@@OtherAttribute(123, ["key" => "val"])
Type $myParam,
bool $param2,
) {
...
}
```

Best regards,  
Theodore

[1]: https://grep.app/search?q=%23%5B&filter[lang][0]=PHP

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Attribute Amendments

[Benjamin Eberlei]

On Mon, Jun 8, 2020 at 6:48 PM Lester Caine  wrote:

> On 08/06/2020 16:30, Benjamin Eberlei wrote:
> >
> >
> > On Mon, Jun 8, 2020 at 11:11 AM Lester Caine  > > wrote:
> >
> > On 08/06/2020 09:44, Marco Pivetta wrote:
> >  > I was mostly conflicted around the "allow grouped attributes"
> > bit, but
> >  > James Titcumb (who currently cannot write to this list due to
> bounced
> >  > emails) convinced me that it is a good replacement for `/**` and
> > `*/`:
> >
> > If twenty years of documentation provided by docblocks is to be
> > replaced
> > there has to be a compelling reason to do so and while this latest
> > drive
> > for yet another documentation method seems to be now a fate acompli
> > there WAS no reason to replace that perfectly acceptable
> documentation!
> >
> >
> > Attributes are not documentation (they could theoretically be used for
> > it, but its not the intented use-case).
> >
> > Attributes are supposed to be used with Runtime Reflection to have an
> > effect on the program.
> >
> > Their existence does not supersede docblocks, only the use of docblocks
> > for meta-programming (essentially doing what Attributes allows with
> > docblocks).
>
> So the statement that "it is a good replacement for `/**` and `*/`" is
> not correct ... it may be that others do not understand the difference?
> Personally none of this is addressing the fundamental problem of
> providing a generic variable system that can manage range as well as
> 'type' ... something the docblock have been providing for a long time
> and moving part of that to some new element is only making things worse :(
>

Ah I think i understand where you come from, the original wording from
Marco was I believe meant to explain only an analogy that <<>> can be seen
as enclosement similar to /** */ in docblocks.

>
> --
> Lester Caine - G8HFL
> -
> Contact - https://lsces.uk/wiki/Contact
> L.S.Caine Electronic Services - https://lsces.uk
> Model Engineers Digital Workshop - https://medw.uk
> Rainbow Digital Media - https://rainbowdigitalmedia.uk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [VOTE] Attribute Amendments

[Benas IML]

Hey,

I'm not sure what you're referring to as "generic variable system" but
given that you mentioned "type", I assume you mean typed variables? If so,
PHP is never going to have typed variables due to performance implications.

As for the `/**` and `*/`, I believe Marco was talking about Doctrine
Annotations. For example, instead of writing this:

```
/**
 * @Route("/users", methods={"GET"})
 * @OtherAnnotation
 */
```

...we would write:

```
<<
Route("/users", ["GET"]),
OtherAnnotation
>>
```

Best regards,
Benas

On Mon, Jun 8, 2020, 7:47 PM Lester Caine  wrote:

> On 08/06/2020 16:30, Benjamin Eberlei wrote:
> >
> >
> > On Mon, Jun 8, 2020 at 11:11 AM Lester Caine  > > wrote:
> >
> > On 08/06/2020 09:44, Marco Pivetta wrote:
> >  > I was mostly conflicted around the "allow grouped attributes"
> > bit, but
> >  > James Titcumb (who currently cannot write to this list due to
> bounced
> >  > emails) convinced me that it is a good replacement for `/**` and
> > `*/`:
> >
> > If twenty years of documentation provided by docblocks is to be
> > replaced
> > there has to be a compelling reason to do so and while this latest
> > drive
> > for yet another documentation method seems to be now a fate acompli
> > there WAS no reason to replace that perfectly acceptable
> documentation!
> >
> >
> > Attributes are not documentation (they could theoretically be used for
> > it, but its not the intented use-case).
> >
> > Attributes are supposed to be used with Runtime Reflection to have an
> > effect on the program.
> >
> > Their existence does not supersede docblocks, only the use of docblocks
> > for meta-programming (essentially doing what Attributes allows with
> > docblocks).
>
> So the statement that "it is a good replacement for `/**` and `*/`" is
> not correct ... it may be that others do not understand the difference?
> Personally none of this is addressing the fundamental problem of
> providing a generic variable system that can manage range as well as
> 'type' ... something the docblock have been providing for a long time
> and moving part of that to some new element is only making things worse :(
>
> --
> Lester Caine - G8HFL
> -
> Contact - https://lsces.uk/wiki/Contact
> L.S.Caine Electronic Services - https://lsces.uk
> Model Engineers Digital Workshop - https://medw.uk
> Rainbow Digital Media - https://rainbowdigitalmedia.uk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [VOTE] Attribute Amendments

[Larry Garfield]

On Mon, Jun 8, 2020, at 11:47 AM, Lester Caine wrote:
> On 08/06/2020 16:30, Benjamin Eberlei wrote:
> > 
> > 
> > On Mon, Jun 8, 2020 at 11:11 AM Lester Caine  > > wrote:
> > 
> > On 08/06/2020 09:44, Marco Pivetta wrote:
> >  > I was mostly conflicted around the "allow grouped attributes"
> > bit, but
> >  > James Titcumb (who currently cannot write to this list due to bounced
> >  > emails) convinced me that it is a good replacement for `/**` and
> > `*/`:
> > 
> > If twenty years of documentation provided by docblocks is to be
> > replaced
> > there has to be a compelling reason to do so and while this latest
> > drive
> > for yet another documentation method seems to be now a fate acompli
> > there WAS no reason to replace that perfectly acceptable documentation!
> > 
> > 
> > Attributes are not documentation (they could theoretically be used for 
> > it, but its not the intented use-case).
> > 
> > Attributes are supposed to be used with Runtime Reflection to have an 
> > effect on the program.
> > 
> > Their existence does not supersede docblocks, only the use of docblocks 
> > for meta-programming (essentially doing what Attributes allows with 
> > docblocks).
> 
> So the statement that "it is a good replacement for `/**` and `*/`" is 
> not correct ... it may be that others do not understand the difference? 
> Personally none of this is addressing the fundamental problem of 
> providing a generic variable system that can manage range as well as 
> 'type' ... something the docblock have been providing for a long time 
> and moving part of that to some new element is only making things worse :(

That... is not related?  This is *not* a documentation tool.  At all.  It's 
more akin to moving Doctrine Annotations into core (junior version thereof).  
It doesn't render docblocks redundant, it renders "using docblocks for custom 
metaprogramming" redundant, which was always a fugly hack to begin with.

A type system improvement for "this parameter must be a positive integer less 
than 50" would be super nice, I agree, but is in no way related to the topic at 
hand at all.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Shorter attribute syntax

[Markus Fischer]

Hi Theodore,

On 08.06.20 06:36, Theodore Brown wrote:

```php
// 170 characters for attributes (162 not counting leading whitespace)
<<
   ManyToMany(Phonenumber::class),
   JoinTable("users_phonenumbers"),
   JoinColumn("user_id", "id"),
   InverseJoinColumn("phonenumber_id", "id", JoinColumn::UNIQUE),



private $phonenumbers;

// 160 characters for attributes
@@ManyToMany(Phonenumber::class)
@@JoinTable("users_phonenumbers")
@@JoinColumn("user_id", "id")
@@InverseJoinColumn("phonenumber_id", "id", JoinColumn::UNIQUE)
private $phonenumbers;
```


When your proposal came up, my first thought was this is great and 
should be supported; I simply had a liking for this terse syntax over 
the older.


Until I read your email last night and saw some direct text comparison.

I noticed that my `@` character did bleed/meld almost with the first 
character of the attribute name. I noticed this in my MUA so I figured a 
proper test in the IDE with my font of choice is more realistic; here's 
a plainly colored version first:


https://i.imgur.com/tq7FzQz.png

Notice how wide characters like the `M` almost touch the `@`.

Same now in a best attempt PHP syntax highlighted source file (courtesy 
of PhpStorm, obviously not supporting this ATM):


https://i.imgur.com/WVXL8S7.png

But even a clearly distinct colored `@@` token did, for me personally, 
not increase the readability by much ("to me").


At this point I forgot if the following is a valid combination, but it 
wouldn't matter as I want to make comparison data point for my 
personally and even this version is by far more readable, to me at least:


https://i.imgur.com/GI3HlsM.png

Until I had this realization, I was absolutely in favour of `@@`. I'm 
not so much anymore.


Since we humans read source more often then we write, I can only suggest 
to everyone to conduct their own "visual" testing first and not just 
judge on technical merits => I think it makes sense to consider both 
here, since we're already discussing a change here.


(note: I'm not a voter here)

I wonder what others think about this.

thanks,
- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Attribute Amendments

[Lester Caine]

On 08/06/2020 16:30, Benjamin Eberlei wrote:



On Mon, Jun 8, 2020 at 11:11 AM Lester Caine > wrote:


On 08/06/2020 09:44, Marco Pivetta wrote:
 > I was mostly conflicted around the "allow grouped attributes"
bit, but
 > James Titcumb (who currently cannot write to this list due to bounced
 > emails) convinced me that it is a good replacement for `/**` and
`*/`:

If twenty years of documentation provided by docblocks is to be
replaced
there has to be a compelling reason to do so and while this latest
drive
for yet another documentation method seems to be now a fate acompli
there WAS no reason to replace that perfectly acceptable documentation!


Attributes are not documentation (they could theoretically be used for 
it, but its not the intented use-case).


Attributes are supposed to be used with Runtime Reflection to have an 
effect on the program.


Their existence does not supersede docblocks, only the use of docblocks 
for meta-programming (essentially doing what Attributes allows with 
docblocks).


So the statement that "it is a good replacement for `/**` and `*/`" is 
not correct ... it may be that others do not understand the difference? 
Personally none of this is addressing the fundamental problem of 
providing a generic variable system that can manage range as well as 
'type' ... something the docblock have been providing for a long time 
and moving part of that to some new element is only making things worse :(


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] What to do with ext/imap?

[G. P. B.]

On Mon, 8 Jun 2020 at 18:15, Christoph M. Becker  wrote:

> Hi all,
>
> I'm wondering what to do with ext/imap, which uses libc-client which had
> its latest release (2007f) in 2011.  There is a respective feature
> request in the bug tracker () where some
> ideas have been discussed, but apparently, not much happened for a
> while, and since feature freeze for PHP 8.0 is approaching, I wanted to
> bring this issue up on the mailing list.
>
> Any ideas?
>
> Thanks,
> Christoph
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Seeing that most core devs seem to prefer the option of sunsetting the
extension, I think this would be the best choice to enact.

Best regards

George P. Banyard

[PHP-DEV] What to do with ext/imap?

[Christoph M. Becker]

Hi all,

I'm wondering what to do with ext/imap, which uses libc-client which had
its latest release (2007f) in 2011.  There is a respective feature
request in the bug tracker () where some
ideas have been discussed, but apparently, not much happened for a
while, and since feature freeze for PHP 8.0 is approaching, I wanted to
bring this issue up on the mailing list.

Any ideas?

Thanks,
Christoph

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Remove inappropriate inheritance signature checks on private methods

[Marco Pivetta]

Hey Pedro,

On Mon, Jun 8, 2020 at 5:59 PM Pedro Magalhães  wrote:

> On Wed, May 27, 2020 at 12:07 AM Pedro Magalhães  wrote:
>
>> On Tue, May 26, 2020 at 3:46 PM Marco Pivetta  wrote:
>>
>>> Considering that, as far as I know, only the constructor remains
>>> "special".
>>>
>>
>> Leaving the special case only for constructors instead of all magic
>> methods sounds better to me. Right now, that sounds like a winning
>> compromise for the RFC. It is still an exception to a rule, but one that
>> can be better justified.
>>
>> Thanks,
>> Pedro
>>
>
> I have updated both the implementation and the RFC to reflect this
> exception for constructors. If no further discussion comes up, I'll open
> the vote in a few days.
>
> Regards,
> Pedro
>

Looking good! Just some formatting issues around __construct (rendered as
_construct), but otherwise I would vote +1 for this!

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] [RFC] [Discussion] Remove inappropriate inheritance signature checks on private methods

[Pedro Magalhães]

On Wed, May 27, 2020 at 12:07 AM Pedro Magalhães  wrote:

> On Tue, May 26, 2020 at 3:46 PM Marco Pivetta  wrote:
>
>> Considering that, as far as I know, only the constructor remains
>> "special".
>>
>
> Leaving the special case only for constructors instead of all magic
> methods sounds better to me. Right now, that sounds like a winning
> compromise for the RFC. It is still an exception to a rule, but one that
> can be better justified.
>
> Thanks,
> Pedro
>

I have updated both the implementation and the RFC to reflect this
exception for constructors. If no further discussion comes up, I'll open
the vote in a few days.

Regards,
Pedro

Re: [PHP-DEV] [VOTE] Attribute Amendments

[Benjamin Eberlei]

On Mon, Jun 8, 2020 at 11:11 AM Lester Caine  wrote:

> On 08/06/2020 09:44, Marco Pivetta wrote:
> > I was mostly conflicted around the "allow grouped attributes" bit, but
> > James Titcumb (who currently cannot write to this list due to bounced
> > emails) convinced me that it is a good replacement for `/**` and `*/`:
>
> If twenty years of documentation provided by docblocks is to be replaced
> there has to be a compelling reason to do so and while this latest drive
> for yet another documentation method seems to be now a fate acompli
> there WAS no reason to replace that perfectly acceptable documentation!
>

Attributes are not documentation (they could theoretically be used for it,
but its not the intented use-case).

Attributes are supposed to be used with Runtime Reflection to have an
effect on the program.

Their existence does not supersede docblocks, only the use of docblocks for
meta-programming (essentially doing what Attributes allows with docblocks).

>
> --
> Lester Caine - G8HFL
> -
> Contact - https://lsces.uk/wiki/Contact
> L.S.Caine Electronic Services - https://lsces.uk
> Model Engineers Digital Workshop - https://medw.uk
> Rainbow Digital Media - https://rainbowdigitalmedia.uk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Shorter attribute syntax

[Larry Garfield]

On Sun, Jun 7, 2020, at 11:36 PM, Theodore Brown wrote:

> > Bracket-based syntaxes, particularly with grouping, are more clearly 
> > separated from the main code, particularly when used inline. For instance:
> > 
> > `$f = @@Something @@AnotherThing function(@@Special @@ReallyInt int $var) 
> > {};`  
> > vs  
> > `$f = <> function(<> int $var) 
> > {};`
> 
> To me there doesn't seem to be a big difference in readability between
> the function attributes in this example. And with syntax highlighting,
> the function keyword itself provides a very clear separation.
> 
> For the parameter attributes, the `@@` syntax example is actually
> more readable to my eye. I can't help seeing the `>>` token as a
> shift operator at first glance in this context.
> 
> > Finally, typing up those examples, it occurs to me that `@@` is quite a 
> > "heavy" symbol - it has a large proportion of black (or whatever colour) 
> > pixels - and inevitably a rather "fussy" one. I find it draws the eye 
> > more than the angle-brackets do, which feels unfortunate.
> 
> I guess this is somewhat dependent on the font you're using. But in
> general I don't think that the symbol being "heavy" is necessarily
> a bad thing. It can help attributes stand out better from function
> calls, generics, and other nearby syntax.
> 
> Best regards,  
> Theodore
> 
> [1]: https://wiki.php.net/rfc/attributes_v2#use_cases

FWIW, I find both alternatives ugly to my eye.  So, there's that.  

Given that @ is off the table for obvious reasons, my preference would frankly 
be for Rust's #[], which has the nice side effect of being a normal comment in 
earlier PHP versions and so attributes can be included as optional without 
breaking BC.  I don't know if that's a big deal or not, but it's a benefit.  
And it should be no harder on the parser to differentiate than @ vs @@ is.

(The only advantage of @@ in my mind is another obvious Star Wars joke.)

Something that I don't think has been addressed explicitly in this thread yet 
is single line vs separate line attributes.  Vis:

<> class Blah {}

vs.

<>
class Blah {}

Syntactically both are legal AFAIK; I don't know which most people will do.  
The separate line version seems more likely, and cleaner to me, but for 
parameters people may want to inline it in shorter signatures.  Or it may push 
people to always multi-line those function definitions, for better or worse.  
(I find that quite ugly myself, but I don't know if I'm in the majority on that 
view.)

My gut feeling is that @@ is notably worse inline.  It subjectively feels 
messier because there's no clear indication of where the end is.  On separate 
lines, @@ and << >> seem about equally ugly to me.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Session default settings (use_strict_mode)

[Eddie Kohler]

Enabling same-site cookies by default is a little risky now, because
current browsers don't always set them properly.

https://bugs.chromium.org/p/chromium/issues/detail?id=961617


On Sun, Jun 7, 2020 at 6:42 PM Claude Pache  wrote:

>
>
> > Le 7 juin 2020 à 22:15, AllenJB  a écrit :
> >
> > Are there any other session (security) related settings that should be
> tightened by default? (cookie_samesite?)
>
>
> Yes, of course:
>
> * session.cookie_httponly should be "1" by default.
> * session.cookie_samesite should be "Lax" by default.
> * Ideally, session.cookie_secure should be enabled by default on https;
> sadly, the setting does not allow to have different values for secure and
> insecure connections.
>
> —Claude

Re: [PHP-DEV] New functions `hash_serialize` and `hash_unserialize`?

[Johannes Schlüter]

On Mon, 2020-06-08 at 09:01 -0400, Eddie Kohler wrote:
> I'm writing to gauge interest in two new functions to the PHP `hash`
> extension, `hash_serialize` and `hash_unserialize`. These functions
> would serialize and unserialize the internals of a HashContext
> objectallowing a partially-computed hash to be saved, then restored
> and completed in a laterrun.

I would suggest to make the HashContext Serializable, then 

serialize($hash_context);

works. Then it also fits when stored in other objects or something ...

johannes

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] New functions `hash_serialize` and `hash_unserialize`?

[Eddie Kohler]

Hello internals! Thanks for PHP!

I'm writing to gauge interest in two new functions to the PHP `hash`
extension, `hash_serialize` and `hash_unserialize`. These functions would
serialize and unserialize the internals of a HashContext object, allowing a
partially-computed hash to be saved, then restored and completed in a later
run.

EXAMPLE: Multi-part upload.

Say that a very large file is uploaded in pieces, `big.001` through
`big.999`, and it is necessary to compute the SHA256 of the final
concatenated file.
Current PHP must compute the hash in one go:

$ctx = hash_init("sha256");
for ($i = 1; $i <= 999; ++$i) {
 hash_update_file($ctx, sprintf("big.%.03d", $i));
}
$hash = hash_final($ctx);

This in turn requires that all pieces be on the filesystem simultaneously.

With hash_serialize and hash_unserialize, the hash can be computed
gradually, allowing pieces to be deleted as they are uploaded elsewhere.

$ctx = hash_init("sha256");
hash_update_file($ctx, "big.001");
SAVE_TO_DATABASE(hash_serialize($ctx));
...
$ctx = hash_unserialize(LOAD_FROM_DATABASE());
hash_update_file($ctx, "big.002");
SAVE_TO_DATABASE(hash_serialize($ctx));
...
etc.

***

I am happy to write up an RFC for these functions. An initial
implementation with tests is visible here:
https://github.com/kohler/php-src/commit/5a3a828f90b88cd7f660babec7db531cfc04b0a1

New functions `hash_serialize` and `hash_unserialize` appear to fit the
existing API well, and simplify implementation, but it's possible that
`__serialize/__unserialize` or the internal `serialize/unserialize`
functions would be preferred.

I'd be grateful for any feedback.
Thanks!
Eddie Kohler

Re: [PHP-DEV] [RFC] Named arguments

[Nikita Popov]

On Fri, Jun 5, 2020 at 3:40 PM Nikita Popov  wrote:

> On Fri, Jun 5, 2020 at 12:45 PM Christian Schneider 
> wrote:
>
>> Am 05.05.2020 um 15:51 schrieb Nikita Popov :
>> > \I've now updated the old proposal on this topic, and moved it back
>> under
>> > discussion: https://wiki.php.net/rfc/named_params
>>
>> First of all I really like this approach to Named Parameters: It seems to
>> fit well with the rest of PHP.
>>
>> Note: I'm using the key: 'value' syntax instead of key => 'value' here
>> but that's just because I prefer that syntax and think it more naturally
>> extends to stuff like the shorthand syntax under "Future Scope" but that's
>> not a prerequisite.
>>
>> I have two questions regarding to the Named Parameters which are not
>> related to the LSP discussion.
>> They might be restrictions of the current implementation mentioned in the
>> RFC as opposed to design restrictions:
>>
>> 1) Could keywords be allowed as parameter names? Currently using class:
>> 'foo' throws a syntax error.
>> 2) Could positional parameters be allowed after named parameters for
>> variadic functions?
>>
>> These two restrictions can be looked at separately and the only reason
>> I'm bringing them up together is because the use case I'm looking at is
>> HTML generation with something like a function div() being used as follows.
>> Please don't discard the two questions just because you don't like this
>> particular use-case, thank you ;-)
>> div(class: 'error',
>> div(class: 'title', "Error Title"),
>> "Detailed error description...",
>> )
>>
>> The first issue is probably mainly a parsing issue and changing T_STRING
>> to identifier seems to fix it though I'm not 100% sure if there are any
>> drawbacks to this.
>>
>
> Right. It should be possible to use keywords. It's a bit harder than just
> replacing T_STRING with identifier, but I don't see any fundamental reason
> why it shouldn't work.
>

I've implemented the necessary groundwork for this in
https://github.com/php/php-src/commit/b03cafd19c01db57b89727ce77cc89a7d816077c,
so now I can say for sure that using keywords as parameter name will work
fine.

Nikita

Re: [PHP-DEV] RFC: Error backtraces

[Dan Ackroyd]

On Tue, 2 Jun 2020 at 21:57, Max Semenik  wrote:
>
> Thanks for your input!
>

> The problem with this is that it doesn't get called on fatal errors,

That would be an easier and smaller thing to fix, rather than also
changing error/warning handling.

A stack trace shown on fatal errors that doesn't include any variables
would be a useful thing imo.

> I don't see leaks via traces as a serious problem.

That is an opinion not universally shared.

I know one company that failed a security audit, and so failed to win
a contract, due to variables being exposed in stacktraces that reached
their log files.

> Your solution requires programmers to write code
> supporting this kind of workflow,

Sorry, not sure what you mean.

The changes would be internal, and then would naturally reach the
users outer exception handler, where they should already have logging
of uncaught exceptions. So can't see why it would be a problem.

> Sorry, didn't realize the word is, uh, "informal".

Informal? _Infernal_ more like. *ba-dum-tish*

Danack wrote:
>> That depends on what callback function has been set for
>> 'set_exception_handler'.
Max wrote:
> From my reading of the code, backtraces are generated on object creation,

I meant that whether the trace is converted to a string and logged
anywhere is dependent on what the exception handler chooses to do.

> INI setting should take care of this.

People really, really really, _really_ don't  like ini settings.

Although application level ini settings can be appropriate in some
cases, a new ini setting here doesn't feel like a great choice.

Combine that with "As shown in the example output, traces are saved as
string" and I really don't like it.

We want to make it possible to decide what to do with errors programmatically.

Converting stack traces to strings before a user handler can decide
what to do with them is not a good approach.

To summarise, adding stack trace to fatal error output (without
variables) sounds good to me, and the idea I said before of adding
exceptions to errors/warning would allow better user control over what
happens also sounds good, but more ini settings and traces as strings
sounds not good.

cheers
Dan
Ack

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Attribute Amendments

[Dan Ackroyd]

On Mon, 8 Jun 2020 at 09:13, Benjamin Eberlei  wrote:
>
> I have opened voting for four different amendments to the Attributes RFC
>
> https://wiki.php.net/rfc/attribute_amendments

To explain a 'no' vote.

> Should a secondary grouped syntax for attributes be introduced?

Voted no, as it's not obviously required, and can be added later.
Also, we aren't that good at designing the 'group' syntax. See group
use for a bad example.

> Should attributes allow definition of repeatability?
> Should attributes allow definition of target declarations?

Voted no for both, as they can be enforced in userland, or be added to
core later if some reason for why they must be in core is found.

cheers
Dan
Ack

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Attribute Amendments

[Lester Caine]

On 08/06/2020 09:44, Marco Pivetta wrote:

I was mostly conflicted around the "allow grouped attributes" bit, but
James Titcumb (who currently cannot write to this list due to bounced
emails) convinced me that it is a good replacement for `/**` and `*/`:


If twenty years of documentation provided by docblocks is to be replaced 
there has to be a compelling reason to do so and while this latest drive 
for yet another documentation method seems to be now a fate acompli 
there WAS no reason to replace that perfectly acceptable documentation!


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Attribute Amendments

[Marco Pivetta]

Hey Benjamin,

On Mon, Jun 8, 2020 at 10:13 AM Benjamin Eberlei 
wrote:

> Hello internals,
>
> I have opened voting for four different amendments to the Attributes RFC
>
> https://wiki.php.net/rfc/attribute_amendments
>
> The voting period ends at 2020-06-22 8:00 UTC.
>
> greetings
> Benjamin
>

I was mostly conflicted around the "allow grouped attributes" bit, but
James Titcumb (who currently cannot write to this list due to bounced
emails) convinced me that it is a good replacement for `/**` and `*/`:

<<
Foo,
Bar,
>>

I'm mostly worried that people will do a mess like with grouped use
statements, but hopefully we can fix that via CS rules :-)

Overall, good improvement!

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

[PHP-DEV] [VOTE] Attribute Amendments

[Benjamin Eberlei]

Hello internals,

I have opened voting for four different amendments to the Attributes RFC

https://wiki.php.net/rfc/attribute_amendments

The voting period ends at 2020-06-22 8:00 UTC.

greetings
Benjamin