Re: [PHP-DEV] [RFC] Alternative syntax for Nowdoc.
En mié, 30 jun 2021 14:29:40 +0200 G. P. B. escribió > Ignoring the fact that this proposal is way past the cutoff date to be able > to make it into PHP 8.1 due to how the RFC process works,it seems that this > feature just came into your mind and you decided to send it onto the list > without considering its ramifications.Userland contribution and opinions on > new features (or other internal discussion) is valuable but oughts to > consider all the ramifications, good and bad, and how it affects the > language as a whole. I say this because I didn't do this when I started > contributing on this list and it made for less than stellar discussions. Hi, George, I am not an expert in developing programming languages. However, I don't agree with that. When Dennis Ritchie and Brian Kernighan developed C. They didn't think in avoid pointers because of they thought what they could be dangerous. Surely when someone invented air planes, he didn't think of risks but opportunities It was my fault. I thought that someone here would propose an idea and if this was useful, then everyone would find the best way to put it into code. With last Rowan email, I understood that this purpose is useless. However, if it had been useful, I had expected answers like: "hey, Manuel, ``` is dangerous, why don't use other syntax like ... ? or "Manuel, why don't use this for heredoc ? In one word: Synergy. Why should this be done?. Because someone can read my purpose and can modify to something better, maybe a great change to the language. I think so. Regards, Manuel Canga -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Alternative syntax for Nowdoc.
En mié, 30 jun 2021 11:16:24 +0200 Lynn escribió > > I'd expect a lot of markdown issues when trying to write examples using > backticks. While such a thing might not be blocking for a nice language > feature, it will surely impact the tooling in the ecosystem for > documentation. I already run into issues with single line code examples in > Discord because it gets messy real fast. Sure it's just an annoyance, but I > would like to suggest avoiding it if we can. > ``` > `const something = `foo`;` > ``` Hi, Lynn. My intention wasn't a closed purpose. Maybe ``` is not a good syntax, In this case, other can be found. Regards Manuel Canga -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Alternative syntax for Nowdoc.
En mié, 30 jun 2021 11:03:32 +0200 Guilliam Xavier escribió > Hi, Hi Guilliam > Maybe other syntax could be used, but I don't know which. In javascript > > only a backtick is used: > > https://developers.google.com/web/updates/2015/01/ES6-Template-Strings . > > But in PHP this is used as eval. > > > > Just a precision, because you keep referring to it as "eval", which makes > me "tick" (haha): `$cmd` (i.e. $cmd wrapped in a pair of backticks) is the > same as shell_exec($cmd), not eval($cmd). Yes, you're right. > (BTW, one of JS "template strings" main selling points is string > substitution / variable interpolation, which is explicitly *not* wanted > with nowdoc [VS heredoc].) Yes, I mean that in JS is used some similar (although as you say with variables). I would prefer to use this "feature" with nowdoc. Normally, strings with variables are moved to views, while large literals (like queries) are added inline. > As for the proposal, overall I agree with Rowan -- well, that would not be > exactly like single quotes (regarding [not] escaping them), but still "yet > another way" to write a nowdoc string literal. I see this purpose as a simplification of Nowdocs. Just like `[]` with `array()`. > PS: "amusingly", the code samples are hard to understand after rendered on > https://externals.io/message/115213 ups!, I'm sorry...but, look at: https://externals.io/message/115213#115222 Markdown is not broken here due to ``` of code. Regards, Manuel Canga -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Alternative syntax for Nowdoc.
En mar, 29 jun 2021 21:33:19 +0200 Michał Marcin Brzuchalski escribió > Hi Manuel, > I think a Markdown document including PHP code snippet with above examples > could cause issues while parsing. > I can imagine parsers don't expect end-of-snippet tag "```" being not an > end tag actually. > > Cheers, > Michał Marcin Brzuchalski Hi, Michal, You can escape backticks using a different number of backticks as a wrapper. Examples: 1. ``There is a literal backtick (`) here.`` We're using two backstick as wrapper of one backtick. 2. Using Rowan example: php $markdown=``` PHP has lots of ways to write strings: ``` $example = 'hello'; $example = "hello"; $example = <<https://github.com/manuelcanga/RFC/blob/master/README.md This works due to use four backticks as wrapper of three backticks. Although these examples work generally, with some Markdown parser can that these doesn't work. Maybe other syntax could be used, but I don't know which. In javascript only a backtick is used: https://developers.google.com/web/updates/2015/01/ES6-Template-Strings . But in PHP this is used as eval. Regards, Manuel Canga -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Alternative syntax for Nowdoc.
En mar, 29 jun 2021 18:40:05 +0200 Rowan Tommins escribió > > The big advantage of heredoc and nowdoc syntax is that you can choose > the delimiter to be something that you know won't occur in the string. > For instance: > > $markdown = <<<'MD' > PHP has lots of ways to write strings: > ``` > $example = 'hello'; > $example = "hello"; > $example = << hello > EXAMPLE; > $example = << hello > EXAMPLE; > ``` > MD; > > > Unless I'm missing something, your proposed syntax would just be a *more > verbose* way of writing single quotes. Hi, Rowan, Basically, you're right. This would be a Heredoc variant of writing text without worrying about quotes (singles or doubles). Something like: $quote =```"Sometimes it's better to leave something alone, to pause, and that's very true of programming." - Joyce Wheeler```; Regards Manuel Canga -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [RFC] Alternative syntax for Nowdoc.
Hi, folks, here again with a new purpose: ``` as alternative to Nowdoc syntax. Currently, Nowdoc syntax is very "verbose": $string =<<<'CODE' Link: '%s' CODE; Why doesn't something like this?: $string =``` Link: '%s' ```; even as well: $string =```Link: '%s'```; I see a caveat: this is very similar to `eval` syntax. However, this syntax is more similar to Markdown syntax. What do you think ? Regards Manuel Canga -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] class_name:namespace
En vie, 26 feb 2021 14:40:03 +0100 Guilliam Xavier
escribió
> Hi,
>
> For that example (and most others), you're manipulating file paths anyway,
> and assume that the FQCN is at least one level deep (i.e. not top-level),
> so you may as well start with `$p = str_replace('\\', \DIRECTORY_SEPARATOR,
> $fqcn);` then use `dirname($p)` and/or `basename($p)`.
>
> Now for the (rarer) cases when you actually want the namespace name and/or
> the unqualified class name, I agree that the current state is not ideal.
> To my knowledge, you have the choice between "magic" string manipulation
> (various ways) and "semantic" reflection (e.g. `$r = new
> \ReflectionClass($fqcn);` -- which may try to autoload the class and throws
> if it doesn't actually exist -- then use `$r->getNamespaceName()` and/or
> `$r->getShortName()`).
> Like `str_contains()` was introduced as a "shorthand" for `false !==
> strpos()`, something like `get_namespace_name()` and/or `get_short_name()`
> (or other namings) might be worth considering.
>
> Regards,
>
> --
> Guilliam Xavier
>
Hi, Guilliam,
I think so.
I don't need `dirname` function in order to extract path from a file name.
However, `dirname` exists in order to simplify a "common" task in a semantic
way.
Why don't the same with namespaces ?. There is nothing specific in order to
work with namespaces only they can be used.
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] class_name:namespace
En vie, 26 feb 2021 13:25:30 +0100 Michał Marcin Brzuchalski escribió > Personally, none of the above examples is convincing bc I'd implement them > using a fixed class names map to avoid loading untrusted classes. > Any kind of helper class is something I'd personally not use to avoid > static coupling of code and hacks while writing unit tests over > services that could be injected by IoC. > Full class names (whether they're aliased or used in use clause) have more > benefit over class name string operations as they're easy for any renaming > which most of the IDE's these days can handle. > IMO introducing namespace magic constant has relatively narrow use and I'd > probably vote NO on this. > > Cheers, > Michał Marcin Brzuchalski I see... I agree with you, however one thing is as we would like PHP will be used and other is as it is used. - https://stackoverflow.com/questions/24798621/how-can-i-get-the-full-namespace-of-a-class-without-creating-an-instance-of-it - https://stackoverflow.com/questions/13932289/get-php-class-namespace-dynamically - https://stackoverflow.com/questions/43630010/php-how-can-get-the-namespace-of-class-method-parameter - https://stackoverflow.com/questions/28182783/get-namespace-of-an-object-using-an-abstract-class-or-trait/28182941 - ... It's like `eval`, it is dangerous, maybe it never should be used. However, sometimes is useful. do we avoid "dangerous" features ? or do we think people are professional( I don't know if this is used in English equal Spanish ) and they know using it when is needed ? I think that if something is common and normally useful, PHP should implement that. For example, `::namespace` or `get_namespace()` 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] class_name:namespace
>
> Hi,
>
> Note that (typos aside) this example cannot work as-is, because
> `static::namespace` (like `static::class`) cannot be resolved at
> compile-time, and therefore cannot be assigned to a constant.
>
> More generally, in the various examples you provided, the namespace is not
> resolved at compile-time: it is either static::namespace or
> $fullClassName::namespace where $fullClassName is provided by the
> autoloader. As such, instead of a ::namespace magic class constant, it might
> be more appropriate to have a helper function, say `get_namespace()`, which
> has the additional benefit to work not only on (fully qualified) class
> names, but also on function, constant and namespace names (in the case of
> namespace names, it would return the name of the parent namespace).
>
> —Claude
>
>
Hi, Claude,
That's sound great. Something like dirname[1] but with namespaces.
But...in that case, I also add a new function like basename but with
namespaces. Example autoload for WordPress :
```
function autoload( $ful_class_name ) {
$class_ path = str_replace('\\', '/', get_namespace( $ful_class_name ) );
$class_name = strtolower( get_base_namespace( $ful_class_name ) );
require "{$class_path}/class-{$class_name}.php";
}```
[1]: https://www.php.net/manual/es/function.dirname.php
[2]: https://www.php.net/manual/es/function.basename.php
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] class_name:namespace
En vie, 26 feb 2021 11:08:33 +0100 Glash Gnome
escribió
> Hola Manuel,
> "Don't you think the same ?"
> I was thinking of something more generi, maybe :
> ```
> namespace Foo\Bar;
>
> class A {
> static function getNamespace() {
> static $ns = __NAMESPACE__;//
> https://wiki.php.net/rfc/static_variable_inheritance
> return $ns;
> }
> }
>
> namespace My\Baz;
> class B extends \Foo\Bar\A { }
>
> echo \Foo\Bar\A::getNamespace(), PHP_EOL;// Foo\Bar
> echo \My\Baz\B::getNamespace(), PHP_EOL;// Foo\Bar Ho no !```
> Unfortunately it doesn't work ...
>
> Best regards,Serge
>
Hola, Glash,
I sometimes use:
class Foo {
const NAMESPACE = __NAMESPACE__;
}
Foo::NAMESPACE;
However, this doesn't work:
class Bar extends Foo {
}
Bar::NAMESPACE; // == Foo::NAMESPACE
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] class_name:namespace
I'm Sorry, I feel a little nervous by writing here again after long time.
Replace '/' by '\' and PATH( HELPER_PATH | SERVICE_PATH ) by NAMESPACE(
HELPER_NAMESPACE | SERVICE_NAMESPACE ).
Sorry
En vie, 26 feb 2021 09:16:18 +0100 Manuel Canga
escribió
> Hello, another example with "factories method"[1]:
>
> ```php
> use MyProject\Framework;
>
> abstract class AbstractController {
> private const HELPER_PATH = static::namespace.'/Helpers';
> private const SERVICE_PATH = static::namespace.'/Services';
>
> public function instanceHelper( string $helperClass ) {
> $helperClassName = self::HELPER_PATH."/{$helperClass}";
>
>return new $helperClassName();
> }
>
>public function instanceService( string $serviceClass ) {
> $serviceClassName = self::SERVICE_PATH."/{$serviceClass}";
>
>return new $serviceClassName();
>}
> }
>
> use MyProject\MyModule;
>
> class Controller {
> public function __invoke() {
> //..
>$date = $this->instanceHelper('Date');
> //...
> }
>
> }
> ```
>
> [1]: https://en.wikipedia.org/wiki/Factory_method_pattern
>
> 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
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] class_name:namespace
Hello, another example with "factories method"[1]:
```php
use MyProject\Framework;
abstract class AbstractController {
private const HELPER_PATH = static::namespace.'/Helpers';
private const SERVICE_PATH = static::namespace.'/Services';
public function instanceHelper( string $helperClass ) {
$helperClassName = self::HELPER_PATH."/{$helperClass}";
return new $helperClassName();
}
public function instanceService( string $serviceClass ) {
$serviceClassName = self::SERVICE_PATH."/{$serviceClass}";
return new $serviceClassName();
}
}
use MyProject\MyModule;
class Controller {
public function __invoke() {
//..
$date = $this->instanceHelper('Date');
//...
}
}
```
[1]: https://en.wikipedia.org/wiki/Factory_method_pattern
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] class_name:namespace
--
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
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
[PHP-DEV] [RFC] class_name:namespace
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] Import of variables
Hi, Internals,
Thanks, Marco and also to Rowans, Josh, David and Tyson
I'll use IIFE in order to avoid global conflicts.
Regards
En lun, 10 ago 2020 02:16:06 +0200 Marco Pivetta
escribió
> Hey Manuel,
>
>
>
>
> On Sun, Aug 9, 2020, 11:02 Manuel Canga wrote:
>
> > Hi Internals,
> >
> > I'd like to open up a discussion around the implementation of a new
> > functionality: 'import of variables'.
> >
> > This functionality would allow to create a new 'use vars' keyword in
> > order to can use( or cannot use ) global variables in local scope( of
> > current file ).
> >
> > I think the best is a example:
> >
> > ```php
> > >
> > $a = 1;
> > $b = 2;
> > $c = 3;
> >
> > include __DIR__.'/without_import.php';
> > include __DIR__.'/all_import.php';
> > include __DIR__.'/none_import.php';
> > include __DIR__.'/some_vars.php';
> > include __DIR__.'/global_in_function.php';
> > ```
> >
> > ## without_import.php
> >
> > ```php
> > >
> > echo $a; //1
> > echo $b; //2
> > $c = 'any value'; //replace value in global var
> > ```
> >
> > ## all import.php
> >
> > ```php
> > >
> > use vars all;
> >
> > echo $a; //1
> > echo $b; //2
> > $c = 'other value'; //replace value in global var
> > ```
> >
> > ## none_import.php
> >
> > ```php
> > >
> > use vars none;
> >
> > echo $a; //Warning: undefined var $a
> > echo $b; //Warning: undefined var $b
> > $c = 'other value'; //assign value to local var
> > ```
> >
> >
> > ## some_vars.php
> >
> > ```php
> > >
> > use vars $a, $c, $d; //Warning: undefined var $d
> >
> > echo $a; //1
> > echo $b; //Warning: undefined var $b
> > $c = 'a value'; //replace value in global var
> > ```
> >
> > ## global_in_function.php
> >
> > ```php
> > >
> > use vars $a, $c;
> >
> >
> > function hello() {
> > global $a, $b, $c;
> >
> > echo $a; //1
> > echo $b; //null.
> > $c = 'end value'; //replace value in global var
> > }
> >
> > hello();
> > ```
> >
> >
> > In a project with a lot of global vars( like WordPress ) this
> > functionality avoids conflicts and easy replacements of values in main
> > global vars.
> >
>
> This looks like what IIFE do already (you can use them today):
>
> ```php
>
> require 'something/with/side/effects.php';
>
> (static function () use ($a, $b, & $c) : void {
> echo $a; //1
> echo $b; //Warning: undefined var $b
> $c = 'a value'; //replace value in global var
> })();
> ```
>
> You can use this right now, and it has the advantage of reporting any
> missing symbols right at the time at which the closure is declared.
>
> I tend to use IIFE all the time in procedural code, since they prevent
> leaking state into globals
>
> >
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Import of variables
-- Manuel Canga En dom, 09 ago 2020 23:41:12 +0200 Rowan Tommins escribió > On 9 August 2020 22:35:11 BST, Manuel Canga wrote: > > Hi Manuel, > > I think there's a misunderstanding. My comments weren't really about how to > implement your proposal, they were about the features the language already > has, which in my view make this new feature unnecessary. > > Regards, > > Hi, Rowan. I'm sorry. I'm Spanish and my English is not very good. :( A new example: ``` $miVariableEsSuperBuena='5'; include __DIR__.'/test.php'; ``` # test.php ``` echo miVariableEsSuperBuena; echo empty($miVariableEsSuperbuena); ``` What is the result ? .. - Result is 51( the second identifier is wrong ). However, with: ``` $miVariableEsSuperBuena='5'; include __DIR__.'/test.php'; # test.php use vars miVariableEsSuperBuena; echo miVariableEsSuperBuena; echo empty($miVariableEsSuperbuena); //editor could mark this variable as not initialized. ``` . Regards -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Import of variables
Hi, David. Thanks En dom, 09 ago 2020 16:58:41 +0200 David Rodrigues escribió > I suggests to make something like Node does: import "file.php" ($a, $b) so > $a and $b must be extracted from file.php context. All other variables > should be ignored. > Or, to avoid create more complexity and possible new keywords to import > syntax, maybe create a new function: > importx(string $file, ?array $extract = null) and requirex(...) (importx and > requirex is only pseudo) That is a good idea!. However, in some framworks/CMS you don't have control about include/require. :( Regards -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Import of variables
Hi, Josh. Thanks En dom, 09 ago 2020 21:36:30 +0200 Josh Bruce escribió > Have not tested - just catching up on emails. > > To verify: A property defined with a default value of the global does not > already do this? In functions/methods. In some files can "inherit" gobal vars directly or simply "inherit" local vars of other function. > Developer need: I rarely access global variables directly - usually going > through a lib or framework. When I do I would probably wrap the access in a > trait or method on a class. Some frameworks or CMS use view files in PHP like templates. https://platesphp.com/v3/templates/syntax/#syntax-example In WordPress case: "Developers are advised to consider this a Reserved Name List, and not to create local variables with the same names in Plugins or Themes. Under some circumstances, the global variable value will be replaced by the local variable value, causing errors in the WordPress Core that are difficult to diagnose. " https://codex.wordpress.org/Global_Variables This could be avoid easily with "use vars none" on the start of each file of theme/plugin. Regards -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Import of variables
Hi, Tyson, Thanks.
En dom, 09 ago 2020 16:41:44 +0200 tyson andre
escribió
> Hi Internals,
>
> To be clear: The variables in the top-level scope depend on what has
> require()d/include()d a file.
> The top-level scope starts off as being global, but if a file is required
> from within a function/method/closure (e.g. the autoloader closure), then
> the top-level scope in the require()'d file uses variables (e.g. $this) from
> whatever context called require().
My idea was using 'use vars' not only with global vars but also with vars in
context.
> It may be possible to use a declare syntax, e.g.
> declare(used_variables='all') for `'all'`, `null`, `['var1', 'var2']`, etc.
> - Otherwise, you face the issue of where `use vars` should be allowed, what
> happens if there's a statement before `use vars`, etc.
Good point, I don't think about that.
> I can see this as having some use cases, such as in configuration files or
> files used for bootstrapping.
> For example,
>
> ```
> declare(used_variables=null);
>
> $api_base = IS_PRODUCTION ? 'https://example.com/api/' :
> 'http://localhost/api';
> do_stuff();
>
> return [
> // long config array
> 'url_new' => "$api_base/new",
> 'url_all' => "$api_base/all",
> ];
> ```
>
> This feature (ignoring the question of syntax) would ensure that people
> reading the file knew that $api_base was not modified by other files
> and that other files did not read local variables created within a
> configuration/bootstrapping file in unexpected ways,
> which is a fairly common issue in some web apps I've worked on.
> Opcache would also do a better job at optimizing code if it knew which
> variables in a top-level scope couldn't be modified.
>
> That being said, there's been opposition to extensions to the language that
> add functionality that can be implemented in other ways, as in Rowan's
> comment,
> but peoples opinions depend on the specifics of the proposal
> (e.g. `match` was added and was more performant than chained conditionals or
> switch).
>
> As Rowan said, there are ways to reimplement this:
> - Wrapping the config file or bootstrapping file in a closure, global
> function, or class method
> - `function safe_require_once(string $path, $vars = []) { extract($vars);
> require($path); }` from the caller, to limit what variables are passed in.
> IDEs/tooling would be worse at telling you if a file name had a typo, though.
I think in views system( of some frameworks ) or CMS like WordPress. In
WordPress, for example, I can do something like this:
## index.php
```
foreach($posts as $post ) {
$post = 'foo';
}
```
index.php is loaded from CMS. $post is a global variable used in WordPress
core. So that, I am crashing WordPress. However, with:
```
use vars none;
foreach($posts as $post ) {
$post = 'foo';
}
```
I don't crash my WordPress or any external plugin which can use global vars. My
file now is a container( black box ) where my code is isolated.
Regards
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [RFC] Import of variables
Hi Internals, I'd like to open up a discussion around the implementation of a new functionality: 'import of variables'. This functionality would allow to create a new 'use vars' keyword in order to can use( or cannot use ) global variables in local scope( of current file ). I think the best is a example: ```php https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Named arguments
Hi, Rowan, En dom, 12 jul 2020 14:19:08 +0200 Rowan Tommins escribió > The problem with this, whether built in or not, is that you have to express > everything with strings rather than keywords. That means, for instance, that > invalid values in the definitions themselves will only error at run-time. > The definitions also tend to get verbose pretty quickly. > > To make it concise and checked at compile-time, you need it to be a > construct that pairs identifiers to types without first representing them as > strings, e.g. to write `?string $foo = 'hello'` rather than `'foo' => > ['type'=>'string', 'nullable'=>true, 'default'=>'hello']`. It turns out we > already have a construct for doing that: function signatures. > > If the input is an actual array or object coming from "outside", you're > probably going to want a more extensible validation system anyway. Those are > really hard to design, and probably best left to userland where people can > choose the tradeoffs they prefer. > > Regards, > I see. However, with named arguments you also have to implement changes in parser in order to can recognize named arguments. You also have to change behavior about default parameters. I don't know if this change affect to performance, maybe do. By the other hand, editor like PHPStorm has "Inlay Hints": https://www.jetbrains.com/help/rider/Inline_Parameter_Name_Hints.html With a function which checks scheme, you also could use in other contexts, like forms: ``` $scheme = ['name' => 'string', 'surname' => 'string', '?age' => 'int'); $is_valid = array_check_scheme( $_POST, $scheme ); ``` You can use it even with JSON: ``` $request = json_decode( $request_json, true ); $scheme = ['name' => 'string', 'surname' => 'string', '?age' => 'int'); $is_valid = array_check_scheme( $request, $scheme ); ``` > e.g. to write `?string $foo = 'hello'` rather than `'foo' => > ['type'=>'string', 'nullable'=>true, 'default'=>'hello']` Maybe you don't need checked at compile-time. is it slow?, securely, but you don't use in everywhere. > you're probably going to want a more extensible validation system anyway. Maybe, in that case, userland libraries have a starting point. With XML parsing is the same. PHP provides basic functionality and userland provide advanced. Regards -- Manuel Canga -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Named arguments
Hi,
En vie, 10 jul 2020 16:18:40 +0200 Benjamin Eberlei
escribió
> On Fri, Jul 10, 2020 at 11:21 AM Marco Pivetta wrote:
>
> > Hi Nikita,
> >
> > I kept my "NO" stance here, as per discussion in
> > https://externals.io/message/110004#110005, where I provided (in my
> > opinion) good/safe alternatives to arrays as input parameters.
> >
>
> > The BC implications on this RFC still largely outweigh any advantages that
> > it brings, from my perspective.
> >
>
> Are there alternatives to named parameters? Of course. Are they as simple?
> Not really.
>
> 1. You can use an array, but array values cannot be typed, so you completly
> loose typing of the language.
> 2. You can use an object with builder pattern, but that requires a lot of
> code to write, and increases the mental capacity of understanding something
> for developers.
> 3. your example of an api to convert named params to a sequence is not
> discoverable, you don't know looking or using method A() that it comes with
> an additional NamedParamsA() helper.
>
4. Other option is creating a new function( not yet available in PHP ) like:
```
array_check_scheme( array $array, array $scheme, bool $forced = false ): bool
```
( name of function can be better )
in order to check types in arrays. Then you could:
/**
* @param array $args{name: string, surname: string, ?age: int}
*/
function my_function( array $args ) {
$scheme = ['name' => 'string', 'surname' => 'string', '?age' => 'int');
$is_valid = array_check_scheme( $args, $scheme );
}
my_function( ['name' = 'Nikita', 'surname' => 'Popov' ] ); //is_vaild = true
my_function( ['name' = 'Nikita'] ); //is_vaild = false
my_function( ['name' = 'Nikita'], 'age' => 10 ); //is_vaild = false
A function like this could be useful in other contexts as well.
Regards
--
Manuel Canga
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Proposal For Return-If / Early Return / Guard Clause Syntax
En mar, 19 may 2020 08:53:46 +0200 Manuel Canga
escribió
>
> Hi, Internals,
>
>
>
> En dom, 17 may 2020 06:33:51 +0200 Peter Stalman
> escribió
> > A few thoughts:
> >
> >
> > 1. I agree with the sentiment that this syntactic sugar doesn't
> > actually save any verbosity, so it's not really syntactic sugar at
> > all.
> >
> >
> > 2. There appears to now be another RFC by Pavel Patapau, specifically
> > focused on a Guard statement as a new keyword
> > (https://wiki.php.net/rfc/guard_statement), which now has its separate
> > discussion.
> >
> >
> > 3. As Thomas Lamy mentioned, I too would prefer a single keyword.
> > Consider the following two examples:
> >
> > function foo($bar)
> > {
> > if ($bar === 1)
> > return;
> >
> > if ($bar === 666)
> > delete_everything();
> > }
> >
> >
> > Both would now be valid syntax, and IDEs would have a harder time
> > warning about the misplaced semicolon in the second example. Wouldn't
> > be very common, but still.
> >
> >
> > 4. However, this RFC is interesting to me because there be a way to
> > modify it to allow for less verbose refactoring, and kinda allowing
> > returns to bubble up like exceptions do. I think it would only make
> > sense if it's a "if not null then return" type of thing.
> >
> > Consider the following (a bit contrived, but I hope you get the point):
> >
> > function main_function()
> > {
> > $result = calculate($var);
> > if ($result !== null)
> > return $result;
> >
> > /* do other important stuff */
> > }
> >
> > function main_function()
> > {
> > ifnotnullreturn calculate($var);
> >
> > /* do other important stuff */
> > }
> >
> > Obviously not an ideal keyword, but this is the only thing I can think
> > of where this type of syntactic sugar makes sense and decreases
> > verbosity. Something similar can also be accomplished with exception
> > though.
> >
> >
> > 5. Finally, I think if we start putting several returns at the same
> > indentation then the cognitive load increases because we can no longer
> > tell if a return is actually a return at a glance.
> >
> >
> > Thanks,
> > Peter
> >
>
> I agree.
>
> ¿ Maybe something like...
>
>function main_function()
> {
> escape when( calculate($var) );
>
> /* do other important stuff */
> }
>
>
> `escape when( expr )` returns value of `expr` to caller function when
> `expr` evaluate to true otherwise next line.
>
>function main_function()
> {
> escape with $ a + 1 when( !calculate($var) );
>
> /* do other important stuff */
> }
>
>
> `escape with expr1 when( expr2 )` returns value of `expr1` to caller
> function when `expr2` evaluate to true otherwise next line.
>
>
Upgrade version.
Maybe is better:
`escape when( expr )` returns null to caller function when `expr` evaluate
to true otherwise next line.
`escape with expr1 when( expr2 )` returns value of `expr1` to caller function
when `expr2` evaluate to true otherwise next line.
Then these code are equals to:
> > function main_function()
> > {
> > $result = calculate($var);
> > if ($result !== null)
> > return $result;
> >
> > /* do other important stuff */
> > }
> >
function main_function()
{
escape with $result when( $result = calculate($var) );
/* do other important stuff */
}
> > function foo($bar)
> > {
> > if ($bar === 1)
> > return;
> >
> > if ($bar === 666)
> > delete_everything();
> > }
function foo($var) {
escape when( $bar === 1 || $bar !== 600 );
delete_everything();
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal For Return-If / Early Return / Guard Clause Syntax
Hi, Internals,
En dom, 17 may 2020 06:33:51 +0200 Peter Stalman
escribió
> A few thoughts:
>
>
> 1. I agree with the sentiment that this syntactic sugar doesn't
> actually save any verbosity, so it's not really syntactic sugar at
> all.
>
>
> 2. There appears to now be another RFC by Pavel Patapau, specifically
> focused on a Guard statement as a new keyword
> (https://wiki.php.net/rfc/guard_statement), which now has its separate
> discussion.
>
>
> 3. As Thomas Lamy mentioned, I too would prefer a single keyword.
> Consider the following two examples:
>
> function foo($bar)
> {
> if ($bar === 1)
> return;
>
> if ($bar === 666)
> delete_everything();
> }
>
> function foo($bar)
> {
> if ($bar === 1)
> return
>
> if ($bar === 666);
> delete_everything();
> }
>
> Both would now be valid syntax, and IDEs would have a harder time
> warning about the misplaced semicolon in the second example. Wouldn't
> be very common, but still.
>
>
> 4. However, this RFC is interesting to me because there be a way to
> modify it to allow for less verbose refactoring, and kinda allowing
> returns to bubble up like exceptions do. I think it would only make
> sense if it's a "if not null then return" type of thing.
>
> Consider the following (a bit contrived, but I hope you get the point):
>
> function main_function()
> {
> $result = calculate($var);
> if ($result !== null)
> return $result;
>
> /* do other important stuff */
> }
>
> function main_function()
> {
> ifnotnullreturn calculate($var);
>
> /* do other important stuff */
> }
>
> Obviously not an ideal keyword, but this is the only thing I can think
> of where this type of syntactic sugar makes sense and decreases
> verbosity. Something similar can also be accomplished with exception
> though.
>
>
> 5. Finally, I think if we start putting several returns at the same
> indentation then the cognitive load increases because we can no longer
> tell if a return is actually a return at a glance.
>
>
> Thanks,
> Peter
>
I agree.
¿ Maybe something like...
function main_function()
{
escape when( calculate($var) );
/* do other important stuff */
}
`escape when( expr )` returns value of `expr` to caller function when
`expr` evaluate to true otherwise next line.
function main_function()
{
escape with $ a + 1 when( !calculate($var) );
/* do other important stuff */
}
`escape with expr1 when( expr2 )` returns value of `expr1` to caller function
when `expr2` evaluate to true otherwise next line.
Regards
--
Manuel Canga
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Keep type of reference params
Hi, Internals, En lun, 11 may 2020 11:34:22 +0200 Nikita Popov escribió > > I'm finding it hard to follow what is actually being proposed here at this > point (as many different ideas seems to be discussed at the same time). > I've granted you RFC karma on the wiki in case you want to write down > something. > > As other's have mentioned, this is not a simple topic from the > implementation side, so it's good to have a firm idea of how things would > work on a technical level. If you want to pursue the "inout" idea, I would > recommend reading through https://externals.io/message/101254 in its > entirety, because there is quite a bit of inout related discussion in > there. My current assessment is that I do not see any way to implement > inout in a way that both does not use references and has acceptable > performance. (Implementing inout on top of references is possible, but has > impact on its behavior, e.g. the fact that the reference will be > initialized to null by default, even if the function throws.) > > One of the core problems is that any naive approach to inout (i.e. > literally implementing it as a read before the call and a write after the > call) will necessitate a copy of the modified value, precluding rc=1 cow > avoidance. Implementing array_push() as an inout operation would copy the > array every time a value is pushed. Maybe this is actually a fundamental > implementation-independent property of inout, if it has the semantics that > the original value is not changed on exception (a copy would be necessary > in case code later in the function throws.) > > Regards, > Nikita Nikita, I've already read your thread. I like your purpose about "Explicit call-site send-by-ref syntax". I don't understand why it wasn't accepted. Yes, you're right about performance then maybe this RFC doesn't make much sense. :( Thanks, anyway. You can remove my karma again. Regards -- Manuel Canga -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Keep type of reference params
Hi, Nikita and internals, En lun, 11 may 2020 11:34:22 +0200 Nikita Popov escribió > On Fri, May 8, 2020 at 8:49 AM Manuel Canga wrote to > this RFC, could someone give me(manuelcanga user ) karma in order to create > wiki page ?. > > I'm finding it hard to follow what is actually being proposed here at this > point (as many different ideas seems to be discussed at the same time). I've > granted you RFC karma on the wiki in case you want to write down something. > As other's have mentioned, this is not a simple topic from the > implementation side, so it's good to have a firm idea of how things would > work on a technical level. If you want to pursue the "inout" idea, I would > recommend reading through https://externals.io/message/101254 in its > entirety, because there is quite a bit of inout related discussion in there. > My current assessment is that I do not see any way to implement inout in a > way that both does not use references and has acceptable performance. > (Implementing inout on top of references is possible, but has impact on its > behavior, e.g. the fact that the reference will be initialized to null by > default, even if the function throws.) > One of the core problems is that any naive approach to inout (i.e. literally > implementing it as a read before the call and a write after the call) will > necessitate a copy of the modified value, precluding rc=1 cow avoidance. > Implementing array_push() as an inout operation would copy the array every > time a value is pushed. Maybe this is actually a fundamental > implementation-independent property of inout, if it has the semantics that > the original value is not changed on exception (a copy would be necessary in > case code later in the function throws.) Thanks, Nikita. I will read that thread. I don't have know about PHP core so it's possible I will say a silly thing but... is possible using Hack implementation ?. Maybe They found the best way of implementation. Regards -- Manuel Canga -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Keep type of reference params
En vie, 08 may 2020 23:40:22 +0200 Bob Weinand
escribió
> > Am 04.05.2020 um 10:53 schrieb Manuel Canga :
> >
> > Hi internals,
> >
> >
> >
> > I would like to present a possible new RFC( "keep type of reference
> > params" ) for your
> >
> > consideration.
> >
> >
> >
> > Firstly, an example:
> >
> >
> >
> > ```
> >
> > >
> >
> >
> > function my_array_shift( array & $array ) {
> >
> > $array = "string";
> >
> > }
> >
> >
> >
> > $array = [ 0, 1, 2, 3, 4 ];
> >
> >
> >
> > my_array_shift($array);
> >
> >
> >
> > count( $array );
> >
> > ```
> >
> >
> >
> > The result of this code is a warning( in count line ) because of $array is
> > a string.
> >
> > However, I think it should be an error or exception when a string is
> > assigned to $array var.
> >
> > In my opinion, $array var would have to keep its type when function ends.
> >
> >
> >
> > What is your opinion ? Do you see it useful ?
> >
> > Thanks and I'm sorry for my English( I'm a Spanish ).
> >
> > Regards
> >
> > --
> >
> > Manuel Canga
>
> Hey Manuel,
>
> the primary issue (apart from the BC break) here is leaking the reference
> across the function boundary.
>
> function a(array &$a) {
> $GLOBALS["globalA"] = &$a;
> }
>
> funcition b() {
> $GLOBALS["globalA"] = 10;
> }
>
> $a = 1;
> a($a);
> b();
> // $a is magically changed to 10
>
> Yes, you can here verify, that $a is an array at the function boundaries,
> but you cannot afterwards.
>
> If we had proper inout parameters (which do not leak a reference, but assign
> the value of the variable (in callee scope) back to the passed variable from
> caller), then we could easily enforce it.
>
> But as it stands now, this is not an option. (Especially due to the false
> promise this seems to make.)
>
> Bob
Thanks Bob, that was a great example
I explain...I am very forgetful, so it's very easy for me to write somethink
like this:
```
function filter_something( $to_filter) {
$to_filter = strtolower($to_lower);
$to_filter = sanitize_this($to_filter);
.
}
filter_something($my_string);
```
Sometimes, one of these functions can returns a false|null|numeric|... instead
of expected type.
Also, If any function in 'filter_somethid' would throw an exception, value in
$to_filter would finish inconsistent
However, with:
```
function filter_something( inout string $to_filter) {
$to_filter = strtolower($to_lower);
$to_filter = sanitize_this($to_filter);
.
}
filter_something(inout $my_string);
```
PHP could in the end produce exception when any function in `filter_something`
modify type of $my_string or
PHP could keep value of `$to_filter` as well if any function throwed an
exception.
Regards
--
Manuel Canga
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Keep type of reference params
En vie, 08 may 2020 15:31:52 +0200 Levi Morrison escribió > I think changing reference is a bad idea, even if it's behind some > sort of declare or ini setting or what-have-you. > > I do support `inout`, which has similar high-level outcomes: the > current value is fed in, and when the function returns it has a new > value. I think we should use `&` at the call site, and we should also > permit it optionally for by-ref parameters as it provides a migration > path: first add `&` to all the call sites, then switch it to `inout`. Hi, Levi, Thanks for your opinion. Why don't reverse mode ?. 'inout' is created with the three characteristics: - Check type of out is equal to type of param - Avoid modifying caller variable value when the function throws an exception. ( Like inout of Hacker language ) - Allow explicit call-site pass-by-reference annotation. Then, current references are deprecated and after than, in other version, they are removed. In this way, projects can be adapted gradually Regards -- Manuel Canga -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Keep type of reference params
En vie, 08 may 2020 15:07:13 +0200 Dan Ackroyd escribió > On Fri, 8 May 2020 at 07:49, Manuel Canga wrote: > > > > What is your opinion ? Do you see it useful ? > > I can see the need; I strongly dislike the idea of using references for this. > > What you're describing is a form of 'out parameters' which have been > mentioned a few times before on this list. > > I've made a note of the general idea here: > https://github.com/Danack/RfcCodex/blob/master/out_parameters.md > > Though the wikipedia article is also good: > https://en.wikipedia.org/wiki/Parameter_(computer_programming)#Output_parameters > > Using references for things like this is a bad idea as references make > it hard to reason about code. In this specific case, having the > function mutate the existing variable is horrible. Hi, Dan, I think nothing is bad practice. It depends of context. Example: global variables, __set/__get, public properties and so on could be considered bad practices, however, they sometimes are useful. References could be a priori bad idea, but if you limit your their dangerousness, they will be less bad. > > > If nobody objects to this RFC > > While you categorically must do what you must, I don't think you will > get much benefit from raising this as an RFC until you find someone > who can and is willing to implement it. I agree :'( > > Actually, just finding any core contributor who is willing to say that > they would back this idea might be a good idea. > > And yes, phpinternals could still really do with an 'informal but only > to open to voters' feedback mechanism. Someone should do something > about thatwait I'm _someone_. And I have wiki permissions. > > So here's a page for a non-binding 'indication of interest' poll: > https://wiki.php.net/indication_of_interest/keep_type_of_reference_params Thanks so much, Dan > > If anyone disagrees with the text, either please suggest a change or > edit it if you have karma. I'd add( but I don't have karma ): Add a new`inout` keyword( very similar to 'inout' of Hack ) in order to: - Check type of out is equal to type of param( like example of my first email ). - Avoid modifying caller variable value when the function throws an exception. ( Thanks to Mathew for link to inout* of Hacker language ) - Allow explicit call-site pass-by-reference annotation. ( Thanks to Rowands for link** to Nikita's RFC ) * https://docs.hhvm.com/hack/functions/inout-parameters ** https://wiki.php.net/rfc/explicit_send_by_ref > cheers > Dan > Ack Thanks again, Dan, Regards -- Manuel Canga -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Keep type of reference params
En vie, 08 may 2020 13:03:59 +0200 Thomas Gutbier
escribió
> Isn't that already solved for typed properties?
>
> Consider this:
>
> class A { public static int $number = 5; }
> $num = ::$number;
> $num = "String";
>
> This will result in an uncaught TypeError,
> see https://3v4l.org/XC6hk
>
> I would think, it would be consistent if referenced parameters
> behaved in exactly the same way.
>
> Regards,
> Thomas
>
>
Hi, Tomas,
That option was my first thought. However, people( and me ) I know, normally
use local vars for function calls.
Thanks Thomas for your opinion.
Regards
--
Manuel Canga
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Keep type of reference params
En vie, 08 may 2020 12:37:29 +0200 G. P. B. escribió I think everyone can agree this is useful. But the issue here is the implementation. Because from what I know PHP's references are a special kind of pain in the engine. That's why the common wisdom is to use references in PHP as least as possible. And IIRC what you are trying to achieve would need a major overhaul of how references work and someone who wanted to tackle this would have done it on their own and propose an RFC at the same time. So sadly unless something semi-concrete shows up, I'm considering this a pipe dream. But I'd gladly be shown otherwise. Hi, George. Thanks for your opinion. Nikita porposed a RFC in order to improve refences( https://wiki.php.net/rfc/explicit_send_by_ref, links thanks to Rowan ). Maybe, he wants to code this. Regards -- Manuel Canga,
Re: [PHP-DEV] [RFC] Keep type of reference params
En lun, 04 may 2020 19:33:51 +0200 Rowan Tommins escribió > On 04/05/2020 16:43, Manuel Canga wrote: > > I think I’d be positive of adding `inout` keyword in order to: > > > > - Check type of out is equal to type of param( like example of my first > > email ). > > - Avoid modifying caller var value when the function throws an exception > > > Another huge advantage of adding inout parameters is that we could make > it mandatory to mark at the call-site, and get the advantages of this > RFC with less of the compatibility hassle of changing the way references > work: https://wiki.php.net/rfc/explicit_send_by_ref > > We'd still need to figure out how to smoothly transition built-in > functions to use inout rather than by-ref parameters; but then we > already have magic "prefer-ref" in internal functions, so maybe we could > come up with some kind of "prefer-inout". > Hi, Rowan. That's a good point. If nobody objects to this RFC, could someone give me(manuelcanga user ) karma in order to create wiki page ?. Thanks in adavance -- Manuel Canga -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Keep type of reference params
En lun, 04 may 2020 15:01:44 +0200 Matthew Brown escribió > This would break quite a lot of existing code, though PHP could add an > explicit keyword like "inout" that catches this behaviour (see example in > Hack: https://docs.hhvm.com/hack/functions/inout-parameters). > > Today these issues can also be caught with static analysis: > https://psalm.dev/r/1f670956ab Thanks, Matthew, I don't know about inout. I think I’d be positive of adding `inout` keyword in order to: - Check type of out is equal to type of param( like example of my first email ). - Avoid modifying caller var value when the function throws an exception Other option is adding to normal reference( & ) these behaviours when strict_types will be activated in caller. Regards -- Manuel Canga -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Keep type of reference params
Hi internals, I would like to present a possible new RFC( "keep type of reference params" ) for your consideration. Firstly, an example: ```
Re: [PHP-DEV] Feature request - allow to append multiple elements to an array
Hi, Internals
>
> Em sáb., 28 de mar. de 2020 às 20:07, Michael Voříšek - ČVUT FEL <
> voris...@fel.cvut.cz> escreveu:
>
> > Hi all PHP gurus!
> >
> > This is a feature request / RFC for the following use-case:
> >
> > $res = [];
> > foreach ($arr as $i) {
> > foreach (make_res($i) as $v) {
> > $res[] = $v;
> > }
> > }
> >
Maybe, PHP needs array_flatten like Ruby:
https://apidock.com/ruby/Array/flatten
In this way, above code would be equal to:
$res = array_flatten( array_map('make_res', $arr) );
Regards
--
Manuel Canga
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] Type casting in array destructuring expressions
Hi, Enno,
En mié, 25 mar 2020 18:53:15 +0100 Enno Woortmann
escribió
> Hi,
>
> I've written the RFC and implemented a first patch concerning the idea
> to allow type casting in array destructuring expressions.
>
>
> The RFC is located at https://wiki.php.net/rfc/typecast_array_desctructuring
>
> The patch can be found in MR 5296 located at
> https://github.com/php/php-src/pull/5296
>
>
> Thanks for further feedback!
>
> Cheers, Enno
>
I like your RFC. I hope it is approved. However, I would change your
examples. Because, this one:
["now" => (int) $now, "future" => (int) $future] = ["now" => "2020", "name" =>
"2021"];
You could do casting in this way:
["now" => $now, "future" => $future] = array_map('intval', ["now" => "2020",
"name" => "2021"] );
If I were you I add examples with mixed types, like:
["address" => (string) $address, "floor" => (int) $floor] = ["address" => "My
adress", "floor" => "3"];
I'm sorry my English
Regards
--
Manuel Canga
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] switch expression
Hi, internals,
En mié, 25 mar 2020 17:21:29 +0100 Rowan Tommins
escribió
> On Wed, 25 Mar 2020 at 15:29, Ilija Tovilo wrote:
>
> > I don't think this would add any significant benefit over:
> >
> > ```php
> > $x = true switch {
> > $x !== null && $x < 5 => ...
> > }
> > ```
> >
>
>
> The problem with that is that it requires a temporary variable to be
> switched on. If I want to switch on, say, a method call, I can write this
> for equality:
>
> $result = $this->foo($bar) switch {
> 1 => 'hello',
> 2 => 'hi',
> 3 => 'goodbye'
> };
In this case, you can also do:
$result = [
1 => 'hello',
2 => 'hi',
3 => 'goodbye'
][$this->foo($bar)];
With syntax very similar to proposed switch but this is using array.
Regards
--
Manuel Canga
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] exit() via exception
ill have the scenario 2 available
> >> on PHP land without a BCB? :)
> >>
> >
> >> I have one simple suggestion: Introduce `EngineShutdown -> Throwable`,
> >> bind `exit|die` to it but disallow
> >> `catch(\EngineShutdown $e)` at compile time. This would allow keeping
> >> backwards compatibility to
> >> scenario 2 without messing with our current exception hierarchy.
> >>
> >
> > I think the options are basically:
> >
> > 1. Making EngineShutdown implement Throwable, which would make existing
> > catch(Throwable) catch it -- probably a no-go.
> >
> > 2. Making EngineShutdown not implement Throwable, which means that not all
> > "exceptions" implement the interface, which is rather odd. It still allows
> > explicitly catching the exit.
> >
> > 3. Introducing a function like catch_exit(function() { ... }). This would
> > still allow catching exits (for phpunit + daemon use cases), but the fact
> > that this is actually implemented based on an exception would be hidden and
> > the only way to catch the exit is through this function.
> >
> > 4. Don't allow catching exits at all. In this case the exception is just
> > an implementation detail.
> >
>
> I've started implementing variant 4 in
> https://github.com/php/php-src/pull/5243. It uses an internal exception
> type to implement exit() that cannot be caught.
>
> Finally blocks do get executed, as they should be. This does mean that it
> is possibly to discard the exit through finally, because control flow
> performed in finally always wins:
>
> try {
> exit;
> } finally {
> (null)->method(); // throw Error
> }
>
> This snippet will throw an Error exception, with the original exit being
> discarded.
>
> try {
> try {
> exit;
> } finally {
> (null)->method(); // throw Error
> }
> } catch (Error $e) {
> // Ignore
> }
>
> This snippet will catch the Error exception and thus stops unwinding.
>
> I believe this behavior is correct and expected (by which I mean:
> consistent with finally semantics), but it does mean that exits can be
> discarded even without having an explicit "catch_exit" function or similar.
>
> Nikita
>
Hello,
About this subject:
Nowadays, `register_shutdown_function`* function exists in order to custom your
the end of program. However, with this code:
--- CODE ---
https://www.php.net/manual/en/function.register-shutdown-function.php
Regards
--
Manuel Canga
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC]
En sáb, 15 feb 2020 09:22:41 +0100 Larry Garfield escribió > On Fri, Feb 14, 2020, at 1:04 AM, Manuel Canga wrote: > > > Maybe, bettern fn: * fn(callable $to_clsoure ): *closure ? > > > > I know fn is used in arrow functions. However, for that same reason fn is > > the most convenient. > > > > Using dik examples( by the way, they are brilliant ): > > Point of order: The Stats analyzer examples were from me, not Dik. :-) > They're taken from one of the monad chapters in the book I'm working on. > > --Larry Garfield > By the way...the following is for folks in internals: Do you think it is worth creating an RFC page about :: function ? I say that because I see that there are many voices against of :: function -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC]
En sáb, 15 feb 2020 09:22:41 +0100 Larry Garfield escribió > On Fri, Feb 14, 2020, at 1:04 AM, Manuel Canga wrote: > > > Maybe, bettern fn: * fn(callable $to_clsoure ): *closure ? > > > > I know fn is used in arrow functions. However, for that same reason fn is > > the most convenient. > > > > Using dik examples( by the way, they are brilliant ): > > Point of order: The Stats analyzer examples were from me, not Dik. :-) > They're taken from one of the monad chapters in the book I'm working on. > > --Larry Garfield Oops!, sorry Larry!. Then you book will be securily a great book. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC]
On Fri, 14 Feb 2020 at 01:39, Mike Schinkel wrote:
> > On Feb 13, 2020, at 7:24 PM, Rowan Tommins
> wrote:
> >
> > An idea I had earlier which might solve some of them is if what was
> returned was not a normal Closure instance, but a new class like
> FunctionReference. It could then "remember" the name of the function
> wrapped, and implement __toString, Serializable, etc. It could inherit from
> Closure, so instanceof checks would work, and bindTo would return a normal
> Closure. I'm sure there's downsides I haven't thought of yet, but I thought
> I'd throw the idea into the mix.
>
> I thought about that too, and mentioned it yesterday in a reply[1] to you
> on this list.
>
> Here is the link to the Gist with the hypothetical code using such a
> concept:
>
> - https://gist.github.com/mikeschinkel/78684d708358e1d101e319c7a2fdef9c
>
> -Mike
>
>
> [1] https://www.mail-archive.com/internals@lists.php.net/msg100719.html
>
>
Maybe, bettern fn: * fn(callable $to_clsoure ): *closure ?
I know fn is used in arrow functions. However, for that same reason fn is
the most convenient.
Using dik examples( by the way, they are brilliant ):
$result = Stats::of($string)
->analyze(fn(normalizeNewlines))
->analyze(fn(readingLevel))
->analyze(fn(countStats))
->analyze(fn($synonymSuggester, 'analyze'))
->analyze(fn(WordCouter::class, 'analyze'))
->analyze(fn($s) => wordDistribution($s, 3))
Returning to ::function again and with a modified example of dik( again ):
Now is:
result = Stats::of($string)
->analyze('\Stats\Analyzer\normalizeNewlines')
->analyze('\Stats\Readings\readingLevel')
->analyze('\Stats\Parser\countStats')
->analyze(fn($s) => \Stats\Analyzer\wordDistribution($s, 3));
Could be:
use function Stats\Analyzer\normalizeNewlines;
use function \Stats\Readings\readingLevel;
use function \Stats\Parser\countStats;
result = Stats::of($string)
->analyze(normalizeNewlines::function)
->analyze(readingLevel::function)
->analyze(countStats::function )
->analyze(fn($s) => \Stats\Analyzer\wordDistribution($s, 3));
Maybe '::function' is something long, however it wiil be autocompleted by
editors and, moreover, nowadays function is a reserved keyword. Could we
use "normalizeNewlines::name", but in this case: normalizeNewlines is
function or class ?, because in this case could be "normalizeNewlines" a
class and "name" a constant of class.
Rowan put me in an awkward situation with [MyClass::class, method::function
] however, in this case, could be simply MyClass::class, 'method' ].
Because method don't need be used with namespace. ::function could be
documented with advice of being used with name of functions. Because
::function is also useful in array:
$filters = [ normalizeNewlines::function, readingLevel::function,
countStats::function
]
$content = Stats::of($string);
foreach($filters as $filter) $filter($content);
Regards
Re: [PHP-DEV] [RFC]
On Thu, 13 Feb 2020 at 08:58, Rowan Tommins wrote:
> On 12 February 2020 23:12:34 GMT+00:00, Manuel Canga <
> manuelca...@gmail.com> wrote:
> >El mié., 12 feb. 2020 23:01, Rowan Tommins
> >escribió:
> >In your example, you has the same options:
> >
> >>
> >1. Change import
> >2. Add namespace:
> >
> >['Acme\Global\I18N',\translate::function]
>
>
> There is no collision between 'Foo::translate()' and 'translate()', so
> there is no reason to change the import. That's true of executing the
> functions, so it should remain be true of resolving them to strings.
>
> There is collision with import which you added.
>
>
> >Explain:
> >
> >When you do: [ class, method ] or [ $object, method ]. Method has not
> >namespace, you write it without namespace( like global functions )
>
>
> I think this is where we are thinking differently. A method name is not
> "like a global function", it's just a name; it doesn't belong in the same
> category.
>
> You might have any number of classes that use the same method name, but
> with completely different parameters and purpose, so "a method named foo"
> isn't a useful concept outside some specific class or interface.
>
> On the other hand, you can only have one function with a particular
> fully-qualified name, and the proposed feature is a way of referencing that.
>
>
Function as callable is different as regular function. Example:
http://sandbox.onlinephpfunctions.com/code/99408213d1ed740f60471646f16f9765d7efa93e
namespace MyProject;
function my_function() {
//
}
my_function(); // it calls to \MyProject\my_function
array_map('my_function', [] ); //*
* Here, 'my_function' is only a string. Maybe a global function( without
namespace ) or maybe a method or other case. With native array_map is a
global function. However, you can have a function like this:
function array_map( $method, $array) {
\Collection::$method( $array );
}
In both cases, you could do:
array_map(\my_function::function, [] );
>
>
> >Other example:
> >
> >$class = \MyClass::class;
> >$method = \method::function;
> >
> >and...
> >
> >$class = '\MyClass';
> >$method = 'method';
> >
> >$obj = new $class();
> >$obj->$method();
> >
> >Both are the same, but first is more semantic.
>
>
> This isn't semantic at all - it works only because \method::function
> happens to return the string you want, but so does \method::class; neither
> is actually labelling it as what it is, which is a method within class
> \MyClass.
>
> Importantly, it might not work at all, if ::function gives an error if
> the function doesn't exist.
>
>
::function only would retrieve string, like as ::class, exists or not. In
fach, that code might not work at all due to class. What matter if Class
does't exist ?. ::class doesn't produce error. Look:
http://sandbox.onlinephpfunctions.com/code/0a8466a00974bc1ffc12b219569ced55753327bd
If class doesn't exist, nothing happend.
Thank, Rowan. You points of view are very interesting.
Re: [PHP-DEV] [RFC]
El mié., 12 feb. 2020 23:01, Rowan Tommins
escribió:
> On 12/02/2020 21:47, Manuel Canga wrote:
> > You is importing function and you are using different. It is the same
> > case like:
> >
> > namespace MyProject;
> >
> > use Vendor/Controller;
> >
> > class Controller extends Controller {
> > }
>
>
> In that example, you're defining two things of the same type with the
> same name, which would be an error; that's not what was happening in my
> example.
>
> In a call like Acme\Global\I18N::translate, or a callable like
> ['Acme\Global\I18N', 'translate'], the "translate" part never refers to
> a function in the current namespace, or indeed any namespace, only to a
> method of that particular class.
>
> But if you write ['Acme\Global\I18N', translate::function], there's no
> way for the engine to know that you wanted a method name rather than a
> function name, so it will try to resolve it in the current namespace and
> import list. That will either give an error, because there is no
> function called translate; or it will give you a fully-qualified name,
> which isn't what you wanted, you just wanted the string 'translate'
>
You're right about my example. This is good example:
namespace MyProject;
use Vendor\Controller;
class MyController extends Controller {
.
}
This is an error, if Controller has actually MyProyect namespace. Then, you
have two options:
1. Change import
2. Add namespace to class Controller
In your example, you has the same options:
>
1. Change import
2. Add namespace:
['Acme\Global\I18N',\translate::function]
Explain:
When you do: [ class, method ] or [ $object, method ]. Method has not
namespace, you write it without namespace( like global functions ) then you
do the same with ::function. This is [ class, \method::function ] or [
$object, \method::function ]
Other example:
$class = \MyClass::class;
$method = \method::function;
$obj = new $class();
$obj->$method();
and...
$class = '\MyClass';
$method = 'method';
$obj = new $class();
$obj->$method();
Both are the same, but first is more semantic.
Re: [PHP-DEV] [RFC]
El mié., 12 feb. 2020 22:36, Rowan Tommins
escribió:
> On 11/02/2020 15:13, Manuel Canga wrote:
> > One case which string can be useful but a callable would not be
> acceptable is:
> >
> > array_map([I18N::class, translate::function] );
>
>
> I wouldn't expect that to work anyway, because the whole purpose of the
> keyword would be to resolve "translate" as a function name, not a method
> name, e.g.
>
> use Acme\Global\I18N;
> use function Acme\Global\translate;
>
> var_dump([I18N::class, translate::function]);
>
> # array(0 => 'Acme\Global\I18N', 1 => 'Acme\Global\translate')
> # not a valid callable
>
> var_dump([I18N::class, 'translate']);
>
> # array(0 => 'Acme\Global\I18N', 1 => 'translate');
> # this was what was intended
>
>
> If you didn't want to quote the method, you'd need some other syntax
> that took both class and method name, like:
>
> [I18N, translate]::callable
>
> Or as proposed elsewhere in the thread:
>
> $(I18N::translate)
>
>
> Regards,
>
Hi,
You is importing function and you are using different. It is the same case
like:
namespace MyProject;
use Vendor/Controller;
class Controller extends Controller {
}
>
Re: [PHP-DEV] [RFC]
On Wed, 12 Feb 2020 at 15:08, Dan Ackroyd wrote:
> On Tue, 11 Feb 2020 at 13:19, Nikita Popov wrote:
> >
> > https://wiki.php.net/rfc/consistent_callables.
> >
>
> btw it's probably worth mentioning the other reason I didn't pursue
> https://wiki.php.net/rfc/consistent_callables.
>
> By itself, the callable type isn't much use. It only allows you to
> specify that a type can be called, but it doesn't allow you to specify
> what parameters the callable should take, or what the return type
> should be.
>
> Just making the callable type be consistent would be a lot of work,
> and possibly cause a lot of BC breaks and still not do the useful
> thing.
>
> Instead what would be far more useful would be allow people to define
> the callable signature, and use that as a type.
>
> callable some_callback(int $x, string $y) : int;
>
> function bar(some_callback $fn) { }
>
> $fn_correct = function (int $x, string $y) : int {}
> $fn_wrong = function (int $x, string $y) : int {}
>
> Calling bar with $fn_correct should work.
> Calling bar with $fn_wrong should give a type error.
>
> In my opinion, pursuing that idea would be a lot more valuable than
> breaking BC for callables without much gain.
>
> cheers
> Dan
> Ack
>
Hi, internals,
I think, we are taking this very far. In Spain, we usually say: "Quien
mucho abarca, poco aprieta". In English, I think is similar to: "don’t bite
off more than you can chew" or KISS/YAGNI in development. IMO, we should
limit RFC to '::function'( scope and accept/reject ). After this, other RFC
can be added/checked like Short closures( of Michal ) or other purposes
with other variation like :interface and ::trait: ( of Mike )
Respect to ::function:
::function, it should return a string like ::class. This is:
Case 1: ::function === \namespace\function_name ( when
function_name is imported )
Case 2: ::function === \current_namespace\function_name(
when ::function is below a namespace )
Case 3: ::function === \function_name( when
::function is not below a namespace )
Case 4: \namespace\::function === \namespace\function_name
Case 5: \::function === \function_name ( equal of 4 but in
global context )
Examples:
1.
namespace my_project;
use function \vendor\I18n\translate;
$mapped_array = array_map(translate::function, $array);
//= $mapped_array = array_map('\vendor\I18n\translate', $array);
2.
namespace my_project;
$mapped_array = array_map(translate::function, $array);
//= $mapped_array = array_map('\my_project\translate' $array);
3.
$mapped_array = array_map(translate::function, $array);
//= $mapped_array = array_map('\translate' $array);
4.
$mapped_array = array_map(\vendor\I18n\translate::function, $array);
//= $mapped_array = array_map('\vendor\I18n\translate' $array);
5.
$mapped_array = array_map(\translate::function, $array);
//= $mapped_array = array_map('\translate' $array);
Although, cases 3, 4 or 5, can appear useless, however editors could
distinguish
when is a function( and not a ordinary string ) and validate if function
exists or not.
Regards
Re: [PHP-DEV] [RFC]
On Tue, 11 Feb 2020 at 17:49, Dan Ackroyd wrote:
>
> Nicolas Grekas wrote:
> > I wish this would return a Closure instead, making $foo::function the
> > equivalent of Closure::fromCallable($foo).
>
> I didn't include the following in that RFC, because I thought it would
> be too controversial, but I think it's worth considering a new syntax
> for this.
>
> Given the code:
>
> function foo();
> class Zoq {
> public function Fot() {}
> public static function Pik() {}
> }
> $obj = new Zoq();
>
>
> Then these:
>
> $(foo);
> $($obj, Fot);
> $(Zoq, Fot);
>
> Would be equivalent to:
>
> Closure::fromCallable('foo');
> Closure::fromCallable([$obj, 'Fot']);
> Closure::fromCallable('Zoq::Fot'); or Closure::fromCallable(['Zoq', 'Fot']);
>
> Or similar.
>
> The justification for having a dedicated syntax is that I think
> readability is quite important in code, and it's reasonably common for
> me to have quite long lists of 'callables'.
>
> [Bar::class, foo1::function],
> [Bar::class, foo2::function],
> [Bar::class, foo3::function],
> [Bar::class, foo4::function]
>
> vs
>
> $(Bar, foo1),
> $(Bar, foo2),
> $(Bar, foo3),
> $(Bar, foo4)
>
> The latter is far easier to read for me.
>
> Nikita Popov wrote:
> > This would circumvent all the issues outlined in
> > https://wiki.php.net/rfc/consistent_callables.
>
> Probably there would still be some issues with some of the weird stuff
> happening internally in SPL related code where the deep horrors
> rest...but we can leave them alone...and they might not wake.
>
> cheers
> Dan
> Ack
Other option:
Closure::fromCallable('foo');
Closure::fromCallable([$obj, 'Fot']);
Closure::fromCallable('Zoq::Fot'); or Closure::fromCallable(['Zoq', 'Fot']);
to
<$foo, Fot>
E.g:
array_map(, $array);
array_map(, $array);
Do you like ?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC]
On Tue, 11 Feb 2020 at 17:49, Dan Ackroyd wrote:
>
> Nicolas Grekas wrote:
> > I wish this would return a Closure instead, making $foo::function the
> > equivalent of Closure::fromCallable($foo).
>
> I didn't include the following in that RFC, because I thought it would
> be too controversial, but I think it's worth considering a new syntax
> for this.
>
> Given the code:
>
> function foo();
> class Zoq {
> public function Fot() {}
> public static function Pik() {}
> }
> $obj = new Zoq();
>
>
> Then these:
>
> $(foo);
> $($obj, Fot);
> $(Zoq, Fot);
>
> Would be equivalent to:
>
> Closure::fromCallable('foo');
> Closure::fromCallable([$obj, 'Fot']);
> Closure::fromCallable('Zoq::Fot'); or Closure::fromCallable(['Zoq', 'Fot']);
>
> Or similar.
>
> The justification for having a dedicated syntax is that I think
> readability is quite important in code, and it's reasonably common for
> me to have quite long lists of 'callables'.
>
> [Bar::class, foo1::function],
> [Bar::class, foo2::function],
> [Bar::class, foo3::function],
> [Bar::class, foo4::function]
>
> vs
>
> $(Bar, foo1),
> $(Bar, foo2),
> $(Bar, foo3),
> $(Bar, foo4)
>
> The latter is far easier to read for me.
>
> Nikita Popov wrote:
> > This would circumvent all the issues outlined in
> > https://wiki.php.net/rfc/consistent_callables.
>
> Probably there would still be some issues with some of the weird stuff
> happening internally in SPL related code where the deep horrors
> rest...but we can leave them alone...and they might not wake.
>
> cheers
> Dan
> Ack
Hi, Dan,
I like it, although syntax reminds me to JQuery syntax.
Thanks
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC]
On Tue, 11 Feb 2020 at 16:27, Levi Morrison
wrote:
>
> I have three immediate thoughts:
>
> 1. It should be `fn` or `function`; reserving a new word even if it's
> contextual is pointless here.
> 2. It should support methods.
> 3. It should return a closure, not a string. The reason is for
> consistency with methods, where we want to capture the scope at the
> time the closure is created, not ran. Imagine passing a private method
> as a callback; if it was done via `[$obj, 'privatemethod']` then it
> will fail at runtime, because the scope it's called in doesn't have
> access.
Hi, Levi,
1. Yes
2. Yes, I agree
3. Wouldn't it be the opposite?. E.g:
class Foo {
static function run_callable(callable $callable) {
$callable();
}
private static function private_function() {
echo "bar";
}
}
Foo::run_callable( [ 'Foo', 'private_function' ] );
Currently, this is valid. However, the following is fatal:
class Foo {
static function run_callable(callable $callable) {
$callable();
}
private static function private_function() {
echo "bar";
}
}
Foo::run_callable(Closure::fromCallable(['Foo', 'private_function']));
The same with functions. If "::function" would retrieve a closure,
some code could breaking
when people switch string function syntax( e.g: 'strlen' ) to
"::function" syntax( strlen::function ).
On other hand, other option is ::callable, This is different to
::function, because it would affect to other
callables, so that, returns could be other( Closure )
Re: [PHP-DEV] [RFC]
On Tue, 11 Feb 2020 at 15:51, Chase Peeler wrote:
>
>
>
> On Tue, Feb 11, 2020 at 8:19 AM Nikita Popov wrote:
>>
>> On Tue, Feb 11, 2020 at 1:43 PM Manuel Canga wrote:
>>
>> > On Tue, 11 Feb 2020 at 13:16, Nicolas Grekas
>> > wrote:
>> > >
>> > >
>> > >
>> > > Le mar. 11 févr. 2020 à 12:52, Diogo Galvao a écrit
>> > :
>> > >>
>> > >> On Tue, Feb 11, 2020 at 8:14 AM Manuel Canga
>> > wrote:
>> > >> >
>> > >> > Hi internals,
>> > >> > I Would like to present a possible new "::func resolution" for your
>> > >> > consideration.
>> > >> ...
>> > >> > use function \My\I18N\i18n_translate;
>> > >> >
>> > >> > $mapped_array = array_map(i18n_translate::func, $array);
>> > >> ...
>> > >> > What is your opinion ? Do you see it useful ?
>> > >>
>> > >> I've wished for this on many occasions and think it'd be really useful,
>> > as long
>> > >> as it could work with methods as well:
>> > >>
>> > >> $mapped_array = array_map(I18N::translate::function, $array);
>> > >>
>> > >> For what it's worth I guess it could just return [I18N::class,
>> > 'translate'].
>> > >
>> > >
>> > > I wish this would return a Closure instead, making $foo::function the
>> > equivalent of Closure::fromCallable($foo).
>> >
>> > Hi, Nicolas,
>> >
>> > Currently, when ::class is used, class with
>> > can or cannot exists in that moment.
>> > Using ::func( or ::function ), I think
>> > should keep the same behavior.
>> >
>> > Using ::func as alias of "Closure::fromCallable" check if function
>> > exists in that moment. It is certainly useful, but, I think it's more
>> > important be consistent
>> >
>>
>> Checking whether the function exists is really unavoidable for functions,
>> because you don't know whether
>>
>> namespace Foo;
>> var_dump(strlen::function);
>>
>> refers to 'Foo\strlen' or 'strlen', without first trying to look up the
>> former.
>>
>> I agree with Nicolas that this kind of feature would provide the most value
>> if it created a Closure. This would circumvent all the issues outlined in
>> https://wiki.php.net/rfc/consistent_callables.
>>
>> Regards,
>> Nikita
>
>
> Can anyone thing of a use-case where you would want a string name of a
> function and a callable would not be acceptable, besides possibly debugging
> code that said 'echo "I'm calling ".myfunction::function;'? Everything that I
> can think of that accepts a function name, also accepts a callable (e.g.
> array_map), but I could be forgetting something.
>
> If not, then I think it makes sense to return a callable. It might not be
> entirely consistent with the behavior of ::class, but, a class isn't entirely
> consistent with a method/function either, so I think there is some latitude
> for small differences.
>
> As for the ::func vs ::function. I think ::function is safer, since it's a
> reserved word. Otherwise you might run into issues with something like this:
>
> class foo {
> const func = "bar";
> }
>
> function foo(){}
>
> echo foo::func;
>
> Probably not something that happens very often, but, I think the 4 extra
> characters to prevent it would be worth it.
>
> --
> Chase Peeler
> chasepee...@gmail.com
Hi, Chase,
Yes, '::function' is better. I don't know because I thought 'func' was
used with short functions.
One case which string can be useful but a callable would not be acceptable is:
array_map([I18N::class, translate::function] );
Although it's true that can have side effects.
Thanks, Chase,
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC]
On Tue, 11 Feb 2020 at 14:19, Nikita Popov wrote: > > On Tue, Feb 11, 2020 at 1:43 PM Manuel Canga wrote: >> >> On Tue, 11 Feb 2020 at 13:16, Nicolas Grekas >> wrote: >> > >> > >> > >> > Le mar. 11 févr. 2020 à 12:52, Diogo Galvao a écrit : >> >> >> >> On Tue, Feb 11, 2020 at 8:14 AM Manuel Canga >> >> wrote: >> >> > >> >> > Hi internals, >> >> > I Would like to present a possible new "::func resolution" for your >> >> > consideration. >> >> ... >> >> > use function \My\I18N\i18n_translate; >> >> > >> >> > $mapped_array = array_map(i18n_translate::func, $array); >> >> ... >> >> > What is your opinion ? Do you see it useful ? >> >> >> >> I've wished for this on many occasions and think it'd be really useful, >> >> as long >> >> as it could work with methods as well: >> >> >> >> $mapped_array = array_map(I18N::translate::function, $array); >> >> >> >> For what it's worth I guess it could just return [I18N::class, >> >> 'translate']. >> > >> > >> > I wish this would return a Closure instead, making $foo::function the >> > equivalent of Closure::fromCallable($foo). >> >> Hi, Nicolas, >> >> Currently, when ::class is used, class with >> can or cannot exists in that moment. >> Using ::func( or ::function ), I think >> should keep the same behavior. >> >> Using ::func as alias of "Closure::fromCallable" check if function >> exists in that moment. It is certainly useful, but, I think it's more >> important be consistent > > > Checking whether the function exists is really unavoidable for functions, > because you don't know whether > > namespace Foo; > var_dump(strlen::function); > > refers to 'Foo\strlen' or 'strlen', without first trying to look up the > former. > > I agree with Nicolas that this kind of feature would provide the most value > if it created a Closure. This would circumvent all the issues outlined in > https://wiki.php.net/rfc/consistent_callables. > > Regards, > Nikita Thanks, Nikita. I don't know that RFC. In that case, why don't use ::callable ?. This will be useful for functions and others callable. E.g: enqueue_task([I18n::class, 'translate']::callable); enqueue_task(translate::callable); Would it be hard to implement in PHP ? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC]
Ups!. What big mistake! Then ::function should be a better option. Thanks, Guilliam, On Tue, 11 Feb 2020 at 13:47, Guilliam Xavier wrote: > > Hi, > > On Tue, Feb 11, 2020 at 1:09 PM Manuel Canga wrote: > > > > I was thinking about 'function' or 'func'. 'function' is more > > semantic, but 'func' is used with "short functions"( PHP 7.4 ) and > > these will be used for callbacks. Then I think 'func' will be more > > consistent. > > Actually PHP 7.4's short closures / array functions use `fn`, not `func`. > But `::fn` would look... weird. > I agree with Diogo that `::function` would be more consistent. > > -- > Guilliam Xavier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC]
On Tue, 11 Feb 2020 at 13:16, Nicolas Grekas wrote: > > > > Le mar. 11 févr. 2020 à 12:52, Diogo Galvao a écrit : >> >> On Tue, Feb 11, 2020 at 8:14 AM Manuel Canga wrote: >> > >> > Hi internals, >> > I Would like to present a possible new "::func resolution" for your >> > consideration. >> ... >> > use function \My\I18N\i18n_translate; >> > >> > $mapped_array = array_map(i18n_translate::func, $array); >> ... >> > What is your opinion ? Do you see it useful ? >> >> I've wished for this on many occasions and think it'd be really useful, as >> long >> as it could work with methods as well: >> >> $mapped_array = array_map(I18N::translate::function, $array); >> >> For what it's worth I guess it could just return [I18N::class, 'translate']. > > > I wish this would return a Closure instead, making $foo::function the > equivalent of Closure::fromCallable($foo). Hi, Nicolas, Currently, when ::class is used, class with can or cannot exists in that moment. Using ::func( or ::function ), I think should keep the same behavior. Using ::func as alias of "Closure::fromCallable" check if function exists in that moment. It is certainly useful, but, I think it's more important be consistent Thanks, Nicolas, -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC]
Hi, Diogo That's right. I could be useful with classes as well. I was thinking about 'function' or 'func'. 'function' is more semantic, but 'func' is used with "short functions"( PHP 7.4 ) and these will be used for callbacks. Then I think 'func' will be more consistent. Thanks, Diogo, On Tue, 11 Feb 2020 at 12:51, Diogo Galvao wrote: > > On Tue, Feb 11, 2020 at 8:14 AM Manuel Canga wrote: > > > > Hi internals, > > I Would like to present a possible new "::func resolution" for your > > consideration. > ... > > use function \My\I18N\i18n_translate; > > > > $mapped_array = array_map(i18n_translate::func, $array); > ... > > What is your opinion ? Do you see it useful ? > > I've wished for this on many occasions and think it'd be really useful, as > long > as it could work with methods as well: > > $mapped_array = array_map(I18N::translate::function, $array); > > For what it's worth I guess it could just return [I18N::class, 'translate']. > > Also for keeping consistency and avoiding new keywords wouldn't it fit better > as > ::function instead of ::func? > > > Best regards. > Diogo -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC]
Hi Tom,
I thought about that short version. However, in order to avoid
conflicts with constants, I chosen "::func". If this is not problem in
low level of PHP, then I agree with you in shorter version is better.
Thanks for your opinion, Tom
On Tue, 11 Feb 2020 at 12:33, Tom Gerrits wrote:
>
> Hi Manuel
>
> Thanks for bringing this idea forward.
>
> Adding a non-string construct to reference functions uniquely seems
> like a good idea and would be consistent with the existing ::class
> keyword for classes.
>
> I'm wondering if it would be useful to take a page out of the book of
> other programming languages in order to shorten the notation further:
>
> > // First file.
> > namespace A\B;
> >
> > function foo() { }
> >
> > // Second file.
> > use function A\B\foo;
> >
> > function bar(callable $c) { }
> >
> >
> > // Current approach.
> > bar('\A\B\foo');
> >
> > // Notation without parantheses, references imported function.
> > // Similarly, in the future, Class::method could reference a
> > // class method.
> > bar(foo);
> >
> > // Notation with references, could be expanded in the future
> > // for static class methods, such as ::method.
> > bar();
>
> The second example can already be achieved by defining your own
> constant that references the fully qualified name and importing it.
> However, an explicit, separate, import of these constants is still
> needed, which is not ideal.
>
> A suffix "::func" would also be useful, but allowing shorter notation
> would improve readability when using the functional programming
> paradigm and composing functions.
>
> Op di, feb 11, 2020 at 12:13 schreef Manuel Canga
> :
> > Hi internals,
> > I Would like to present a possible new "::func resolution" for your
> > consideration.
> >
> > In first place, PHP now support "::class" in this way:
> >
> > use My\I18N;
> >
> > $mapped_array = array_map([I18N::class, 'translate'], $array);
> > It avoid add Full I18N namespace in callback.
> >
> > However with functions is different:
> >
> > use function \My\I18N\i18n_translate;
> >
> > $mapped_array = array_map('\My\I18N\i18n_translate', $array);
> >
> > What is the useful here of importing the function?.
> > My proposal is ":func" in order to avoid full namespace in callback of
> > functions. E.g:
> >
> > use function \My\I18N\i18n_translate;
> >
> > $mapped_array = array_map(i18n_translate::func, $array);
> >
> > "::func" should validate if a function with `` is
> > imported.
> > In this case, "::func" is replaced with FQN of this function,
> > otherwise with only ""
> >
> > What is your opinion ? Do you see it useful ?
> >
> > Thanks and I'm sorry for my English( I'm a Spanish ).
> >
> > Regards
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] ::func resolution for functions
I'm sorry. I forgot subject due to nerves. I add it.
On Tue, 11 Feb 2020 at 12:13, Manuel Canga wrote:
>
> Hi internals,
> I Would like to present a possible new "::func resolution" for your
> consideration.
>
> In first place, PHP now support "::class" in this way:
>
> use My\I18N;
>
> $mapped_array = array_map([I18N::class, 'translate'], $array);
> It avoid add Full I18N namespace in callback.
>
> However with functions is different:
>
> use function \My\I18N\i18n_translate;
>
> $mapped_array = array_map('\My\I18N\i18n_translate', $array);
>
> What is the useful here of importing the function?.
> My proposal is ":func" in order to avoid full namespace in callback of
> functions. E.g:
>
> use function \My\I18N\i18n_translate;
>
> $mapped_array = array_map(i18n_translate::func, $array);
>
> "::func" should validate if a function with `` is imported.
> In this case, "::func" is replaced with FQN of this function,
> otherwise with only ""
>
> What is your opinion ? Do you see it useful ?
>
> Thanks and I'm sorry for my English( I'm a Spanish ).
>
> Regards
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC]
Hi internals,
I Would like to present a possible new "::func resolution" for your
consideration.
In first place, PHP now support "::class" in this way:
use My\I18N;
$mapped_array = array_map([I18N::class, 'translate'], $array);
It avoid add Full I18N namespace in callback.
However with functions is different:
use function \My\I18N\i18n_translate;
$mapped_array = array_map('\My\I18N\i18n_translate', $array);
What is the useful here of importing the function?.
My proposal is ":func" in order to avoid full namespace in callback of
functions. E.g:
use function \My\I18N\i18n_translate;
$mapped_array = array_map(i18n_translate::func, $array);
"::func" should validate if a function with `` is imported.
In this case, "::func" is replaced with FQN of this function,
otherwise with only ""
What is your opinion ? Do you see it useful ?
Thanks and I'm sorry for my English( I'm a Spanish ).
Regards
