[PHP-DEV] Re: [RFC][DISCUSSION] PHP Namespace in core

[Michał Brzuchalski]

Hi Internals,

I'm really sorry for the long delay on this topic.

I think it's time to vote since there seems like no further discussion is
needed.

*So head's up!* I plan to open this topic for a vote.
The vote will be simple Yes/No and requires to be accepted by 2/3 votes as
always.

Voting will open Tomorrow on *May 22nd around 06:00 UTC*
and will remain open for 14 days until *4th of June.*

Cheers,
--
Michał Marcin Brzuchalski
/For the fame and glory of PHP!!/


śr., 15 kwi 2020 o 14:29 Michał Brzuchalski 
napisał(a):

> Hi internals,
>
> I hope you're doing well.
>
> I'd like to announce the PHP Namespace in core RFC for discussion.
> The RFC is authored by me together with George Peter Banyard and it's
> purpose
> is nothing more like to allow the use of PHP Namespace in the core.
>
> The RFC is described at https://wiki.php.net/rfc/php-namespace-in-core
>
> Best Regards,
> Michał Brzuchalski
>

Re: [PHP-DEV] Draft RFC callable types + callable type/function autoloading

[tyson andre]

Hi Dan Ackroyd,

> I'd be happy to see function autoloading support in php overall.
> It'd help in avoiding loading unnecessary polyfills,
> or in large codebases with many global functions that are only occasionally 
> used.

I forgot, but I'd also started the thread https://externals.io/message/107967 
("Autoloading functions/consts without a performance impact") 5 months ago,
and got sidetracked looking into ways to reduce ambiguity in calls to functions.
It might have been a better idea for me to start a straw poll instead of that,
but I didn't know how representative initial feedback was,
and I'm no longer working on autoloading.

Some of the messages might be relevant for the "Discussions" section of an RFC.

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

Re: [PHP-DEV] Draft RFC callable types + callable type/function autoloading

[tyson andre]

Hi Dan Ackroyd,

> Function + callable type autoloading
> https://github.com/Danack/FunctionTypes/blob/master/2_autoloading_part_2.md

I'd be happy to see function autoloading support in php overall.
It'd help in avoiding loading unnecessary polyfills, or in large codebases with 
many global functions that are only occasionally used.

Autoloading functions involves a lot of tradeoffs due to design choices in PHP.
I've seen a lot of different opinions - It might be worth setting up a straw 
poll for whether people would be interested in the change, unless you expect 
the php 8 implementation to be easy.
(though straw polls have much lower response rates than RFCs)

- Functions can be added to a namespace after they get added to the global 
scope.
- A lot of namespaced php code refers to functions ambiguously
(`namespace Foo; echo strlen($x);` can either refer to `strlen()` or 
`Foo\strlen`).
  What were your plans for handling ambiguous calls?
  I was in favor of checking if either existed (current behavior) before 
autoloading `Foo\strlen`, then before autoloading `strlen`, to keep performance 
acceptable.
  Others preferred various alternate approaches to autoloading.
  I don't think there was ever a straw poll to measure how common other 
opinions were,
  or if people would accept a given approach despite having a preference for 
something else.

The alternatives I can imagine/remember from previous RFC discussions, *none of 
which I hold* 
(https://wiki.php.net/rfc/use_global_elements#deprecate_the_fallback_to_the_root_namespace_instead
 and below had somewhat related discussion as an attempt to reduce ambiguity):

- The exact way to deal with ambiguity when autoloading, e.g. "autoload 
Foo\strlen() every single time strlen() is called" (I object because that would 
harm performance significantly)
- You should make calling static methods easier (doesn't help with a lot of 
internal functionality like strlen() or polyfills for PECL functions are global 
functions)

Other thoughts:

- Maybe it would be useful/practical to initially *just* support autoloading 
functions when they're passed to function_exists($name, autoload: true) or 
autoload_function($name).
  I don't remember if that approach was suggested before.
  Then again, I'd personally want something more powerful than that due to the 
inconvenience, and I imagine most people would.

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

[PHP-DEV] Reserved words and class name collisions

[Jakob Givoni]

Hello,

It's a common thing to want to introduce a new keyword as a reserved
word as part of an RFC.
(Recently: match, mixed, guard, readonly...)

These new keywords always lead to possible BC breaking changes because
they become unusable for namespaces, class names, function names and
global constants.

This may sound frivolous, but has it been considered to try to find a
way to make it possible to have some classes of language keywords and
identical class names etc. living side by side?

One thing I could think of is to allow prefixing either new keywords
or conflicting class names with a special character whenever there is
a possibility of ambiguity in the syntax.

Let's take an example - I've always wanted to name a class "Function"
:-) It would live in a namespace, f.ex. \App\Middleware\Function. I
don't really see how declaring the class Function or using the fully
qualified class name could be an insurmountable obstacle to
distinguish from the keyword used to declare a function.
However, if you're already in the \App\Middleware namespace and just
find the untethered Function in the code, that would not be nice to
the parser. But if we prefixed it with .\Function the confusion would
evaporate, wouldn't it?

This idea would not eliminate this kind of Backward Incompatible
Changes but the upgrade path to simply prefix the class name etc. with
.\ or something else, whenever it was found out and alone, would cause
a lot less friction that renaming files and classes. And as such it
just might lead to more, otherwise nice RFC's being accepted :-)

If this sparks some interest, let me know. Or rather, tell me please
in a mild tone why this would be a total disaster.

Best regards,
Jakob

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

Re: [PHP-DEV] [RFC] Amendments to Attributes

[Benjamin Eberlei]

On Wed, May 20, 2020 at 7:53 PM Ben Ramsey  wrote:

> > On May 20, 2020, at 12:07, Benjamin Eberlei  wrote:
> >
> > 2. Rename PhpAttribute to Attribute in global namespace (independent of
> the
> > namespace RFC)
>
>
> I suggested in a previous thread that we consider renaming `PhpAttribute`
> to `UserlandAttribute`, since this is the intent of the attribute, and it
> helps distinguish it from `CompilerAttribute`.
>
> I noticed that the compiler attribute is actually named
> `PhpCompilerAttribute`, so unless we change its name to
> `CompilerAttribute`, I don’t think it makes sense to change `PhpAttribute`
> to `Attribute`. Perhaps we change it to `PhpUserlandAttribute`, for clarity?
>

Ah that's a good point that still needs to be clarified. We realized that
PhpAttribute and PhpCompilerAttribute should be merged, because the
difference doesn't make a difference to userland code and it complicates
things. For example enforcing that PhpCompilerAttribute is just on internal
classes would not work for generated stub code in Phan/Psalm and so on that
"describe" internal code by imitating it in userland. This would not be
allowed by the current implementation and lead to a compiler error, lets
say if we imitated Deprecated for documentation purposes:

>
class Deprecated {}

This file could not be compiled by current implementation as an error would
prevent Userland Deprecated class from using PhpCompilerAttribute.

>
> Cheers,
> Ben
>

Re: [PHP-DEV] [RFC] Amendments to Attributes

[Benas IML]

Hello,

Would it possible to make a separate RFC for renaming `PhpAttribute` to
`Attribute` and `PhpCompilerAttribute` to `CompilerAttribute`? Since it
would a huge BC break changing this in PHP 8.1.

Best regards,
Benas Seliuginas

Re: [PHP-DEV] [RFC] Amendments to Attributes

[Benjamin Eberlei]

On Wed, May 20, 2020 at 7:37 PM Marco Pivetta  wrote:

> Hey Benjamin,
> 
>
>
> On Wed, May 20, 2020 at 7:08 PM Benjamin Eberlei 
> wrote:
>
>> Hi everyone,
>>
>> the Attributes RFC was rather large already, so a few things were left
>> open
>> or discussions during the vote have made us rethink a things.
>>
>> https://wiki.php.net/rfc/attribute_amendments
>>
>> These points are handled by the Amendments RFC to Attributes:
>>
>> 1. Proposing to add a grouped syntax <
>> 2. Rename PhpAttribute to Attribute in global namespace (independent of
>> the
>> namespace RFC)
>> 3. Add validation of attribute class targets, which internal attributes
>> can
>> do, but userland can't
>> 4. Specification if an attribute is repeatable or not on the same
>> declaration and fail otherwise.
>>
>> Each of them is a rather small issue, so I hope its ok to aggregate all
>> four of them in a single RFC. Please let me know if it's not.
>>
>
>
> Do you hope to get nested attributes to 8.0, or is it something you'd
> prefer to happen at a later time?
>

Martin evaluated the technical requirements in more detail and we discussed
with others that the timeframe is probably to short to get all the details
fleshed out :-( So we are going to table that for 8.1

>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>

Re: [PHP-DEV] [RFC] Amendments to Attributes

[Benas IML]

Hey,

I personally think that `UserlandAttribute` is too verbose and a quite
useless change since just using `Attribute` will make little to no BC
compatibility breaks (we know that thanks to Rowan, please check out
Renaming PhpAttribute thread) and would also sound more natural. This would
also mean that we would rename `PhpCompilerAttribute` to simply
`CompilerAttribute`.


Best regards,
Benas Seliuginas

Re: [PHP-DEV] [RFC] Amendments to Attributes

[Ben Ramsey]

> On May 20, 2020, at 12:07, Benjamin Eberlei  wrote:
> 
> 2. Rename PhpAttribute to Attribute in global namespace (independent of the
> namespace RFC)


I suggested in a previous thread that we consider renaming `PhpAttribute` to 
`UserlandAttribute`, since this is the intent of the attribute, and it helps 
distinguish it from `CompilerAttribute`.

I noticed that the compiler attribute is actually named `PhpCompilerAttribute`, 
so unless we change its name to `CompilerAttribute`, I don’t think it makes 
sense to change `PhpAttribute` to `Attribute`. Perhaps we change it to 
`PhpUserlandAttribute`, for clarity?

Cheers,
Ben


signature.asc
Description: Message signed with OpenPGP

Re: [PHP-DEV] [RFC] Amendments to Attributes

[Larry Garfield]

On Wed, May 20, 2020, at 12:07 PM, Benjamin Eberlei wrote:
> Hi everyone,
> 
> the Attributes RFC was rather large already, so a few things were left open
> or discussions during the vote have made us rethink a things.
> 
> https://wiki.php.net/rfc/attribute_amendments
> 
> These points are handled by the Amendments RFC to Attributes:
> 
> 1. Proposing to add a grouped syntax <

I'm torn here.  I can absolutely see the use cases for it, but it also is a can 
of worms in terms of many different coding styles.  In short, this is going to 
make more work for FIG to sort out.

> 2. Rename PhpAttribute to Attribute in global namespace (independent of the
> namespace RFC)

I don't feel strongly enough in any direction to bother wading into this... :-)

> 3. Add validation of attribute class targets, which internal attributes can
> do, but userland can't
> 4. Specification if an attribute is repeatable or not on the same
> declaration and fail otherwise.

It's not clear from the RFC what the failure mode is.  If I put an attribute in 
the wrong place, or repeat it when I shouldn't... at what point does the code 
blow up and how?  Does it get silently skipped somewhere?  Is there an 
exception?  Is it purely informational for the user processing it?

The RFC needs to be clearer on what happens when validation fails.  Even if 
that's repeating something from the original RFC, it needs to be clarified here 
so that we know what we're talking about.

--Larry Garfield

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

Re: [PHP-DEV] [RFC] Amendments to Attributes

[Marco Pivetta]

Hey Benjamin,



On Wed, May 20, 2020 at 7:08 PM Benjamin Eberlei 
wrote:

> Hi everyone,
>
> the Attributes RFC was rather large already, so a few things were left open
> or discussions during the vote have made us rethink a things.
>
> https://wiki.php.net/rfc/attribute_amendments
>
> These points are handled by the Amendments RFC to Attributes:
>
> 1. Proposing to add a grouped syntax <
> 2. Rename PhpAttribute to Attribute in global namespace (independent of the
> namespace RFC)
> 3. Add validation of attribute class targets, which internal attributes can
> do, but userland can't
> 4. Specification if an attribute is repeatable or not on the same
> declaration and fail otherwise.
>
> Each of them is a rather small issue, so I hope its ok to aggregate all
> four of them in a single RFC. Please let me know if it's not.
>


Do you hope to get nested attributes to 8.0, or is it something you'd
prefer to happen at a later time?

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

[PHP-DEV] [RFC] Amendments to Attributes

[Benjamin Eberlei]

Hi everyone,

the Attributes RFC was rather large already, so a few things were left open
or discussions during the vote have made us rethink a things.

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

These points are handled by the Amendments RFC to Attributes:

1. Proposing to add a grouped syntax <
2. Rename PhpAttribute to Attribute in global namespace (independent of the
namespace RFC)
3. Add validation of attribute class targets, which internal attributes can
do, but userland can't
4. Specification if an attribute is repeatable or not on the same
declaration and fail otherwise.

Each of them is a rather small issue, so I hope its ok to aggregate all
four of them in a single RFC. Please let me know if it's not.

greetings
Benjamin

[PHP-DEV] Draft RFC callable types + callable type/function autoloading

[Dan Ackroyd]

Hi internals,

A while ago, I spent some time thinking about callables, and how they
are not very consistent, which makes people sad:
https://wiki.php.net/rfc/consistent_callables

The reason I didn't pursue that RFC is that although tidying up PHP
core to be more consistent would be nice, it would be a large amount
of work, that wouldn't dramatically improve the developer experience
when programming in PHP. In fact it would mostly just break otherwise
working code.

What would be better would be an RFC to make callables be more useful,
specifically by allowing you to define the parameter and return types
for them. Making it possible to autoload those types would be
required, and function autoloading is also a feature that has been
desired for a while.

So here are two draft RFCs:

Callable types
https://github.com/Danack/FunctionTypes/blob/master/1_callable_type_rfc.md

Function + callable type autoloading
https://github.com/Danack/FunctionTypes/blob/master/2_autoloading_part_2.md

I'll leave them on github for the moment, as it is easier to do PRs
and track issues there but I wanted to gather initial feedback before
getting closer to the RFC cutoff date.

I'll move them to the wiki and formally submit them for discussion
when the implementation is closer to being done.

cheers
Dan
Ack

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

[PHP-DEV] Fwd: PHP RFC about variables

[Глеб Жуков]

-- Forwarded message -
От: Глеб Жуков 
Date: ср, 20 мая 2020 г. в 16:10
Subject: PHP RFC about variables
To: 


If you look at Wikipedia, you can see that a variable in programming is a
named, or otherwise addressed, area of memory whose address can be used to
access data. The word from this definition to which I would like to draw
your attention is data.Is it really so that in PHP and other
programming languages in which we write, variables are used only for
accessing data.   In fact, in addition to access   data, variables are also
used to access objects, arrays and some other things.   Data (strings,
integers, floating-point numbers, boolean values), objects and structures
(arrays) for a human are essentially different entities (abstractions), and
it would be reasonable to handle them as different things, ignoring the
fact that for the machine they are the same (named memory areas).   In
order to do this, I would like to propose (once again) to start to use
entities  such as, for example: object, structure, data  instead of
variables . This will help to greatly simplify the perception of the code,
because you no longer have to keep in mind the data types of most
variables.  Code:

// If formerly, for example, to store objects in PHP,
// we used variables that are declared in the current syntax using the $
symbol
$objectVar = new SomeClass();

// Now for the objects we will have a special entity “object”,
// which, for example, will be declared using the * symbol *objectEntity =
new SomeClass(); // "Structure" entities will be declared using ^
symbol ^simpleArray
= ['one', 'two', 'three'];
^associativeArray = ['key' => 'val', 'another_key' => 'another_val'];

// And "data" entities using symbol %

%string = 'abcde';
%integer = 123;
%floating = 1.23;
%boolean = true;

I want to make one point right away - my concept has nothing to do with the
concept that is used in the PERL programming language, where each data type
has a separate character. I urge only to enter one symbol for all scalar
types, one symbol for objects and one for structures (arrays). The
variables themselves and the symbol that is used to denote them ($) can be
left for backward compatibility, as well as for types that are not covered
by the new entities described by me, one of such types, for example,
resource.


The last time I proposed my idea for RFC, they refused me because
allocating three new characters to implement it would be too wasteful. I do
not deny that the remaining available characters should be used wisely. But
in my opinion, in this case, the allocation of three new characters is
quite justified by substantial benefits that this innovation brings. And
due to the limited number of characters at the present time, it seems to me
unreasonable to refuse futher progress.

[PHP-DEV] PHP RFC about variables

[Глеб Жуков]

If you look at Wikipedia, you can see that a variable in programming is a
named, or otherwise addressed, area of memory whose address can be used to
access data. The word from this definition to which I would like to draw
your attention is data.Is it really so that in PHP and other
programming languages in which we write, variables are used only for
accessing data.   In fact, in addition to access   data, variables are also
used to access objects, arrays and some other things.   Data (strings,
integers, floating-point numbers, boolean values), objects and structures
(arrays) for a human are essentially different entities (abstractions), and
it would be reasonable to handle them as different things, ignoring the
fact that for the machine they are the same (named memory areas).   In
order to do this, I would like to propose (once again) to start to use
entities  such as, for example: object, structure, data  instead of
variables . This will help to greatly simplify the perception of the code,
because you no longer have to keep in mind the data types of most variables.
Code:

// If formerly, for example, to store objects in PHP, // we used variables
that are declared in the current syntax using the $ symbol $objectVar = new
SomeClass(); // Now for the objects we will have a special entity “object”, //
which, for example, will be declared using the * symbol *objectEntity = new
SomeClass(); // "Structure" entities will be declared using ^ symbol
^simpleArray = ['one', 'two', 'three']; ^associativeArray = ['key' => 'val',
'another_key' => 'another_val']; // And "data" entities using symbol %
%string = 'abcde'; %integer = 123; %floating = 1.23; %boolean = true;

I want to make one point right away - my concept has nothing to do with the
concept that is used in the PERL programming language, where each data type
has a separate character. I urge only to enter one symbol for all scalar
types, one symbol for objects and one for structures (arrays). The
variables themselves and the symbol that is used to denote them ($) can be
left for backward compatibility, as well as for types that are not covered
by the new entities described by me, one of such types, for example,
resource.

The last time I proposed my idea for RFC, they refused me because
allocating three new characters to implement it would be too wasteful. I do
not deny that the remaining available characters should be used wisely. But
in my opinion, in this case, the allocation of three new characters is
quite justified by substantial benefits that this innovation brings. And
due to the limited number of characters at the present time, it seems to me
unreasonable to refuse futher progress.