Re: [PHP-DEV] Inline conditional that returns null if falsy

[Larry Garfield]

On Thu, Feb 25, 2021, at 2:55 AM, Rowan Tommins wrote:
> On 24/02/2021 04:26, Mike Schinkel wrote:
> > Repeating code similar to that from the message sent by David Rodrigues you 
> > can see that eliminating the ": null" is less noisy:
> >
> >  ...
> >  ...
> 
> 
> That's an interesting use case. Of course, the logical default there is 
> actually '' (empty string) rather than null, since "echo null;" doesn't 
> actually make much sense, but null works under current type juggling rules.
> 
> Then again, perhaps this is a good example of why PHP *isn't* the best 
> choice any more if you want a templating language. Twig, for instance, 
> has exactly this facility 
> [https://twig.symfony.com/doc/3.x/templates.html#other-operators]:

Given the security implications of plain PHP templating (you're on your own for 
absolutely all filtering and escaping, good luck), I'd say this isn't even a 
controversial statement.  PHP may have begun life as a templating language for 
the 90s, but in the 2020s it's a fairly mediocre option at best compared to 
what else is readily available.

--Larry Garfield

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

Re: [PHP-DEV] [RFC] class_name:namespace

[Manuel Canga]

--
Manuel Canga

Zend Certified PHP Engineer 
Websites: https://manuelcanga.dev | https://trasweb.net
Linkedin: https://es.linkedin.com/in/manuelcanga




  En jue, 25 feb 2021 23:12:23 +0100 David Gebler  
escribió 
 > You can achieve what you're trying to do already with a combination of
 > get_class() on a namespaced class and a simple regex (or other method of
 > processing a string to your liking):
 > 
 > $foo = "My\\Namespace\\Name\\Class";
 > var_dump(preg_match('/^(.*)\\\([^\\\]*)$/m',$foo,$matches),$matches);
 > 
 > array(3) {
 >   [0] =>
 >   string(23) "My\Namespace\Name\Class"
 >   [1] =>
 >   string(17) "My\Namespace\Name"
 >   [2] =>
 >   string(5) "Class"
 > }
 > 
 > Regards
 > David Gebler
 > 

Hi, David.

::namespace notation would be more semantic and faster.

Other example: In WordPress, classes use class-{{class-name}}.php notation for 
file of classes[1]. Example: class-wp-error.php

An autoloader for WordPress could be:

```
https://make.wordpress.org/core/handbook/best-practices/coding-standards/php/#naming-conventions
--
Manuel Canga

Zend Certified PHP Engineer 
Websites: https://manuelcanga.dev | https://trasweb.net
Linkedin: https://es.linkedin.com/in/manuelcanga

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

Re: [PHP-DEV] [RFC] class_name:namespace

[David Gebler]

You can achieve what you're trying to do already with a combination of
get_class() on a namespaced class and a simple regex (or other method of
processing a string to your liking):

$foo = "My\\Namespace\\Name\\Class";
var_dump(preg_match('/^(.*)\\\([^\\\]*)$/m',$foo,$matches),$matches);

array(3) {
  [0] =>
  string(23) "My\Namespace\Name\Class"
  [1] =>
  string(17) "My\Namespace\Name"
  [2] =>
  string(5) "Class"
}

Regards
David Gebler

On Thu, Feb 25, 2021 at 9:40 PM Manuel Canga  wrote:

>   En jue, 25 feb 2021 21:41:40 +0100 Nikita Popov <
> nikita@gmail.com> escribió 
>  > On Thu, Feb 25, 2021 at 8:11 PM Manuel Canga 
> wrote:
>  >
>  > > Hi internals,
>  > >
>  > > I would like to present a possible new RFC( "class_name:namespace" )
> for
>  > > your consideration.
>  > >
>  > > As you know, namespaces are very important nowdays. They are used in
>  > > autoloaders, Frameworks, CMS, ...
>  > >
>  > > Maybe, you are used to code something similar to this:
>  > >
>  > > ```
>  > > use MyProject\MyHelpers\MyClass;
>  > >
>  > > echo substr( MyClass::class, 0, strrpos( MyClass::class, '\\'));
>  > > ```
>  > >
>  > > or perhaps:
>  > >
>  > > ```
>  > > use MyProject\MyHelpers\MyClass;
>  > >
>  > > $splited_class_name = explode( '\\', MyClass::class );
>  > > array_pop($splited_class_name);
>  > > echo $namespace = implode('\\', $splited_class_name );
>  > > ```
>  > >
>  > > Other option is:
>  > >
>  > > ```
>  > > namespace MyProject\MyHelpers;
>  > >
>  > > class MyClass {
>  > >   public const NAMESPACE = __NAMESPACE__;
>  > > }
>  > > ```
>  > >
>  > > However... :(
>  > >
>  > > ```
>  > > namespace MyProject\MyServices;
>  > >
>  > > class MyNewClass  extends MyClass{
>  > > }
>  > >
>  > > echo MyNewClass::NAMESPACE; //MyProject\MyHelpers
>  > > ```
>  > >
>  > > All of these examples are ways for getting a thing which PHP compiler
>  > > would resolver fast.
>  > >
>  > > It would be fantastic can code:
>  > >
>  > > MyClass::namespace or static::namespace( for example, in abstract
> classes )
>  > >
>  > > Don't you think the same ?
>  >
>  >
>  > Could you please share the use case(s) you have in mind for this?
>  >
>  > Regards,
>  > Nikita
>
> Hi, Nikita,
>
> Yes, of course. For example, loading views using TemplateViews pattern[1]:
>
> ```
> namespace MyProjects\Framework;
>
> abstract class TemplateView {
>private const VIEW_SUBPATH = '/views/';
>
>protected function includeView( string $viewName ) {
> $filePath = str_replace('\\', '/', static::namespace ).
> self::VIEW_SUBPATH;
> $fileName =$filePath.$viewName.'.tpl';
>
> if( file_exists($fileName) ) {
> return include $fileName;
> }
>
> error_log("Not found view[$viewName] in path $filePath"  };
>}
> }
> ```
>
> ```
> namespace MyProject\CMS\Freelancer\Attachments;
>
> class Budget extends TemplateView {
>
>   public function __toString() {
>   $this->includeView('full_budget');
>   }
>
> }```
>
>
>
> Regards
> - P.S: Sorry, my mistake with subject.
>
> [1]:
> https://dzone.com/articles/practical-php-patterns/practical-php-patterns-9
> --
> Manuel Canga
>
> Zend Certified PHP Engineer
> Websites: https://manuelcanga.dev | https://trasweb.net
> Linkedin: https://es.linkedin.com/in/manuelcanga
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] class_name:namespace

[Manuel Canga]

  En jue, 25 feb 2021 21:41:40 +0100 Nikita Popov  
escribió 
 > On Thu, Feb 25, 2021 at 8:11 PM Manuel Canga  wrote:
 > 
 > > Hi internals,
 > >
 > > I would like to present a possible new RFC( "class_name:namespace" ) for
 > > your consideration.
 > >
 > > As you know, namespaces are very important nowdays. They are used in
 > > autoloaders, Frameworks, CMS, ...
 > >
 > > Maybe, you are used to code something similar to this:
 > >
 > > ```
 > > use MyProject\MyHelpers\MyClass;
 > >
 > > echo substr( MyClass::class, 0, strrpos( MyClass::class, '\\'));
 > > ```
 > >
 > > or perhaps:
 > >
 > > ```
 > > use MyProject\MyHelpers\MyClass;
 > >
 > > $splited_class_name = explode( '\\', MyClass::class );
 > > array_pop($splited_class_name);
 > > echo $namespace = implode('\\', $splited_class_name );
 > > ```
 > >
 > > Other option is:
 > >
 > > ```
 > > namespace MyProject\MyHelpers;
 > >
 > > class MyClass {
 > >   public const NAMESPACE = __NAMESPACE__;
 > > }
 > > ```
 > >
 > > However... :(
 > >
 > > ```
 > > namespace MyProject\MyServices;
 > >
 > > class MyNewClass  extends MyClass{
 > > }
 > >
 > > echo MyNewClass::NAMESPACE; //MyProject\MyHelpers
 > > ```
 > >
 > > All of these examples are ways for getting a thing which PHP compiler
 > > would resolver fast.
 > >
 > > It would be fantastic can code:
 > >
 > > MyClass::namespace or static::namespace( for example, in abstract classes )
 > >
 > > Don't you think the same ?
 > 
 > 
 > Could you please share the use case(s) you have in mind for this?
 > 
 > Regards,
 > Nikita
 
Hi, Nikita,

Yes, of course. For example, loading views using TemplateViews pattern[1]: 

```
namespace MyProjects\Framework;

abstract class TemplateView {
   private const VIEW_SUBPATH = '/views/';

   protected function includeView( string $viewName ) {
$filePath = str_replace('\\', '/', static::namespace ).  
self::VIEW_SUBPATH;
$fileName =$filePath.$viewName.'.tpl';

if( file_exists($fileName) ) {
return include $fileName;
}

error_log("Not found view[$viewName] in path $filePath"  };
   }
}
```

```
namespace MyProject\CMS\Freelancer\Attachments;

class Budget extends TemplateView {
 
  public function __toString() {
  $this->includeView('full_budget');
  }

}```



Regards
- P.S: Sorry, my mistake with subject. 

[1]: https://dzone.com/articles/practical-php-patterns/practical-php-patterns-9
--
Manuel Canga

Zend Certified PHP Engineer 
Websites: https://manuelcanga.dev | https://trasweb.net
Linkedin: https://es.linkedin.com/in/manuelcanga

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

Re: [PHP-DEV] [RFC] Static variables in inherited methods

[Glash Gnome]

I can understand that some people coming from C++, Java may be shocked by
the behavior of a static variable in a static function.
And the need to improve things.

Maybe can you add *virtual static* keywords as a replacement for old
behavior in your RFC 
. You would satisfy me.

class A {
static function Counter() {
static $count = 0;
virtual static $i = 1;
return [++$count, $i++];
}
}
class B extends A {}

var_dump(A::Counter()); // array(int(1), int(1))
var_dump(A::Counter()); // array(int(2), int(2))
var_dump(B::Counter()); // array(int(3), int(1))
var_dump(B::Counter()); // array(int(4), int(2))

A::Counter::$count = 665; // Great Feature

A::Counter::$i = 0; //Initialize

B::Counter::$i = 0; //Reset


In C Poo we could get :

/*header*/
typedef struct _A {// Instance class A
} A;
typedef struct _AClass {// vtable class A

  int counter_i;// php: virtual static $i

  void (*counter)(void);// php: public static function counter(){}

} AClass;

typedef struct _B {// Instance class B  A parent_instance;
} B;
typedef struct _BClass {// vtable class B  AClass parent_class;// B
contains its own virtual static variable $i
} BClass;

/*source*/

int A_counter_count = 0;// What did you expect ?
//...

A_counter_count = 665;// php: A::Counter::$count=665;

A_class_entity.i = 0;// php: A::Counter::$i=0;

B_class_entity.i = 0;// php: B::Counter::$i=0;



Best regards,

Serge




Le mar. 23 févr. 2021 à 15:02, Nikita Popov  a écrit :

> Hi internals,
>
> While looking into various issues related to static variable handling, I've
> become increasingly convinced that our handling of static variables in
> inherited methods is outright buggy. However, it's also long-standing
> behavior, so I've put up an RFC:
>
> https://wiki.php.net/rfc/static_variable_inheritance
>
> Regards,
> Nikita
>

Re: [PHP-DEV] [RFC] class_name:namespace

[Nikita Popov]

On Thu, Feb 25, 2021 at 8:11 PM Manuel Canga  wrote:

> Hi internals,
>
> I would like to present a possible new RFC( "class_name:namespace" ) for
> your consideration.
>
> As you know, namespaces are very important nowdays. They are used in
> autoloaders, Frameworks, CMS, ...
>
> Maybe, you are used to code something similar to this:
>
> ```
> use MyProject\MyHelpers\MyClass;
>
> echo substr( MyClass::class, 0, strrpos( MyClass::class, '\\'));
> ```
>
> or perhaps:
>
> ```
> use MyProject\MyHelpers\MyClass;
>
> $splited_class_name = explode( '\\', MyClass::class );
> array_pop($splited_class_name);
> echo $namespace = implode('\\', $splited_class_name );
> ```
>
> Other option is:
>
> ```
> namespace MyProject\MyHelpers;
>
> class MyClass {
>   public const NAMESPACE = __NAMESPACE__;
> }
> ```
>
> However... :(
>
> ```
> namespace MyProject\MyServices;
>
> class MyNewClass  extends MyClass{
> }
>
> echo MyNewClass::NAMESPACE; //MyProject\MyHelpers
> ```
>
> All of these examples are ways for getting a thing which PHP compiler
> would resolver fast.
>
> It would be fantastic can code:
>
> MyClass::namespace or static::namespace( for example, in abstract classes )
>
> Don't you think the same ?


Could you please share the use case(s) you have in mind for this?

Regards,
Nikita

[PHP-DEV] [RFC] Namespaced in bundled extensions

[Nikita Popov]

Hi internals,

The question of namespaces in the stdlib has been coming up a lot recently,
so I'd like to present my own stab at resolving this question:

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

Relative to a number of previous (declined) proposals, the main difference
is that I do not propose a top-level "PHP\" vendor namespace, and instead
recommend the use of "ExtName\", in line with existing practice for
extensions. I believe this addresses the primary concern with previous
proposals.

Regards,
Nikita

[PHP-DEV] [RFC] class_name:namespace

[Manuel Canga]

Hi internals,

I would like to present a possible new RFC( "class_name:namespace" ) for your 
consideration.

As you know, namespaces are very important nowdays. They are used in 
autoloaders, Frameworks, CMS, ... 

Maybe, you are used to code something similar to this:

```
use MyProject\MyHelpers\MyClass;

echo substr( MyClass::class, 0, strrpos( MyClass::class, '\\'));
```

or perhaps:

```
use MyProject\MyHelpers\MyClass;

$splited_class_name = explode( '\\', MyClass::class );
array_pop($splited_class_name);
echo $namespace = implode('\\', $splited_class_name );
```

Other option is:

```
namespace MyProject\MyHelpers;

class MyClass {
  public const NAMESPACE = __NAMESPACE__;
}
```

However... :(

```
namespace MyProject\MyServices;

class MyNewClass  extends MyClass{
}

echo MyNewClass::NAMESPACE; //MyProject\MyHelpers
```

All of these examples are ways for getting a thing which PHP compiler would 
resolver fast.

It would be fantastic can code:

MyClass::namespace or static::namespace( for example, in abstract classes )

Don't you think the same ?

Regards
--
Manuel Canga

Zend Certified PHP Engineer 
Websites: https://manuelcanga.dev | https://trasweb.net
Linkedin: https://es.linkedin.com/in/manuelcanga

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

Re: [PHP-DEV] [RFC] Static variables in inherited methods

[Nikita Popov]

On Thu, Feb 25, 2021 at 4:46 PM Glash Gnome  wrote:

> Dears,
>
> Let me briefly introduce myself. I have been a C coder for 19 years,
> including 12 years with php. And I also do Java, C++, Javascript... from
> time to time.
>
> Nikita, What would the equivalent of this code be after RFC modification?
>
> 
> class CXPLeaks
> {
> static function refCount() {
> static $i=0;
> $i++;
> }
> function refCountByClass() {
> static $i=0;
> $i++;
> }
> function __construct() {
> self::refCount();
> self::refCountByClass();
> }
> }
>
>
> Declaring a static variable in a class or in a function, in terms of
> speed/work it's the same.
> For me, this is not a bug. It's a misunderstanding
> For me, who codes in C, the current behavior is intuitive.
> For me, there is no language as agile as PHP.
>
> Best regards,
> Serge
>

Your example does not contain inheritance, so the RFC has no impact on it.
As such, I do not understand your question.

Nikita


> Le mar. 23 févr. 2021 à 15:02, Nikita Popov  a
> écrit :
>
>> Hi internals,
>>
>> While looking into various issues related to static variable handling,
>> I've
>> become increasingly convinced that our handling of static variables in
>> inherited methods is outright buggy. However, it's also long-standing
>> behavior, so I've put up an RFC:
>>
>> https://wiki.php.net/rfc/static_variable_inheritance
>>
>> Regards,
>> Nikita
>>
>

Re: [PHP-DEV] [RFC] Static variables in inherited methods

[Glash Gnome]

Dears,

Let me briefly introduce myself. I have been a C coder for 19 years,
including 12 years with php. And I also do Java, C++, Javascript... from
time to time.

Nikita, What would the equivalent of this code be after RFC modification?

 a écrit :

> Hi internals,
>
> While looking into various issues related to static variable handling, I've
> become increasingly convinced that our handling of static variables in
> inherited methods is outright buggy. However, it's also long-standing
> behavior, so I've put up an RFC:
>
> https://wiki.php.net/rfc/static_variable_inheritance
>
> Regards,
> Nikita
>

Re: [PHP-DEV] [VOTE] fsync function

[David Gebler]

Thanks Marco, objection understood. I think Nikita's already said what I
would say, from my view I can only reiterate I felt it was more appropriate
to keep the behaviour consistent with how similar stream ops work.

Regards
David Gebler

On Thu, 25 Feb 2021, 13:38 Marco Pivetta,  wrote:

> Het Nikita,
>
> On Thu, Feb 25, 2021 at 1:04 PM Nikita Popov  wrote:
>
>>
>> Throwing a warning in such a case is consistent with how functions for
>> other optional stream operations work.
>>
>
> I understand that, and I'm OK with being **against** it.
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>

Re: [PHP-DEV] [VOTE] fsync function

[Marco Pivetta]

Het Nikita,

On Thu, Feb 25, 2021 at 1:04 PM Nikita Popov  wrote:

>
> Throwing a warning in such a case is consistent with how functions for
> other optional stream operations work.
>

I understand that, and I'm OK with being **against** it.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] RFC: Error backtraces

[Nikita Popov]

On Wed, Jun 3, 2020 at 9:04 AM Nikita Popov  wrote:

> On Tue, Jun 2, 2020 at 10:57 PM Max Semenik  wrote:
>
>> On Sun, May 31, 2020 at 4:47 PM Nikita Popov 
>> wrote:
>>
>> > I'm concerned about the performance implications of this change.
>> Backtrace
>> > gathering is quite expensive and doing this for every diagnostic will
>> have
>> > a large performance impact if there are many of them. This is okay if
>> your
>> > code is intended to be diagnostics clean, but unfortunately this is not
>> a
>> > given. If you generate 10k deprecation warnings during a request, you're
>> > definitely going to feel those backtraces.
>> >
>>
>> INI setting should take care of this. If your code is crap, don't flip it
>> on.
>>
>
> There's a couple of problems with this line of argumentation:
>
> First, even if the code is crap, wouldn't it still want to have stack
> traces for fatal errors? Why should crap code be denied stack traces? Isn't
> that the code that needs them most? If the code weren't crap it wouldn't be
> causing fatal errors anyway ;)
>
> Second, PHP has plenty of functions (especially I/O functions) where
> ignoring notices and warnings is a requirement. You are not interested in
> back traces for errors your ignore. Keep in mind that error_get_last() data
> is populated independently of whether errors are suppressed or not.
>
> Similarly, if your code promoted all warnings to exceptions using a custom
> error handler, then you'll perform a duplicate backtrace calculation, first
> when the warning is originally through, and then again if you construct the
> exception. (This is less bad than other cases, because it's "just" twice as
> slow.)
>
> Finally, even if we completely disregard the question of performance, back
> traces are very noisy. You get one fatal error per request, but you might
> easily get 1k warnings if something happens to trigger in a loop. With back
> traces, those 1k warnings will be 100k lines.
>
> I'm not sure if limiting it to just fatals is the best choice, but I do
> think that this needs a bit more control. And limited to just backtraces
> for fatals, I think this functionality should be enabled by default.
>
> This might also want to integrate with the zend.exception_ignore_args
> option (or, because that one is exception-specific, a renamed option that
> does the same thing). We will want to disable argument gathering in a
> default production configuration, because the arguments may contain
> sensitive data that must not appear inside log files.
>
> Regards,
> Nikita
>

To put my feedback into more actionable form: Rather than adding an ini
setting that enables error backtraces for all diagnostics, I'd make it a
mask of error types for which a backtrace should be captured, and default
it to fatal errors only. So error_reporting=E_ALL,
error_backtrace=E_ERROR|E_CORE_ERROR|E_COMPILE_ERROR|E_USER_ERROR|E_RECOVERABLE_ERROR|E_PARSE.
It might be handy to expose the internal E_FATAL_ERRORS constant we have
for that.

I think this should give a very sensible default behavior, and people who
want to capture backtraces for all errors still have an option to do so.

Finally, I'm wondering if the backtrace in error_get_last() shouldn't be in
array form, rather than string form.

Regards,
Nikita

[PHP-DEV] timelib inefficiency

[Dmitry Stogov]

Hi Derick,

Please take a look

https://github.com/php/php-src/blob/51914610ab8bf75d87e5cdec15bd1b38de7907c5/ext/date/lib/parse_date.re#L684-L700

This code is enormously inefficient. For a single abbr_search(), it calls
timelib_strcasecmp() more than 1000 times (complete linear search in a huge
almost ordered array, with repeatable and redundant lowercasing). 11 calls
to abbr_search() per request in the Symfony Demo application (
https://github.com/symfony/demo) eat 2% of overall CPU time.

I see some other inefficient patterns in timelib. e.g. API design that
leads to many useless heap allocations/deallocations; calloc() followed by
memcpy(), etc

Thanks. Dmitry.

Re: [PHP-DEV] [VOTE] fsync function

[Christoph M. Becker]

On 25.02.2021 at 13:03, Nikita Popov wrote:

> On Thu, Feb 25, 2021 at 1:01 PM Christoph M. Becker 
> wrote:
>
>> On 25.02.2021 at 12:43, Marco Pivetta wrote:
>>> Hey David,
>>> 
>>>
>>>
>>> On Wed, Feb 24, 2021 at 6:15 PM David Gebler 
>> wrote:
>>>
 Voting is now open for 2 weeks on
>> https://wiki.php.net/rfc/fsync_function

 Regards,
 David Gebler

 On Tue, Feb 23, 2021 at 5:15 PM David Gebler 
 wrote:

> Hi internals,
> As there appear to be no objections or concerns, I intend to open
>> voting
> on https://wiki.php.net/rfc/fsync_function tomorrow and voting will
> remain open for two weeks.
>
> The RFC and its implementation
>
> - Adds functions fsync() and fdatasync() for plain file streams on Unix
> systems.
> - Adds function fsync() on Windows with fdatasync() available as an
>> alias
>
> PR ref https://github.com/php/php-src/pull/6650

>>>
>>> Just clarifying on my "NO" vote: I'm opposed to having more E_WARNING
>>> raised by the language.
>>>
>>> We have better approaches for that:
>>>
>>>  * exceptions
>>>  * union types
>>>  * Maybe/Either types
>>>
>>> I don't see a reason to introduce a warning here, and it makes the
>> function
>>> unusable unless some poor soul implements a library that gets rid of the
>>> warning.
>>
>> Note that *this* warning is never supposed to occur in production,
>> because it is a programming error to pass a wrong resource *type*.
>> Rasing a warning for wrong resource types is standard behavior of
>> zend_fetch_resource() (unless no resource type name is passed).  I don't
>> see why these new functions should use a non standard mechanism.
>>
>> Of course, in the long run resources should go away, which would resolve
>> this issue for these functions as well.
>>
>
> A wrong resource type will throw a TypeError as usual -- the warning is
> thrown if the resource is of the correct type (stream), but does not
> support sync operations. For example, if you tried to do an fsync on an
> http:// stream.

Ah, thanks for the correction!  (I'm doing too much PHP 7, still.)

> Throwing a warning in such a case is consistent with how functions for
> other optional stream operations work.

ACK.

--
Christoph

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

Re: [PHP-DEV] [VOTE] fsync function

[Nikita Popov]

On Thu, Feb 25, 2021 at 1:01 PM Christoph M. Becker 
wrote:

> On 25.02.2021 at 12:43, Marco Pivetta wrote:
> > Hey David,
> > 
> >
> >
> > On Wed, Feb 24, 2021 at 6:15 PM David Gebler 
> wrote:
> >
> >> Voting is now open for 2 weeks on
> https://wiki.php.net/rfc/fsync_function
> >>
> >> Regards,
> >> David Gebler
> >>
> >> On Tue, Feb 23, 2021 at 5:15 PM David Gebler 
> >> wrote:
> >>
> >>> Hi internals,
> >>> As there appear to be no objections or concerns, I intend to open
> voting
> >>> on https://wiki.php.net/rfc/fsync_function tomorrow and voting will
> >>> remain open for two weeks.
> >>>
> >>> The RFC and its implementation
> >>>
> >>> - Adds functions fsync() and fdatasync() for plain file streams on Unix
> >>> systems.
> >>> - Adds function fsync() on Windows with fdatasync() available as an
> alias
> >>>
> >>> PR ref https://github.com/php/php-src/pull/6650
> >>
> >
> > Just clarifying on my "NO" vote: I'm opposed to having more E_WARNING
> > raised by the language.
> >
> > We have better approaches for that:
> >
> >  * exceptions
> >  * union types
> >  * Maybe/Either types
> >
> > I don't see a reason to introduce a warning here, and it makes the
> function
> > unusable unless some poor soul implements a library that gets rid of the
> > warning.
>
> Note that *this* warning is never supposed to occur in production,
> because it is a programming error to pass a wrong resource *type*.
> Rasing a warning for wrong resource types is standard behavior of
> zend_fetch_resource() (unless no resource type name is passed).  I don't
> see why these new functions should use a non standard mechanism.
>
> Of course, in the long run resources should go away, which would resolve
> this issue for these functions as well.
>

A wrong resource type will throw a TypeError as usual -- the warning is
thrown if the resource is of the correct type (stream), but does not
support sync operations. For example, if you tried to do an fsync on an
http:// stream.

Throwing a warning in such a case is consistent with how functions for
other optional stream operations work.

Regards,
Nikita

Re: [PHP-DEV] [VOTE] fsync function

[Christoph M. Becker]

On 25.02.2021 at 12:43, Marco Pivetta wrote:
> Hey David,
> 
>
>
> On Wed, Feb 24, 2021 at 6:15 PM David Gebler  wrote:
>
>> Voting is now open for 2 weeks on https://wiki.php.net/rfc/fsync_function
>>
>> Regards,
>> David Gebler
>>
>> On Tue, Feb 23, 2021 at 5:15 PM David Gebler 
>> wrote:
>>
>>> Hi internals,
>>> As there appear to be no objections or concerns, I intend to open voting
>>> on https://wiki.php.net/rfc/fsync_function tomorrow and voting will
>>> remain open for two weeks.
>>>
>>> The RFC and its implementation
>>>
>>> - Adds functions fsync() and fdatasync() for plain file streams on Unix
>>> systems.
>>> - Adds function fsync() on Windows with fdatasync() available as an alias
>>>
>>> PR ref https://github.com/php/php-src/pull/6650
>>
>
> Just clarifying on my "NO" vote: I'm opposed to having more E_WARNING
> raised by the language.
>
> We have better approaches for that:
>
>  * exceptions
>  * union types
>  * Maybe/Either types
>
> I don't see a reason to introduce a warning here, and it makes the function
> unusable unless some poor soul implements a library that gets rid of the
> warning.

Note that *this* warning is never supposed to occur in production,
because it is a programming error to pass a wrong resource *type*.
Rasing a warning for wrong resource types is standard behavior of
zend_fetch_resource() (unless no resource type name is passed).  I don't
see why these new functions should use a non standard mechanism.

Of course, in the long run resources should go away, which would resolve
this issue for these functions as well.

--
Christoph

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

Re: [PHP-DEV] [VOTE] fsync function

[Marco Pivetta]

Hey David,



On Wed, Feb 24, 2021 at 6:15 PM David Gebler  wrote:

> Voting is now open for 2 weeks on https://wiki.php.net/rfc/fsync_function
>
> Regards,
> David Gebler
>
> On Tue, Feb 23, 2021 at 5:15 PM David Gebler 
> wrote:
>
> > Hi internals,
> > As there appear to be no objections or concerns, I intend to open voting
> > on https://wiki.php.net/rfc/fsync_function tomorrow and voting will
> > remain open for two weeks.
> >
> > The RFC and its implementation
> >
> > - Adds functions fsync() and fdatasync() for plain file streams on Unix
> > systems.
> > - Adds function fsync() on Windows with fdatasync() available as an alias
> >
> > PR ref https://github.com/php/php-src/pull/6650
>

Just clarifying on my "NO" vote: I'm opposed to having more E_WARNING
raised by the language.

We have better approaches for that:

 * exceptions
 * union types
 * Maybe/Either types

I don't see a reason to introduce a warning here, and it makes the function
unusable unless some poor soul implements a library that gets rid of the
warning.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] Inline conditional that returns null if falsy

[Kingsquare.nl - Robin Speekenbrink]

Op do 25 feb. 2021 om 09:55 schreef Rowan Tommins :

> On 24/02/2021 04:26, Mike Schinkel wrote:
> > Repeating code similar to that from the message sent by David Rodrigues
> you can see that eliminating the ": null" is less noisy:
> >
> >  ...
> >  ...
>
>
Also just to have a somewhat apples to apples (working) comparission, it
would read something like:

...
...
or one of the other possibilities (print / ">...

this atleast is consistent, doesn't provide yet another way of doing the
same thing and even allows for easier refactoring (i.e. if the falsy
situation has to change from '' to 'offline')

to summarize from my 2cent userland developer standpoint: Hope this doesn't
make this in... (or is at least strongly discouraged)

Thanks,
Robin

Re: [PHP-DEV] [RFC] Static variables in inherited methods

[Nikita Popov]

On Thu, Feb 25, 2021 at 9:48 AM Aleksander Machniak  wrote:

> On 23.02.2021 15:01, Nikita Popov wrote:
> > While looking into various issues related to static variable handling,
> I've
> > become increasingly convinced that our handling of static variables in
> > inherited methods is outright buggy. However, it's also long-standing
> > behavior, so I've put up an RFC:
> >
> > https://wiki.php.net/rfc/static_variable_inheritance
>
> What about non-static methods with static vars inside? I think it should
> be mentioned in the RFC, that it does not matter. Or the examples should
> not use a static method, for clarity.
>

Thanks for the suggestion. I've explicitly mentioned that the behavior is
independent of whether the method is static, and added an example.


> I'm not sure I would agree with the Traits behavior being consistent.


Yes, this part is not so clear cut. I think that intuitively, this is the
correct behavior because it makes static variables work the same way as
static properties. An additional consideration is that it's possible to use
trait methods multiple times in the same class:

Re: [PHP-DEV] Inline conditional that returns null if falsy

[Rowan Tommins]

On 24/02/2021 04:26, Mike Schinkel wrote:

Repeating code similar to that from the message sent by David Rodrigues you can see that 
eliminating the ": null" is less noisy:

 ...
 ...



That's an interesting use case. Of course, the logical default there is 
actually '' (empty string) rather than null, since "echo null;" doesn't 
actually make much sense, but null works under current type juggling rules.


Then again, perhaps this is a good example of why PHP *isn't* the best 
choice any more if you want a templating language. Twig, for instance, 
has exactly this facility 
[https://twig.symfony.com/doc/3.x/templates.html#other-operators]:


{{  foo  ?  'yes'  :  'no'  }}
{{  foo  ?:  'no'  }}is the same as {{  foo  ?  foo  :  'no'  }}
{{  foo  ?  'yes'  }}is the same as {{  foo  ?  'yes'  :  ''  }}

If we wanted to close the gap between Twig and plain PHP for templating, 
this might be somewhere on the list, but after more significant features 
like automatic escaping, filter / pipe syntax, etc.



Regards,

--
Rowan Tommins
[IMSoP]

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

Re: [PHP-DEV] [RFC] Static variables in inherited methods

[Aleksander Machniak]

On 23.02.2021 15:01, Nikita Popov wrote:
> While looking into various issues related to static variable handling, I've
> become increasingly convinced that our handling of static variables in
> inherited methods is outright buggy. However, it's also long-standing
> behavior, so I've put up an RFC:
> 
> https://wiki.php.net/rfc/static_variable_inheritance

What about non-static methods with static vars inside? I think it should
be mentioned in the RFC, that it does not matter. Or the examples should
not use a static method, for clarity.

I'm not sure I would agree with the Traits behavior being consistent.

-- 
Aleksander Machniak
Kolab Groupware Developer[https://kolab.org]
Roundcube Webmail Developer  [https://roundcube.net]

PGP: 19359DC1 # Blog: https://kolabian.wordpress.com

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

Re: [PHP-DEV] [RFC] mysqli bind in execute

[Claude Pache]

> Le 11 févr. 2021 à 20:43, Kamil Tekiela  a écrit :
> 
> Hi internals,
> 
> I am proposing the next change to improve mysqli extension. This RFC's goal
> is to add a new optional parameter to mysqli_stmt:execute() that will take
> an array of parameters.
> 
> The RFC is located at https://wiki.php.net/rfc/mysqli_bind_in_execute
> 
> I'd be happy to hear your comments.
> 
> Kind Regards,
> Kamil Tekiela

Hi,

In the paragraph “Difference between PDO and mysqli”, you propose:

“Array keys are completely ignored. mysqli doesn't have emulated prepares nor 
does it have named parameters.”

Instead of ignoring the keys, I think it is better to throw a TypeError when 
the provided array is not a “list” in the sense of `array_is_list()` introduced 
[in a recent RFC] (https://wiki.php.net/rfc/is_list). The reasons are:

* provide the user with useful feedback when they are attempting to do 
something dubious and/or their intent is ambiguous;
* be forward compatible with possible future addition of named parameters;
* reduce the difference with PDO for input that are accepted in both mysqli and 
PDO.

—Claude

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

Re: [PHP-DEV] [RFC] Static variables in inherited methods

[Dmitry Stogov]

+1

On Tue, Feb 23, 2021 at 5:02 PM Nikita Popov  wrote:

> Hi internals,
>
> While looking into various issues related to static variable handling, I've
> become increasingly convinced that our handling of static variables in
> inherited methods is outright buggy. However, it's also long-standing
> behavior, so I've put up an RFC:
>
> https://wiki.php.net/rfc/static_variable_inheritance
>
> Regards,
> Nikita
>