Re: [PHP-DEV] [RFC] [Discussion] new MyClass()->method() without parentheses
On Mon, Apr 8, 2024 at 3:11 AM Valentin Udaltsov <
udaltsov.valen...@gmail.com> wrote:
> Hello internals,
>
>
> I would like to propose a syntax change for PHP 8.4 that allows to
> immediately access instantiated objects without wrapping the expression
> into parentheses.
>
>
> This was requested and discussed several times, see:
>
> - https://externals.io/message/66197
>
> - https://bugs.php.net/bug.php?id=70549
>
> - https://externals.io/message/101811
>
> - https://externals.io/message/113953
>
>
> Here's what you will be able to write after this change:
>
> ```php
>
> class MyClass
>
> {
>
> const CONSTANT = 'constant';
>
> public static $staticProperty = 'staticProperty';
>
> public static function staticMethod(): string { return
> 'staticMethod'; }
>
> public $property = 'property';
>
> public function method(): string { return 'method'; }
>
> public function __invoke(): string { return '__invoke'; }
>
> }
>
>
> var_dump(
>
> new MyClass()::CONSTANT,// string(8) "constant"
>
> new MyClass()::$staticProperty, // string(14) "staticProperty"
>
> new MyClass()::staticMethod(), // string(12) "staticMethod"
>
> new MyClass()->property,// string(8) "property"
>
> new MyClass()->method(),// string(6) "method"
>
> new MyClass()(),// string(8) "__invoke"
>
> );
>
> ```
>
>
> For more details see the RFC:
> https://wiki.php.net/rfc/new_without_parentheses
>
> Implementation: https://github.com/php/php-src/pull/13029
>
>
> --
>
> Best regards, Valentin
>
Yes, please!
--
Marco Deleu
Re: [PHP-DEV] [RFC][Concept] Data classes (a.k.a. structs)
On Tue, Apr 2, 2024 at 1:47 PM Larry Garfield wrote: > > * Data classes protect from interior mutability. More concretely, > > mutating nested data objects stored in a `readonly` property is not > > legal, whereas it would be if they were ordinary objects. > > * In the future, it should be possible to allow using data classes in > > `SplObjectStorage`. However, because hashing is complex, this will be > > postponed to a separate RFC. > > Would data class properties only be allowed to be other data classes, or > could they hold a non-data class? My knee jerk response is they should be > data classes all the way down; the only counter-argument I can think of it > would be how much existing code is out there that is a "data class" in all > but name. I still fear someone adding a DB connection object to a data > class and everything going to hell, though. :-) > If there is a class made up of 90% data struct and 10% non-data struct, the 90% could be extracted into a true data struct and be referenced in the existing regular class, making it even more organized in terms of establishing what's "data" and what's "service". I would really favor making it "data class" all the way down. I understand you disagree with the argument against inheritance, but to me the same logic applies here. Making it data class only allows for lifting the restriction in the future, if necessary (requiring another RFC vote). Making it mixed on version 1 means that support for the mixture of them can never be undone. -- Marco Deleu
Re: [PHP-DEV] [RFC][Concept] Data classes (a.k.a. structs)
her this is useful for > PHP. > * Data classes protect from interior mutability. More concretely, > mutating nested data objects stored in a `readonly` property is not > legal, whereas it would be if they were ordinary objects. > * In the future, it should be possible to allow using data classes in > `SplObjectStorage`. However, because hashing is complex, this will be > postponed to a separate RFC. > > One known gotcha is that we cannot trivially enforce placement of > `modfying` on methods without a performance hit. It is the > responsibility of the user to correctly mark such methods. > > Here's a fully functional PoC, excluding JIT: > https://github.com/php/php-src/pull/13800 > > Let me know what you think. I will start working on an RFC draft once > work on property hooks concludes. > > Ilija > Looking forward to this!!! -- Marco Deleu
Re: [PHP-DEV] Proposal: AS assertions
Marco Deleu > On 19 Mar 2024, at 14:51, Ilija Tovilo wrote: > > Hi Robert > >> On Tue, Mar 19, 2024 at 5:24 PM Robert Landers >> wrote: >> >> I've been thinking about this as an RFC for awhile, but with generics >> being far off (if at all), I'd like to propose a useful idea: reusing >> the AS keyword in a different context. >> >> Example: >> >> $x = $attributeReflection->newInstance() as MyAttribute; >> >> This would essentially perform the following code: >> >> assert(($x = $attributeReflection->newInstance()) instanceof MyAttribute); > > See https://wiki.php.net/rfc/pattern-matching#throwing_alternative. I > believe this idea would combine nicely with pattern matching. It has > many more uses there than just simple class type matching, and could > even be used for things like destructuring. > > Ilija That looks like a PHP dream. Has there been any work regarding that?
Re: [PHP-DEV] Proposal: AS assertions
On Tue, Mar 19, 2024 at 1:42 PM Marco Pivetta wrote: > One note: if what you are going for is what `azjezz/psl`, be aware that > exception / error tracing design needs special attention here: it's not as > simple as it looks! > I believe you answered your own question here. The proposal seems far simpler and reaches 100% of PHP projects as opposed to the ones that either opt to use psalm or opt to use azjezz/psl. -- Marco Deleu
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
On Thu, Feb 22, 2024 at 8:25 AM tag Knife wrote:
> A few things i was interested to get the idea around.
> Was it thought about for the set{} for it to return the value to set the
> property to
> instead implicitly setting its own field?
>
> eg
>
> ```
> public string $name {
> set {
> return usfirst($value);
> }
> }
> ```
> Where the value returned in the set is what the property will be set to?
>
The answer to this question is best described on the RFC FAQ:
https://wiki.php.net/rfc/property-hooks#why_do_set_hooks_not_return_the_value_to_set
--
Marco Deleu
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
On Wed, Feb 21, 2024 at 3:58 PM Larry Garfield
wrote:
> Hello again, fine Internalians.
>
> After much on-again/off-again work, Ilija and I are back with a more
> polished property access hooks/interface properties RFC. It’s 99%
> unchanged from last summer; the PR is now essentially complete and more
> robust, and we were able to squish the last remaining edge cases.
>
> Baring any major changes, we plan to bring this to a vote in mid-March.
>
> https://wiki.php.net/rfc/property-hooks
>
> It’s long, but that’s because we’re handling every edge case we could
> think of. Properties involve dealing with both references and inheritance,
> both of which have complex implications. We believe we’ve identified the
> most logical handling for all cases, though.
>
> Note the FAQ question at the end, which explains some design choices.
>
> There’s one outstanding question, which is slightly painful to ask:
> Originally, this RFC was called “property accessors,” which is the
> terminology used by most languages. During early development, when we had
> 4 accessors like Swift, we changed the name to “hooks” to better indicate
> that one was “hooking into” the property lifecycle. However, later
> refinement brought it back down to 2 operations, get and set. That makes
> the “hooks” name less applicable, and inconsistent with what other
> languages call it.
>
> However, changing it back at this point would be a non-small amount of
> grunt work. There would be no functional changes from doing so, but it’s
> lots of renaming things both in the PR and the RFC. We are willing to do so
> if the consensus is that it would be beneficial, but want to ask before
> putting in the effort.
>
> --
> Larry Garfield
> la...@garfieldtech.com
>
This is a long, huge and comprehensive work, congratz to the authors.
It clearly shows that so much thought and work has been put into it that it
makes me cautious to even ask for further clarification.
> Javascript have similar features via a different syntax, although that
syntax would not be viable for PHP
Why not?
```
final class Foo
{
public string $bar;
public function get bar(): string
{
// custom getter
}
public function set bar(string $value): void
{
// custom setter
}
}
```
It feels quite a natural syntax for PHP and from someone oblivious to the
internal work, it appears to be a slight marginal change to the existing
RFC. Given the extensive work of this RFC, it seems pretty obvious that
this syntax will not work, I just don't know why.
--
Marco Deleu
Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs
On Fri, Jan 5, 2024 at 9:40 AM Michał Marcin Brzuchalski <
michal.brzuchal...@gmail.com> wrote:
> There are indeed dozens of libraries already working with PSR nicely but
> IMHO
> the API should provide all the necessary information in a way that allows
> the construction of such objects,
> but suggesting PSR with request/response objects will limit the
> capabilities of worker mode API
> to handle pure HTTP protocol only.
>
> What I'd like to say is that I believe for the initial proposal of any
> eventual worker mode API
> with the PSR with request/response objects should not be considered at all.
>
> Cheers
>
I think it's been mentioned quite a few times that it doesn't matter what
gets passed to the callable function that hands over control to userland,
as long as it's more functional-style and not superglobals. I also think
that there's merit in both sides of the conversation between PSR-7 vs
associative arrays, but I find it more important to get one of them, any of
them and not halt for one or the other. PSR would make it HTTP-only, yes,
but that largely benefits the PHP ecosystem to an extent order of magnitude
larger than any non-HTTP format. On the other hand, being a dynamically
typed language, nothing holds us from having a more simple/generic
`function handler(mixed $event)` format which can also be used to process
HTTP and non-HTTP events.
I do prefer the more generic one as I would be interested in seeing what
PHP would become with the capability of processing non-HTTP protocols made
easier. That being said, I find it important to consider the quality of
such an API for its users. It would end up forcing users to do the
following:
```
function handler(mixed $event) {
if (isset($event['_REQUEST'])) {
// We are on HTTP Protocol
}
if (isset($event['...'])) {
// This is a Websocket
}
}
```
If the original proposal is correct and/or my little understanding of this
thread is somewhat in the right direction, it means that the introduction
of a PHP function that asks its engine for the next event to process isn't
a huge amount of work on PHP Internals. If that's true, I would ask that we
consider making something more flexible / forgiving of errors / adjustable
and evolution-friendly. Instead of striving so much for coming up with one
perfect API that shall be the one true API for PHP for the next decade, we
can instead consider the possibility of having multiple small APIs that can
harmonically coexist. Example:
Classic:
```
$classicHttpHandler = function (array $get, array $post, array $request,
array $server, array $cookies): string|Stringable {
// process incoming request in a somewhat backward-compatible friendly
way
return 'http response'; // Return the response similarly to how we used
to `echo` it to the server.
}
worker_http_classic($classicHttpHandler);
```
PSR-7:
```
$httpMiddlewareHandler = function (\Psr\Http\Message\RequestInterface
$request): \Psr\Http\Message\ResponseInterface {
// Process Request
}
worker_http_psr7($httpMiddlewareHandler);
```
HTTP Raw
```
$httpHandler = function (\Psr\Http\Message\StreamInterface $raw):
\Psr\Http\Message\ResponseInterface {
// Process Request
}
worker_http_raw($httpHandler);
```
STDIN
```
$stdinHandler = function (SomeStdinCompatibleType $stdin):
SomeStdoutCompatibleType {
}
worker_stdin($stdinHandler);
```
Websocket
```
$websocketHandler = function (string $event, mixed $data): ??? {
// Process websocket incoming event
}
worker_websocket_event($httpHandler);
```
These APIs don't need to be ready on day one. They don't even need to be
ready at all, actually. Each would end up being its own RFC. What makes the
system a bit more. flexible is the api naming which follows the pattern PHP
Engine Namespace (worker), Purpose Namespace (_http, _websocket, etc) and
Variation Namespace (_classic, _psr7, _raw).
For me personally one awesome last step would make this a PHP Class instead
of procedural functions. That would be even better because we could use the
Class namespace itself to version it and provide future changes without
breaking what's been introduced already.
--
Marco Deleu
Re: [PHP-DEV] [PDO] 2 phase commit
On Thu, Nov 30, 2023 at 3:59 PM Bruce Weirdan wrote: > On Thu, Nov 30, 2023 at 7:22 PM Larry Garfield > wrote: > > > > > I have not heard of this functionality before, so I don't know how common > > it is. If it's only lightly supported and in different ways, perhaps > this > > is a use case for the new per-DB subclasses? > > > > Postgre (https://www.postgresql.org/docs/current/two-phase.html), MySQL ( > https://dev.mysql.com/doc/refman/8.0/en/xa.html) and Oracle ( > > https://docs.oracle.com/en/database/oracle/oracle-database/21/admin/distributed-transactions-concepts.html#GUID-8152084F-4760-4B89-A91C-9A84F81C23D1 > ) > all support it. > > > -- > Best regards, > Bruce Weirdan mailto: > weir...@gmail.com > Having MySQL XA Transactions exposed via PDO methods through a simplified user experience would be amazing. -- Marco Deleu
Re: [PHP-DEV] [RFC][Discussion] Why can constructors violate LSP?
>
> Hey Mike,
>
> Using a static method to enforce LSP when it should have been enforced
> in the first place, merely proves my point that it violates LSP. I
> don't know how else to spell it out, I guess we can try this one next:
>
> class A {
> final public static function foo() {
> return new static();
> }
> }
>
> class B extends A {
> public function __construct(private string $name) {}
> }
>
> $a = B::foo();
>
> It just plainly violates LSP and you can't write safe code that
> touches constructors. I don't know how else to spell this out.
>
Hey Robert, as we've established we may not agree on this subject and I
really don't want to sound like I want to convince you, so feel free to
ignore my email or reply that this isn't helping. My goal here is merely to
try and address what I think the error is in case it gives you some clarity.
-
In this snippet, you're using `new static()` which again is something
PHP-specific and not 100% OOP definition. PHP has a friendly syntax to help
you figure out what the class name is during runtime, this again is
metadata. With these tools, I believe you are able to accomplish what you
want by explicitly adding the constructor to your public API.
```
abstract class Template
{
abstract public function __construct(string
$explicitlyDefinitionOfPublicAPI);
}
class A extends Template {
public function __construct(string|null $ignore) {}
final public static function foo()
{
return new static('parameter defined from A');
}
}
class B extends A {
public function __construct(public string $name) {}
}
$b = B::foo('test');
var_dump($b->name);
```
Let's break this down. The `Template` class uses the Abstract Template
pattern to define a public interface of the inheritance chain. As such, it
offers the ability to opt-in to something that isn't standard: The
Constructor method being part of a class Public API.
Two things happen from this. We are forced to implement a constructor on
class A otherwise we get:
Fatal error: Class A contains 1 abstract method and must therefore be
declared abstract or implement the remaining methods
(Template::__construct) in /in/7qX9j on line 8
And we inherit the Constructor from A in B or we need to override it. My
conclusion here is that 1) if you know what you're doing and 2) you want to
make a constructor's object part of your public API, and therefore, respect
LSP, you are free to do so.
- Why shouldn't this be the default behavior in PHP?
Let's ignore for a second 28 years of breaking change and focus on the OOP
principle
```
serialize($message);
$client->sendMessage([
'QueueUrl' => $this->queue,
'Message' => $data,
]);
}
}
final class RedisQueue extends Queue
{
public function __constructor(private
\Illuminate\Redis\Connectors\PhpRedisConnector $connector, private array
$configuration, private array $options) {}
public function push(array $message): void
{
$connection = $this->connector->connect($this->configuration,
$this->options);
$data = $this->serialize($message);
$command = "redis.call('rpush', KEYS[1], ARGV[1])";
$connection->eval($command, 1, 'queues:my-queue', $data);
}
}
```
This is a text-book case of LSP. A class that expects to receive a `Queue`
object can freely use `push()` in a consistent and predictable manner,
allowing substitution as it sees fit. The object constructor is exempt from
LSP because it is the implementation detail of a particular class.
RedisQueue needs to be able to communicate with Redis in order to provide a
queueing capability.
SqsQueue needs to be able to communicate with AWS SQS in order to provide a
queuing capability.
They have different dependencies/configurations and they wouldn't be able
to perform their capabilities if the language forced their constructor to
follow a single compatible signature.
-
In conclusion, I think PHP has the best of both worlds. We get little
helpers to accommodate how OOP looks like in a dynamic script language
(i.e. new static()) and we have a fully functioning LSP that allows you to
take advantage of it however you see fit. The Queue example goes to show
why having a constructor as part of the public API of a class hierarchy
would be extremely bad, but PHP is nice enough to let you opt-in to it if
you have reasons to force a class hierarchy to have a single dependency
signature.
--
Marco Deleu
Re: [PHP-DEV] [RFC][Discussion] Why can constructors violate LSP?
On Thu, Nov 23, 2023 at 5:31 PM Robert Landers
wrote:
> Hello Internals,
>
> As you may know, an inherited method cannot reduce the visibility of
> an overridden method. For example, this results in a fatal error
> during compilation:
>
> class P {
> public function hello($name = 'world') {
> echo "hello $name\n";
> }
> }
>
> class C extends P {
> private function hello($name = 'world') {
> parent::hello($name);
> echo "goodbye $name\n";
> }
> }
>
> However, we can make certain methods private anyway, namely,
> constructors (I haven't gone hunting for other built-in methods yet).
> This is perfectly allowed:
>
> class P {
> public function __construct($name = 'waldo') {
> echo "hello $name\n";
> }
> }
>
> class C extends P {
> private function __construct($name = 'world') {
> parent::__construct($name);
> echo "goodbye $name\n";
> }
> }
>
> To my somewhat trained eye, this appears to violate the Liskov
> Substitution Principle, for example, this now can have hidden errors:
>
> function create(P $class) {
> return new (get_class($class))();
> }
>
> proven by:
>
> $c = (new ReflectionClass(C::class))
> ->newInstanceWithoutConstructor();
>
> create($c);
>
> Even though we thought we knew that the constructor was declared public.
>
> I'd like to propose an RFC to enforce the covariance of constructors
> (just like is done for other methods), to take effect in PHP 9, with a
> deprecation notice in 8.3.x.
>
> I'm more than happy to implement it.
>
> Does anyone feel strongly about this one way or the other?
>
Constructors are an implementation detail of a specialized class and as
such they're not subject to LSP because the goal of LSP is to be able to
make sure that any object of a given type hierarchy can be used to
accomplish a certain behavior. If you take a step back from PHP's
dynamic nature and think about LSP from a more pure type system, the fact
you're expecting an object of type C, but then you completely disregard
everything about the object itself and dive into it's metadata to build
another object, that's the moment you're no longer playing by the rules of
OOP. It's like those mathematical equations that prove that 1 = 2, they all
have one thing in common: they end up dividing by 0 at some point.
OOP here dictates that you should reach for patterns like Builder, Abstract
Factory or similar. That way you constraint yourself to the rules of OOP
and you won't get weird outcomes.
>From another point of view, when a type is expected by a function or
method, all we can expect from it is whatever was defined as the blueprint
(class/interface) of that object and the __construct() is a special method
that is not assumed to be part of that blueprint because it's not
reasonable to do `$object->__construct();` after receiving an object. As
such, a constructor cannot break LSP because the constructor is not part of
the object's API from a "receptor" point of view.
I don't have a vote so take my opinion with a bucket of salt, but if I
could I would definitely vote against such RFC.
--
Marco Deleu
Re: [PHP-DEV] [RFC] [Discussion] Resource to object conversion
manage to rebuild something (throughout multiple versions), a migration path assumes users will use of Rector, Static Analysers and PHPUnit and the old engine keeps the BC promise in order to allow old software to keep running, but is expected to degrade in performance and to only support new stuff if it has no added burden to internals. When such assumptions are made about userland, the concept of what's an acceptable BC break should be skewed in favor of helping PHP Internals. -- Marco Deleu
[PHP-DEV] Ability to session_decode() in a stateless manner?
Hi! Earlier today I was working on a small tool to invalidate PHP Sessions in a legacy system. I quickly found out about the `session_decode()` function, but unfortunately this function requires an active session and it is completely stateful, which means when I try to decode a specific session data, I end up overriding the existing session. I also tried combining `ob_start()` with `session_id()`, `session_start()`, `session_destroy()` and `ob_end_clean()`, but this would still cause some weird behaviors by sending two PHP Cookies through the Response Headers. In an ideal world, I would override `session.serialize_handler` and be done with it, but that would require invalidating every existing session and some non-trivial changes in the 20 year old codebase. To my original question, is there any exposed API that would give userland access to the session deserializer algorithm in a stateless manner? Something like `session_deserialize(string $data): array;`, preferably in a way that 1) doesn't require or doesn't conflict with any existing session and 2) returns the session array without any side effects? If not, would this be something that requires an RFC? Are there any controversial thoughts around it? Thanks! -- Marco Deleu
Re: [PHP-DEV] RFC Proposal - static modifier for classes
On Mon, Nov 20, 2023 at 1:43 PM Rowan Tommins wrote: > On 20 November 2023 08:35:15 GMT, Lanre Waju > wrote: > > >1. I will personally implement this feature. > > That's good to hear, but the initial implementation is not the main cost > of a new feature. Once we add something, it's very hard to remove, and > every future change has to consider that feature and make sure it doesn't > break. > > It's probably not productive to just say "the people who voted last time > are wrong", but it was long enough ago that a new RFC on the topic wouldn't > break any rules. 9 years is long enough to conclude that whatever happens, they weren't really wrong back then. Maybe at that time the best thing for the language was not to introduce it. The maintenance cost of a feature and the benefit it brings are also things subject to change in such a long timeline. Maybe the current technical debt or the current suite of tests make this feature less of a burden than it used to be or maybe our understanding of the value of such a feature has changed in the course of 9 years. -- Marco Deleu
Re: [PHP-DEV] [RFC][Discussion] Harmonise "untyped" and "typed" properties
On Thu, Nov 16, 2023 at 5:41 PM Rowan Tommins wrote: > Hi all, > > I have finally written up an RFC I have been considering for some time: > Harmonise "untyped" and "typed" properties > > RFC URL: https://wiki.php.net/rfc/mixed_vs_untyped_properties > > > Currently, changing a property declaration from "private $foo" to > "private mixed $foo" changes its behaviour in significant ways, even > though no actual type checks are added. This RFC seeks to remove those > differences, by extending the "uninitialized" state currently reserved > for typed properties to cover all declared properties: > > * Properties without an initial value will be "uninitialized", not "null" > * Calling "unset" on a declared property will make it "uninitialized", > rather than the current complex behaviour > > > There are a handful of open questions still in the RFC, but I wanted to > present an initial draft to start the discussion, because the current > behaviour is quite hard to explain in a short e-mail. > > Please let me know your thoughts. > > Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > I have mixed feelings about this. Reading just the email gives me the impression of an unimaginable BC Break with the potential of holding back PHP upgrades A LOT. But reading the RFC, it is pretty clear that what we have now is a consequence of entropy and what is being proposed is to explicitly make a plan with all existing cases in mind. The fix for the BC is something trivial: null was implicit but now will require explicitness. The behavior which makes existing code work seems easy to get in place. However, the amount of code that would need this and the fact that Rector is not used by every PHP Developer is something that makes this a big deal. The thing I like the most about the proposal is making a sensible choice to cover the scenarios that are intertwined. Considering what has been said about opt-in making things harder with no desired mass adoption, perhaps what could be done instead is an easy-way-out (opt-out). An attribute that can be added to the class and have it automatically default untyped uninitialized properties to null. This allows the original proposal to stand and allow for a wide adoption while still giving a way-out for computer systems written 30~15 years ago that are still running and still being slowly refactored / rewritten. One thing to make it explicitly clear about my suggestion, I don't want or intend to have an attribute that keeps the current engine as-is + develop the engine with the new behavior because in my mind that could mean multiple areas of the engine and it could be quite complex to handle. My proposal is more about an ad-hoc self-contained Annotation that simply goes through the class and automatically set everything to null before the engine does its thing. In a way, it could still be a BC-break no matter what - 2 different behaviors of the language, but I'm thinking that such attribute could make things behave as-is 99% of the time and allow legacy systems to still breathe. -- Marco Deleu
Re: [PHP-DEV] Basic Type Alias
unction was the slim layer that made PHP Namespaces what they are. We can build on top of that mindset with type aliases. We need a syntax to declare them and an autoloading userland function to find where they are declared. Everything else can fall into place as it did before. I would love it if we could bring up a discussion on proposing changes to the PHP Namespace system to allow for something more like ESM while considering we don't have a build system and a hot-reload system, but I'm just not sure if PHP Type Aliases is where that discussion MUST to happen. If this line of thought has any merit, a better question would be whether Type Alias needs a separate autoload function from class/interfaces or a single autoload is better. I think that's the kind of discussion that would help Composer/PSR to decide how to expand and improve the PHP Ecosystem to include handling of Type Aliases. -- Marco Deleu
Re: [PHP-DEV] Two new functions array_first() and array_last()
On Wed, Oct 18, 2023 at 2:49 PM Brandon Jackson wrote: > > The only portion in your email I disagree with is this ending. I believe > there are enough use-cases where if the first value is "valid null" or > "default null" it won't matter. The developer will treat them both the > same. Perhaps you disagree with this and want to avoid ambiguity at all > costs. My proposal to avoid ambiguity would be throwing an exception > instead of involving the key because involving the key can be a composition > between `array_first()`* and `array_key_first()`. > > > > Although I would prefer the function to throw, I think it will have the > same effect as this key discussion: complicate something that can be > simple. If the developer needs to distinguish between "default null" and > "value null", they are able to do so by running `empty()` on the array > prior to asking for `array_first()`. It's actually better than a try/catch, > to be honest. > > Sure in many use cases undefined and null can be equivalent, but there > are other use cases and considering the fact that php does not have a > user level "undefined" value. It should at least attempt to not be > ambiguous when possible. Instead of being ambiguous by default, > requiring the user to do additional work to not be ambiguous. > > I do think the method is a great opportunity to avoid ambiguity, > without a huge sacrifice on cost. As you said, throwing an exception > would only further complicate things. Sure an empty check would get > the job done, but again I believe it should not require such > additional logic just to not be ambiguous. > My statement about throwing exceptions is, to me, exactly equivalent to the discussion of $key and $value. I believe being ambiguous is fine in this case. If we collectively decide that ambiguity is unacceptable, then my vote is on Exception over involving $key on `array_first()`. I would go as far to say that if the only option is to have `array_first()` returning $key and $value simultaneously, I probably would prefer if `array_first()` does not get implemented at all. > > * If naming is an issue to you, I'd also be fine with > `array_value_first()`. > If the rfc does maintain only returning the value > `array_value_first()` IMO is ideal. > * With array_first being so general, I would think it's only fair that > the naming is reserved for something that touches on multiple parts of > the array. > * If someone did want to open an rfc adding the above functionality > they would have to opt for something like array_first_key_value which > having a group of key/value operator methods `array_key_first`, > `array_first`, and `array_first_key_value` would be absolutely > atrocious IMO. > * Naming consistency with array_key_first would be nice. For new > comers to the language I think it is a reasonable assumption when you > see array_key_first being used. That array_value_first should also > exist that does the same thing for values, and array_first might be a > slight curve ball. > * They are going to do some googling and probably be pointed to some > outdated way of doing things, like using array slice or back to > array_key_first. As time goes on blogs and other places like stack > overflow will update there solutions, and or people will re-ask hoping > there's a more up to date/efficient solution, and hopefully then > someone will actually provide the latest answer of `array_first`. > Everything you mention about function naming I believe gets invalidated by Larry's comment regarding all of PHP `array_()` function family. They don't have `value` in their name when working with array values and they have `key` when working with array keys. With that, array_first() cannot be "consistent" with array_key_first() without being inconsistent with dozens of PHP array functions. Larry's comment is enough to close down the discussion on the function name as there's no room for anything other than `array_first()` in my opinion. -- Marco Deleu
Re: [PHP-DEV] Custom object equality
On Wed, Oct 18, 2023 at 2:05 PM Christian Schneider wrote: > Am 18.10.2023 um 18:42 schrieb Larry Garfield : > > So the real question is: Would anyone who voted No on operator > overloading before vote Yes on it if it used ~=, ~>, ~+, etc. instead? > > I confess that I'm not a fan of operator overloading for a language like > PHP but introducing new operators on top of making them overloadable seems > a bad idea. Operators have the problem of being hard to look up and > prefixing them with ~ feels like the worst of both worlds. > > Regards, > - Chris > To add on to this, the proposal side-steps a potential BC break issue while introducing a collection of problems for libraries using PHP Tokens, Static Analysers, IDEs and more importantly the ability to grep your codebase looking for `==`. >From what I understood about the BC break concern, it's the fact that IF: - Existing code is comparing objects (relying on potentially non-deterministic behavior?) - PHP introduces operator overload - A library releases a new major version implementing operator overload - Existing code breaks Sounds to me that this is more between Library authors and Library users. Yes, PHP would be opening the door for potential BC breaks, but the stability of Composer packages and the adoption of Semantic Versioning throughout the industry makes this look like PHP is trying to protect grown, trained, mentally stable adults from running with knives. On Wed, Oct 18, 2023 at 1:43 PM Larry Garfield wrote: > Honestly I'm still on team operator-override. *Most* major languages have > operator overloading, and it doesn't seem to cause a problem. (According > to my research, C++, Kotlin, Swift, Rust, C#, Haskell, Python, and Ruby all > have operator overloading. Go, TypeScript, PHP, and Javascript do not. > Java has comparison-only overloading so it's in the middle.) Most of the > "it causes so many problems" arguments are, from what I can tell, greatly > over-exaggerated. > > ---Larry Garfield > To argue against myself, I think Larry has a killer point in the language comparison. I think it's fair to say PHP is the weird one out for not having Operator Overload when even Python and Ruby (languages more similar to PHP than Kotlin or Rust) have them. Ultimately, if voters think it's best to overload `~=` instead of `==`, I think we bite the bullet and deal with the consequences. Even though I have every reason not to want `~=`, PHP deserves method overloading unless folks can show facts as to why nearly every other major programming language is wrong or why they can have it and we can't. -- Marco Deleu
Re: [PHP-DEV] Two new functions array_first() and array_last()
On Wed, Oct 18, 2023 at 12:04 PM Robert Landers wrote: > > I completely understand what you're saying and I don't disagree with the > thought process. What I disagree with is your statement that you will > always use array_first() together with array_key_first(). When talking > about standard lists (indexed from 0 to upper-bound), array_first() is an > order of magnitude more useful than array_key_first() as we always know > what the first key is: 0. > > This is simply not true, 0 is not always the first key in a list, > especially after filtering it. Hence there is a need for this function > in the first place. > To give back on the same format, "this is simply not true". Here are the facts: - https://www.php.net/manual/en/function.array-is-list.php - Determines if the given array is a list. An array is considered a list if its keys consist of consecutive numbers from 0 to count($array)-1." - https://3v4l.org/JZS9N#v8.2.11 At this point I have nothing else to add to this conversation. You will either accept that it is actually possible to use `array_first()` without using `array_key_first()` or you'll keep believing that your knowledge and experience is the only correct one. I believe my reservations have been registered, I would not like to have `array_first()` behave in a non-obvious way (i.e. involving array $key) because it's useful for Fibers users. I believe that writing your own wrapper that always returns key and value simultaneously is easy and straight-forward and may even make it into the core in the future. Rather than trying to solve deep convoluted issues on version 1, I believe PHP could introduce the simplest version of the function first and later on add an array_first_key_value() in the future if needed. In fact, I encourage you to propose an RFC for `array_first_key_value()` as a solution for the problem you're raising. -- Marco Deleu
Re: [PHP-DEV] Previous discussions about generics syntax only?
On Wed, Oct 18, 2023 at 4:14 AM Olle Härstedt
wrote:
> 2023-10-17 21:39 GMT+02:00, Rowan Tommins :
> > On 16/10/2023 15:08, Olle Härstedt wrote:
> >> Hello internals,
> >>
> >> Was there a previous discussion about the pros/cons of adding only the
> >> syntax needed for generics, but not the functionality? So static
> >> analyzers could use it, instead of docblocks. I looked at externals.io
> >> but couldn't find anything specific.
> >
> >
> > Hi Olle,
> >
> > Since I haven't seen it expressed quite this way in the previous
> > discussion, I'd like to highlight what I think is a major downside to
> > this approach, at least as commonly proposed:
> >
> > Using the same syntax for type information that is guaranteed to be true
> > (existing run-time checks) and type information that is "advisory only"
> > (new checks for optional static analysis) means users can no longer have
> > confidence in that type information.
> >
> > This is one of the interesting things about the compromise over scalar
> > types - if you see a declaration "function foo(int $bar) { ... }", you
> > *know* that $bar will be an int at the start of every invocation of that
> > function, regardless of which mode the calling code uses. I think adding
> > exceptions to that certainty would be a bad direction for the language.
> >
> > On the other hand, I can see a "third way": if the problem with current
> > static analysis conventions is that they have to be parsed out of a
> > string-based docblock, we can provide *dedicated* syntax, without
> > unifying it with the standard type syntax. For instance, some of the
> > earlier discussions around introducing attributes suggested reflection
> > expose the AST of the attributes arguments, rather than the resolved
> > expressions, allowing them to act a bit like Rust's "hygienic macros".
> > If that was added as an optional mode, you might be able to do something
> > like this:
> >
> > #[RawAttribute]
> > class GenericType {
> > public function __construct(AST\Node $typeInfo) { ... }
> > }
> >
> > function foo(#[GenericType(int|float)] array $foo) {
> > // array is the type guaranteed by the language
> > // static analysis libraries can get the GenericType attribute from
> > reflection and receive an AST representing the type constraint int|float
> > }
>
> Not sure readability is improved here compared to existing @template
> annotations. ;)
>
> Olle
>
I won't be participating much about this discussion because I lack
expertise to add too much. I just wanted to voice a small (and defeated)
minority of PHP developers that don't want/care for Generics. I've been
working with Typescript lately and I see generics only being useful for
library code and even then when I end up writing some valid Generics stuff,
Typescript verbosity becomes so bloated that it invalidates the added-value
of the functionality.
I truly can't understand how Generics is the most requested PHP feature so
I will just assume I will have to live with it one day, but mixing it with
Attributes Syntax seems to be a recipe to make it as bad (or worse) than
the experience of using Generics in Typescript.
--
Marco Deleu
Re: [PHP-DEV] Two new functions array_first() and array_last()
On Wed, Oct 18, 2023 at 10:29 AM Brandon Jackson wrote: > > You may be using them and be totally unaware that you are using them. > > Emphasis on that. Take promises for example. Anyone using libraries > that incorporate promises either are using fibers or will likely be > using them in the near future. And I'd say that one pattern is > probably used enough to be considered more than just a corner of php. > If you have 5 developers dealing with issues originated from Fibers and a billion developers using it oblivious that they are using it, why `array_first()` , a function targeted at a billion developers, needs to cater for issues being faced by 5 developers? I don't mean to discredit/reduce/invalidate the work/efforts that developers working with Fibers encounter, but my point is that if you're using Fibers without knowing it, then any inner problem of Fibers do not mean anything to you as the developers providing the library/functionality will have to find ways to avoid exposing an API with broken behavior. Whether today or 1 year from now 100% of PHP code will be taking advantage of Fibers or not is irrelevant to this discussion. -- Marco Deleu
Re: [PHP-DEV] Two new functions array_first() and array_last()
On Wed, Oct 18, 2023 at 10:11 AM Brandon Jackson
wrote:
>
> I get your desire to keep things simple, but IMO returning a value
> that does not conflict with possibly valid values or somehow indicates
> the value was not present is important, and should come before
> simplicity. Which likely means involving the key somehow.
>
The only portion in your email I disagree with is this ending. I believe
there are enough use-cases where if the first value is "valid null" or
"default null" it won't matter. The developer will treat them both the
same. Perhaps you disagree with this and want to avoid ambiguity at all
costs. My proposal to avoid ambiguity would be throwing an exception
instead of involving the key because involving the key can be a composition
between `array_first()`* and `array_key_first()`.
Although I would prefer the function to throw, I think it will have the
same effect as this key discussion: complicate something that can be
simple. If the developer needs to distinguish between "default null" and
"value null", they are able to do so by running `empty()` on the array
prior to asking for `array_first()`. It's actually better than a try/catch,
to be honest.
Ultimately, there's 2 parallel discussion that somewhat intertwine
themselves: Fibers ("async" code) and ambiguity ("value null" vs "default
null") and while there are options that may cater for both of them, there
are also options that cater only for each of them individually. Trying to
over-pollute a function as simple as `array_first()` to cater for these
edge cases is where I think the problem is because userland will always be
able to tackle these issues by wrapping the basic functionality provided by
core.
* If naming is an issue to you, I'd also be fine with
`array_value_first()`.
--
Marco Deleu
Re: [PHP-DEV] Two new functions array_first() and array_last()
On Wed, Oct 18, 2023 at 9:29 AM Robert Landers wrote: > On Wed, Oct 18, 2023 at 1:43 PM Deleu wrote: > > > > > > > > On Wed, Oct 18, 2023 at 4:31 AM Robert Landers > wrote: > >> > >> On Wed, Oct 18, 2023 at 5:26 AM Deleu wrote: > >> > > >> > On Tue, Oct 17, 2023 at 3:43 PM Brandon Jackson < > brandonja...@gmail.com> > >> > wrote: > >> > > >> > > > There is also a technique to make the return value `[$key => > $value]` > >> > > instead of just a value, but this loses simplicity. > >> > > > >> > > Hmm, since the naming array_first and array_last doesn't clarify > that > >> > > it's returning a key or a value. What if it returned both as ?[key, > >> > > value]. > >> > > > >> > > That opens quite a few use possibilities: > >> > > $first = array_first($array); > >> > > $value = $first[1] ?? throw new Exception(); > >> > > > >> > > [,$value] = array_first($array) ?? [null, null]; > >> > > [,$value] = array_first($array) ?? throw new Exception(); > >> > >> > >> Hey Marco, > >> > >> > This function signature can be accomplished by userland once we have > >> > `array_key_first()` and `array_first()`. > >> > >> This would always mean you have to keep them right next to each other, > >> it would be a best practice to do so and to split them up should be a > >> code smell in any static analysis. > > > > > > "You" (general you) don't always have to keep them right next to each > other. Each function is self-sufficient and independent. Maybe on your > personal bubble you might need to always keep them next to each other, > which is why I suggested creating your own userland function that returns > key and value together. > > > >> > >> There is no way to tell if a Fiber > >> is involved in any function call in PHP, thus if you split them apart > >> and call a function, it is possible that your current Fiber is > >> suspended and another Fiber mutates the variable you are referencing > >> (this is especially true in Classes, not so much in pure functions). > > > > > > I might be completely wrong here, but on my personal bubble, I consider > Fibers to be a corner (a fraction) of PHP compared to non-Fibers PHP. > Although Fibers took the approach to not "paint" [what color is] your > function, it doesn't mean that Fibers can be used without taking > precaution, as with any new tool. > > > >> > >> Since they would always have to be right next to each other, it is > >> easier to just combine them into a single atomic function call, which > >> would negate the need for static analysis to be involved or surprises. > >> > >> > It's much better to keep > >> > `array_first()` as simple as possible and let everyone build their own > >> > approach to go about it since we have so many approaches. > >> > >> There is only one right approach that prevents Fibers from messing up > >> your day, and it would be considerable boilerplate code that you'd > >> have to type every time, as well as involve static analysis and watch > >> for "people who don't know" better in code reviews. > > > > > > You say only one approach, but a return signature of `: [$key, $value]` > or the `array_key(array $array, &$key = null) ` makes it at least 2 > approaches that would be fibers-safe, no? > > > > This is a discussion about an extremely basic functionality that PHP > hasn't introduced up until now. I think it's an extremely great addition, > but requires to focus first on the most basic aspect of it. Literally every > beginner, mid-level, experienced and most senior PHP developers will work > with PHP arrays on way or another. As such, a basic functionality like this > should remain as basic as possible. If needed, PHP can port more helper > functions into the core to cater for Fibers in the future. > > > > In my opinion, the only problem is the ambiguity of returning `null` > which might mean the array is empty or might mean the first value is truly > null. If we get a warning box on PHP Docs recommending people to pair this > with `empty()` before using it, it gives users coverage for everything they > will need most of the time. Personally, I think I'd prefer the function to > throw an exception than to return `null` when array is empty to avoid > ambiguity and force fol
Re: [PHP-DEV] Two new functions array_first() and array_last()
On Wed, Oct 18, 2023 at 4:31 AM Robert Landers wrote: > On Wed, Oct 18, 2023 at 5:26 AM Deleu wrote: > > > > On Tue, Oct 17, 2023 at 3:43 PM Brandon Jackson > > wrote: > > > > > > There is also a technique to make the return value `[$key => $value]` > > > instead of just a value, but this loses simplicity. > > > > > > Hmm, since the naming array_first and array_last doesn't clarify that > > > it's returning a key or a value. What if it returned both as ?[key, > > > value]. > > > > > > That opens quite a few use possibilities: > > > $first = array_first($array); > > > $value = $first[1] ?? throw new Exception(); > > > > > > [,$value] = array_first($array) ?? [null, null]; > > > [,$value] = array_first($array) ?? throw new Exception(); > > > Hey Marco, > > > This function signature can be accomplished by userland once we have > > `array_key_first()` and `array_first()`. > > This would always mean you have to keep them right next to each other, > it would be a best practice to do so and to split them up should be a > code smell in any static analysis. "You" (general you) don't always have to keep them right next to each other. Each function is self-sufficient and independent. Maybe on your personal bubble you might need to always keep them next to each other, which is why I suggested creating your own userland function that returns key and value together. > There is no way to tell if a Fiber > is involved in any function call in PHP, thus if you split them apart > and call a function, it is possible that your current Fiber is > suspended and another Fiber mutates the variable you are referencing > (this is especially true in Classes, not so much in pure functions). > I might be completely wrong here, but on my personal bubble, I consider Fibers to be a corner (a fraction) of PHP compared to non-Fibers PHP. Although Fibers took the approach to not "paint" [what color is] your function, it doesn't mean that Fibers can be used without taking precaution, as with any new tool. > Since they would always have to be right next to each other, it is > easier to just combine them into a single atomic function call, which > would negate the need for static analysis to be involved or surprises. > > > It's much better to keep > > `array_first()` as simple as possible and let everyone build their own > > approach to go about it since we have so many approaches. > > There is only one right approach that prevents Fibers from messing up > your day, and it would be considerable boilerplate code that you'd > have to type every time, as well as involve static analysis and watch > for "people who don't know" better in code reviews. > You say only one approach, but a return signature of `: [$key, $value]` or the `array_key(array $array, &$key = null) ` makes it at least 2 approaches that would be fibers-safe, no? This is a discussion about an extremely basic functionality that PHP hasn't introduced up until now. I think it's an extremely great addition, but requires to focus first on the most basic aspect of it. Literally every beginner, mid-level, experienced and most senior PHP developers will work with PHP arrays on way or another. As such, a basic functionality like this should remain as basic as possible. If needed, PHP can port more helper functions into the core to cater for Fibers in the future. In my opinion, the only problem is the ambiguity of returning `null` which might mean the array is empty or might mean the first value is truly null. If we get a warning box on PHP Docs recommending people to pair this with `empty()` before using it, it gives users coverage for everything they will need most of the time. Personally, I think I'd prefer the function to throw an exception than to return `null` when array is empty to avoid ambiguity and force folks to use `empty()`, but that would also mean complicating the function more due to edge cases, which as I stated in this email, I'd rather have the simplest thing possible and let userland fill in the additional complexities needed. -- Marco Deleu
Re: [PHP-DEV] Two new functions array_first() and array_last()
On Tue, Oct 17, 2023 at 3:43 PM Brandon Jackson wrote: > > There is also a technique to make the return value `[$key => $value]` > instead of just a value, but this loses simplicity. > > Hmm, since the naming array_first and array_last doesn't clarify that > it's returning a key or a value. What if it returned both as ?[key, > value]. > > That opens quite a few use possibilities: > $first = array_first($array); > $value = $first[1] ?? throw new Exception(); > > [,$value] = array_first($array) ?? [null, null]; > [,$value] = array_first($array) ?? throw new Exception(); > This function signature can be accomplished by userland once we have `array_key_first()` and `array_first()`. It's much better to keep `array_first()` as simple as possible and let everyone build their own approach to go about it since we have so many approaches. -- Marco Deleu
Re: [PHP-DEV] Why did fibers get added to php core over something more fleshed out like swoole?
On Thu, Oct 12, 2023 at 10:00 PM Lanre Waju wrote: > I find it puzzling that the PHP internals have chosen to delegate this > specific functionality to userspace implementation. Fibers, in my view, > seem somewhat limited without the addition of a third-party library or, > at the very least, the necessity to implement an event loop in userland. > This raises questions, as it effectively obliges users to rely on > third-party libraries to handle a fundamental feature rather than > incorporating it into the core of PHP. > Seems like your description here quite matches what the goal/aim for Fibers initially was; a low-level API to help userland libraries to build async PHP code. > Moreover, I'm curious about why PHPDBG doesn't implement the Language > Server Protocol (LSP). Could it be due to its reliance on Xdebug? I came > across this discussion on https://externals.io/message/78456, which > makes me wonder about the decision-making process within PHP internals. > It sometimes seems as though certain choices may not align with the best > interests of the PHP community. I would appreciate it if you could > provide insights into why this might not be the case. > > > Lanre > My personal, non-fact-checked guesswork about the current state is that PHP had a significant history of decisions that made future work on the language harder. As time passed and the language had more and more features naturally the project becomes harder to maintain and navigate, which affected how future decisions were made. The BC promise of PHP has always been significantly high - some edge cases and significant BC breaks have happened, but they're not the norm. Naturally the next step in this history is to become more conservative. Userland libraries can have faster release cadence, requires PHP maintainers (bigger pool than C maintainers) and breaking changes are a lesser problem to a certain extent. Discussions around language evolution, editions, etc has happened as (among other things) a possibility to make BC breaks less impactful to the world wide web and lower the barrier in getting an RFC approved, but these discussions never led to a concrete implementation. As it currently stands, PHP is a solid language with stable and proven APIs with Composer and Community packages covering the gap in consistency, technology evolution and developer experience. I'm a big advocate for having some language changes that makes common and fundamental use-cases part of the language i.e. it's quite unfortunate that a 30 year old language that powers the World Wide Web don't have a Request object, but history has made PHP quite conservative and there hasn't been a significant change that invalidates the reason to be conservative yet. On top of that, some voters are extra conservative when the topic is added DX built-in to the language, specially because DX can be subjective (see multi-line arrow function). Long story short, Fibers being something "incomplete" from a userland perspective is a feature, not a bug. Look at it as the simplest, smallest (while still being feature-complete) way to expose the ability to write async code in PHP while Swoole is almost an ecosystem on its own. -- Marco Deleu
Re: [PHP-DEV] [RFC][Under discussion] RFC1867 for non-POST HTTP verbs
Marco Deleu > On 6 Oct 2023, at 19:39, Ben Ramsey wrote: > > On 10/6/23 11:18, Jakub Zelenka wrote: >> Hi, >>> On Fri, Oct 6, 2023 at 2:44 PM Ilija Tovilo wrote: >>> https://wiki.php.net/rfc/rfc1867-non-post >>> >>> >> It should probably explicitly mention that it uses the same inis like >> max_input_vars, max_file_uploads and max_multipart_body_parts. >> It's kind of strange function as I can't decide where it should be placed. >> I think it might be better as a stream function if it accepts only stream. >> It means it could go to stream funcs and be called stream_parse_post_data >> instead but not sure about. But not 100% sure about it as it doesn't >> exactly fit there. But seems better than html functions (where it's placed >> in the current PR) as it has nothing to do with html IMHO. > > > Maybe it should go in main/rfc1867.c? That's where the php_rfc1867_callback > lives, and this seems somewhat related to that. > > Cheers, > Ben > Just wanted to mention that maybe this is a great opportunity to create a request_ family and start with request_parse_post_data -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] A new JIT implementation based on IR Framework
On Thu, Sep 21, 2023 at 6:13 AM Tim Düsterhus wrote: > Hi > > On 9/21/23 10:26, Dmitry Stogov wrote: > My understanding is that even if the new JIT might not (yet) be better > than the old one, it is not worse and it is more maintainable. The > reactions from more knowledgeable folks were pretty positive overall. > > So if the new JIT passes the existing test suite without issues, I don't > see a reason why the old JIT should not be replaced right away. By > immediately removing the old JIT (ideally in a separate commit) the > codebase is cleaned up and users that want to test PHP 8.4 (or whatever > that version may be in the end) will be forced to also test the new JIT > which is probably a good thing. > If I understand correctly, the only way to fallback to the JIT 1.0 implementation is by compiling PHP with a new introduced flag, so the JIT 2.0 needs to be opt-out. The RFC doesn't mention the configurations for new JIT (init settings) which makes me assume that they're exactly the same? If these assumptions are right, I think the matter of keeping or removing JIT 1.0 implementation is mostly a matter of what makes Dmitry more comfortable. Removing it straight-away might result in adding more pressure in getting bug fixes on the new one, while keeping it might make it possible for whoever is relying heavily on JIT to still compile new PHP releases with JIT 1.0 to give more time to iron out the final details on JIT 2.0. Of course this is a very basic analysis on my part which mixes my experience in replacing PHP running-systems with new rewrites and it's much more comfortable to me to have a fallback mechanism in place which may or may not be entirely relevant here. -- Marco Deleu
Re: [PHP-DEV] [RFC][Draft] Match block
On Sun, Sep 10, 2023 at 12:51 PM Rowan Tommins wrote: > On 10 September 2023 15:35:44 BST, Deleu wrote: > > ... until we manage to gather enough > >voters to overcome the "no-auto-capture" camp. > > > I think that's a rather adversarial / political way to put it. I believe > the aim of voting should be to measure consensus, not replace it. > Communities are a live organism and I reckon the current pool of voters are not exactly the same as the ones voting 15 years ago. Even if someone used to be an active voter 15 years ago and is still present to this day, maybe their mindset or the language itself has changed enough to yield a different result. What I meant to say with "enough voters to overcome the no-auto-capture camp" is that the current camp that blocks this line of reasoning can either change their mind, disengage from the project (reducing no-votes) or simply be outvoted by a new wave of contributors. > A more productive wording would be "until we can find a version of the > feature that satisfies the concerns raised in previous discussions". > I think this is wishful thinking as the previous discussions has already shown that the disagreement is fundamental. What I want is === auto-capture. I don't want something that resembles auto-capture or facilitates capturing. Previous discussion has already established that one camp of voters don't want auto-capture. They might be open to a compromise on facilitating auto-capture, which is where there's no expectation of a version which satisfies the concerns. I think there are some really powerful things that could be done with new > types of block, and new ways of scoping variables, but have concerns about > how to fit them with the existing language. I will continue to engage in > good faith in discussing those proposals, but find it disheartening to be > labelled as part of a "camp" that needs to be "overcome". I meant no disrespect and I apologize for any negative effect that my wording may have caused. I do have difficulty expressing it differently. There's this core concept which I see as a great improvement to the development of PHP code and there's philosophical disagreement on whether it's a good thing or not. Perhaps there is really no *need* to overcome that camp of voters and maybe they are what's protecting the language from walking towards a bad path. We just have no way of settling this. In such fundamental disagreement, someone is bound to be unsatisfied with the outcome. Either we will manage to get auto-capture and see if it leads to a bad outcome or we won't have it. Either not having it is protecting the language or not having it is preventing a great step forward. There's no experiment, feature-flag or time-machine options. ... I can't help but see the irony that auto-capturing would create something "alien" to the PHP language and since we don't have that, there's a new proposal to create a different "alien" concept which is a kind-of-return within a block statement that doesn't exactly mean "return" (the <- token / resolve keyword). -- Marco Deleu
Re: [PHP-DEV] [RFC][Draft] Match block
On Fri, Sep 8, 2023 at 7:16 PM Ilija Tovilo wrote:
> Hello everyone
>
> I've been working on match blocks over the last few weeks.
> https://wiki.php.net/rfc/match_blocks
>
> I've already shared it in R11 and got conflicting feedback, which
> makes me unsure on how to proceed. We have a few options.
>
> 1. Add blocks only to match, possibly adding blocks to other
> constructs in separate RFCs (the approach of this RFC)
> 2. Support block expressions as a language-level concept, analogous to
> https://doc.rust-lang.org/reference/expressions/block-expr.html
> 3. Do nothing
>
> The two main complaints/questions I've gotten was whether this
> approach is the right one, and whether the syntax can be improved. The
> RFC tries to go into detail on explaining the rationale for the chosen
> approach. Additionally, it proposes a few alternate syntax options,
> although none of them are very satisfactory.
>
> At this point I'm unsure whether a proposal can satisfy all camps. Let
> me know if you have any thoughts/ideas.
>
> Ilija
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Hi Ilija,
This seems like an interesting subject for the PHP language, but
unfortunately doesn't take the direction I would much have preferred. The
use of `<-` to denote a different style of return statement in a block
feels quite "alien" (for lack of a better word) in the language for me. In
addition to that, I'm also not sure if there's anything else in PHP that
behaves differently when a return value is expected or not - this is in
relation to the difference between `$result = match()` vs `match()` without
expecting a result. If there's anything else in PHP that already has a
similar behavior, it might be worth adding it to the RFC so that we can
relate the subjects.
To me it would be much better to stick with the existing language
constructs just as-is.
```
{
echo "foo branch reached\n";
},
});
// foo branch reached
// NULL
var_dump(match ('foo') {
'foo' => {
echo "foo branch reached\n";
return 'this will be dumped';
},
});
// foo branch reached
// string(19) "this will be dumped
var_dump(fn () => {
echo "auto-capturing short closure invoked\n";
}());
// auto-capturing short closure invoked
// NULL
var_dump(fn () => {
return 'foo';
}());
// string(3) "foo"
$foo ??= {
bar();
};
var_dump($foo);
// NULL
$foo ??= {
bar();
return 'baz';
};
var_dump($foo);
// string(3) "baz"
```
There's a somewhat related discussion on this RFC
https://wiki.php.net/rfc/auto-capture-closure#multi-line_expressions which
comes to mind and was just 2 votes short of have been approved.
Other good-related RFCs are https://wiki.php.net/rfc/short-match and
https://wiki.php.net/rfc/short-functions which creates a really nice
symmetry in the language syntax.
Ultimately, this is a sad 10-year-long discussion (as summarised here:
https://externals.io/message/113740#113833) that seems impossible to move
forward within the PHP language. The door of creating of a block with
auto-capture look-and-feel much better across many different aspects of the
language, but it's always shutdown by enough long-time voters.
Overall, between the choice of creating a new syntax that "kind of
represents return statements on specific scenarios" or option 3 - do
nothing, I would prefer to do nothing until we manage to gather enough
voters to overcome the "no-auto-capture" camp.
--
Marco Deleu
Re: [PHP-DEV] PHP 8.3.0beta2 available for testing
On Thu, Aug 3, 2023 at 4:09 PM wrote: > PHP 8.3.0beta2 has just been released and may be downloaded fromhttps:// > downloads.php.net/~jakub > > Or use the git tag: php-8.3.0beta2 > > Windows binaries are available at:https://windows.php.net/qa/ > > Please test it carefully, and report any bugs athttps:// > github.com/php/php-src/issues > > 8.3.0beta3 should be expected in 2 weeks, i.e. on 17 Aug 2023. > > Hash values and PGP signatures can be found below or athttps:// > gist.github.com/bukka/31646ada5b94b4d2b78e0551905f5745 > > Thank you, and happy testing! > > Regards, > Jakub Zelenka & Eric Mann I just want to say a big thank you for PHP 8.3. I just ran about 2000 phpunit tests with it and 0 code change was necessary. I'm looking forward to upgrading! -- Marco Deleu
Re: [PHP-DEV] pipes, scalar objects and on?
https://wiki.php.net/rfc/short-functions > https://wiki.php.net/rfc/auto-capture-closure > https://wiki.php.net/rfc/partial_function_application > https://wiki.php.net/rfc/pipe-operator-v2 The only thing I can think of is if we gather a team of ~20 ppl and come up with a plan on collectively getting Voting Karma so that we can have these awesomeness revisited. -- Marco Deleu
Re: [PHP-DEV] Re: [VOTE] Interface Default Methods
Perhaps a little too late, but I was wondering whether folks that voted NO
would reconsider in case this was made a bit more opt-in.
There could be some bikesheding around syntax but essentially the idea
would be a new RFC targeting 8.4 with the following adjustment:
interface Foo {
public function bar() {
echo "hello";
}
}
class Out implements Foo {}
// RFC is ignored.
// Fatal error: Class Out contains 1 abstract method and must therefore be
declared abstract or implement the remaining methods (Foo::bar)
class In use Foo {}
// RFC takes effect.
class In extends Foo {}
// RFC takes effect but the class is no longer allowed to extend abstract
classes, only interfaces
class In with Foo {}
// RFC takes effect
class In as Foo {}
// RFC takes effect
==
In the spirit of minimizing impact, the proposed syntaxes only use keywords
already present in the language as to not run the risk of causing more
issues (https://www.php.net/manual/en/reserved.keywords.php).
This idea occurred to me when someone pointed out that they don't want to
implement interfaces which might bring code into their class.
Does this adjustment makes things better, worse or the same?
Re: [PHP-DEV] [VOTE] Interface Default Methods
On Thu, Jul 13, 2023 at 8:46 AM Brent Roose via internals < internals@lists.php.net> wrote: > I want to pitch in, agreeing with Larry's message here. > > - There are multiple real life use cases where the combo trait/interface > could be replaced by interface default methods > - Several modern language apply the technique in one form or another, so > it's already proven to be valuable > - There are a multitude of userland devs who'd benefit from this feature > - The only argument I've heard against this RFC is "it goes against my > definition of what an interface should be". I was also thought that same > definition, and I also had to unlearn it. Just like I had to unlearn the > "only one return per method rule" we were taught in college > > Brent > This was a valuable message for me. It helps me pinpoint my frustration with this RFC. - We have userland desire - There's prior art in other languages - It's already "doable" (Interface+Trait) - It adds a ton of convenience. - I have not seen any negative opinion about the implementation or impact on the php-src source code. What we're left with is either: - Let's have this but not on PHP 8.3 due to time constraint - Let's not have this If it's a time constraint, it would be good to hear more from folks that voted no so that it can light up hope. If it's just because voters don't want to let us have this then it's really just frustrating.
Re: [PHP-DEV] [VOTE] Interface Default Methods
On Tue, Jul 11, 2023, 7:32 PM David Gebler wrote: > Looks - sadly to me - like this isn't going to pass. I don't have vote > karma and if I did it wouldn't make a difference to the outcome, but it > would be really good for those of us who can't vote on the feature to hear > from some of the people who voted against it why they chose no. The > feedback from the discussion here seemed overall positive. It's one of > those things that's just a bit opaque to me, that quite often I see people > voting no on an RFC and we haven't heard from them in the relevant > internals threads, so we just never know why something was rejected or what > the author could have said or changed in the RFC to persuade them. > I share some of the sentiment. Although I think we have quite a few people without a vote here on this thread which might had been enough to approve this feature if we all collectively had a vote. Unfortunately the voting system is another broken problem without a fix and it's a really sad outcome at the end. This would had been one of the best PHP improvements since Construction Property Promotion and Short Arrow Functions >
Re: [PHP-DEV] [VOTE] Interface Default Methods
On Tue, Jul 11, 2023 at 10:54 AM Michał Marcin Brzuchalski <
michal.brzuchal...@gmail.com> wrote:
> Hi Robert,
>
> wt., 11 lip 2023 o 14:54 Robert Landers
> napisał(a):
>
>> ...
>> Abstract classes solve this problem perfectly. It's part of the type
>> system, it's type-hintable, it's mockable, and it's pretty easy to see
>> what inherits it as people who inherit it already know what the base
>> behavior was when they wrote the code.
>>
>
> Not exactly, How you wanna solve by abstract class two interfaces
> which can be implemented using let's say two traits - let's say
>
> interface Foo {
> public function foo(): string;
> }
> trait HasFoo {
> public function foo(): string { return 'foo'; }
> }
> interface Bar {
> public function bar(): bool;
> }
> traitHasBar {
> public function bar(): bool { return true; }
> }
>
> Now I can need to implement Foo or Bar separately or together.
> Using abstract class that would require 3 abstract classes: Foo, Bar, and
> FooWithBar.
> With this RFC that would require just two interfaces with default methods.
>
> Now you can easily see how bad this goes if you wanna add 3rd interface.
>
> Cheers,
> Michał Marcin Brzuchalski
>
>
I second this. Imagine a class extends LogAwareAbstractClass. It makes no
sense to the type system and it makes it impossible to extend something
that actually is part of the domain definition. Interface Default
Implementation is an elegant solution that doesn't change the state of PHP
while still making things easier and convenient to manage.
--
Marco Deleu
Re: [PHP-DEV] [VOTE] Interface Default Methods
> > Stop using `implements` at all and solely rely on `use`. > > My 0.02€ > > Cheers > > Andreas > A Trait is not part of the Type system, it's not type-hintable, it's not mockable, it's harder to do code review (a Trait was modified, what gets impacted?). A trait is just an "easy" way to copy/paste code while hiding away the code that is being copy/pasted. To be honest here, a Trait is something that I wouldn't miss if it was deprecated, although I know that's just wishful thinking. An interface default implementation on the other hand is extremely powerful and clear. If you're not happy with the default implementation, just write your own, otherwise less code to write and a better type system at the end. -- Marco Deleu
Re: [PHP-DEV] [VOTE] Interface Default Methods
On Sun, Jul 2, 2023 at 9:11 PM Levi Morrison wrote: > Chatter on the [Interface Default Methods RFC][1] has been quiet for > the past 6 days, and the feature freeze deadline is fast approaching > for PHP 8.3, so I'm moving this to vote. It'll be open for two weeks > as usual. > > Thanks to everyone who discussed weaknesses in the RFC during the > discussion phase. > > [1]: https://wiki.php.net/rfc/interface-default-methods > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > That's wonderful news Levi! Good luck to us all on this RFC!! -- Marco Deleu
Re: [PHP-DEV] [RFC] Interface Default Methods
On Tue, Jun 20, 2023 at 12:10 AM Levi Morrison wrote: > > I like the idea of this RFC - in fact it's one which has been near top of > > my wishlist for PHP language features for a long time - but I think this > is > > an issue with the proposed implementation which at the very least > warrants > > highlighting and discussion. > > I understand your concern but personally believe it's overblown. This > problem already exists with abstract classes, but doesn't seem to be > that much of an issue in practice. I hope static analysis can fill the > gap here, but don't think these checks are necessary to ship this > feature. > I agree that these checks would not be a requirement to ship this feature. I was thinking even further just as a thought experiment. Let's pretend for a second that these checks could easily be implemented, wouldn't it actually make it worse for the language as a whole? The only place where a method body would be forbidden to call `$this->foo()` ahead-of-time (compile-time or runtime with special error) would be on an interface default method. Everywhere else in the language would have the behavior of resolving the scope of `$this` and then attempting to actually execute the method. If the scope of `$this` has a `__call()` implementation, this would never lead to a "FatalError method not found" scenario, making these checks even weirder. What I'm concluding is that although it could have been nice to not allow these weird quirks, that ship has sailed decades ago and doing it on an interface default implementation (even if it was possible) would just create a major language inconsistency and it would always be best to implement this RFC without it regardless of technical limitations. -- Marco Deleu
Re: [PHP-DEV] [RFC] Interface Default Methods
On Thu, Jun 15, 2023 at 12:48 AM Levi Morrison via internals <
internals@lists.php.net> wrote:
> Hello, PHP Internals,
>
> I am moving my RFC for interface default methods to discussion:
> https://wiki.php.net/rfc/interface-default-methods.
>
> This can be a useful tool for a few reasons:
> 1. It can make implementing an interface easier when certain methods
> can be implemented by other methods in the interface. For example, if
> `Countable` had an `isEmpty(): bool` method, it could be implemented
> by doing `$this->count() > 0`. Of course, if an implementation can be
> more efficient, they are still free to implement it how they want.
> 2. It can mitigate BC breaks in some cases. It's somewhat common for
> authors to want to expand new methods onto existing interfaces over
> time. Although this would still be a BC break, it moves it from a
> massive change (every single implementor must add something, even if
> it's a stub, or it will fail to compile) to a naming collision issue
> only (only classes which already had a method of the same name will
> fail to compile).
>
> There is prior art for this feature in both Java and C#. There may be
> other languages, but I was aware of at least these.
>
> Note that the RFC links to a partial implementation. If there are two
> or more interfaces with default methods of the same shape (name, args,
> etc) and a class implements both interfaces and doesn't provide a
> concrete implementation, which default implementation should be
> chosen? There is a proposal for resolving this in some cases which is
> modelled after Java's implementation, but it isn't implemented.
>
> Thank you for your time. I look forward to productive feedback.
>
> Levi Morrison
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
A question just occurred to me. Building up on the example of the RFC, is
the following snippet valid and would it behave as expected?
```
interface Interface1 {
function method1() { echo __METHOD__ . "\n"; }
}
interface Interface2 {
function method1() { echo __METHOD__ . "\n"; }
}
class Class1 implements Interface1, Interface2 {
function method1() {
$result = Interface1::method1();
Interface2::method1();
return $result;
}
}
$result = (new Class1())->method1();
```
--
Marco Deleu
Re: [PHP-DEV] [RFC] Interface Default Methods
> > I still believe this information should be added to the RFC as the risk > of adding new methods to an interface which collide with existing > methods in implementations of that interface is very real, though I > agree with Deleu that this BC impact is not so much of the RFC, but of > what can happen once the RFC would be accepted. > > While I can understand the tendency to defer this question to "that's an > issue for userland when userland adds new methods to existing > interfaces" (or PHP itself if new methods would be added to PHP native > interfaces), I don't think that's fair as this RFC is the one which > opens the door to that possibility. > > Smile, > Juliette > Adding a new method to an existing interface is already a BC break today and requires a major version bump, otherwise implementers of the interface will get a fatal error because they're missing implementing all methods of an interface. We can call this a "Userland BC Path" (how a userland can make a BC to other users). This RFC doesn't open this door, it actually creates a path which makes this Userland BC Path less "damaging". If an interface provider adds a new method to an interface (already a BC Break), but does so by adding a default implementation, then such a change will break less code than just adding a method without a default implementation because only code that already had the exact same method name would now break. One can argue that this change might make it so that users start considering adding methods with default implementation as not-so-much-a-bc-break and do so without bumping a major version, in which case this RFC could be said to "open the door for some users to start introducing BC-breaks without bumping major version" because they consider it a much smaller BC break, but it can't be said to open the possibility. Does this make sense? -- Marco Deleu
Re: [PHP-DEV] [RFC] Interface Default Methods
I loved the proposal and I think this has the potential to be a huge developer experience improvement, perhaps at least as great as property constructor promotion and match(). Just a side note though, in the Backward Compatibility section, I would think that only "None" should be declared. From the PHP binary perspective, running code before and after this change has absolutely 0 impact/breaking changes. The feature may introduce a new way for *Users of PHP* to break BC with *Other Users of PHP*. The language change itself has no impact on PHP code written prior to the feature. The additional note about how users may break BC by using the feature would be a description of the feature itself, thus might be best declared as part of the Proposal instead. I wish us all the best of luck with this proposal. On Thu, Jun 15, 2023 at 12:48 AM Levi Morrison via internals < internals@lists.php.net> wrote: > Hello, PHP Internals, > > I am moving my RFC for interface default methods to discussion: > https://wiki.php.net/rfc/interface-default-methods. > > This can be a useful tool for a few reasons: > 1. It can make implementing an interface easier when certain methods > can be implemented by other methods in the interface. For example, if > `Countable` had an `isEmpty(): bool` method, it could be implemented > by doing `$this->count() > 0`. Of course, if an implementation can be > more efficient, they are still free to implement it how they want. > 2. It can mitigate BC breaks in some cases. It's somewhat common for > authors to want to expand new methods onto existing interfaces over > time. Although this would still be a BC break, it moves it from a > massive change (every single implementor must add something, even if > it's a stub, or it will fail to compile) to a naming collision issue > only (only classes which already had a method of the same name will > fail to compile). > > There is prior art for this feature in both Java and C#. There may be > other languages, but I was aware of at least these. > > Note that the RFC links to a partial implementation. If there are two > or more interfaces with default methods of the same shape (name, args, > etc) and a class implements both interfaces and doesn't provide a > concrete implementation, which default implementation should be > chosen? There is a proposal for resolving this in some cases which is > modelled after Java's implementation, but it isn't implemented. > > Thank you for your time. I look forward to productive feedback. > > Levi Morrison > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > -- Marco Deleu
Re: [PHP-DEV] RFC [Concept] - Interface Properties
On Sun, May 28, 2023 at 8:21 AM Jorg Sowa wrote: > Hello, > > I agree with David's statement: > > So yes anyay, my view is that between interfaces as we have them today, > > traits and abstract classes, there isn't a problem which needs to be > solved > > by now allowing properties on interfaces, but it would open up a > likelihood > > of encouraging things which are often regarded as anti-patterns. > > It could be abused creatively. Interfaces define the behaviour of the > object, not the data the object should contain. That's why the properties > are implementation details. Liskov principle describes the behavioral > subtyping, not the state. > Pretty much anything human-made can be abused creatively. And when it comes to coding practices and LSP, one person's anti-pattern is another's best practices, so the subjectivity is strong enough to void the argument. Although a few languages already support properties in interfaces (C#, > Java, Typescipt), so it's not rare case in other languages. However, I'm > not well oriented whether those communities have any problems with them. > Typescript interface property declaration is a wonderful example of data struct. When expecting a Value Object or a Data Transfer Object, instead of being forced to transform your own object into a library's expected object, TS will infer the object compatibility. Since PHP doesn't have the nature of type inference, we could accomplish a similar DX by implementing a library's interface into the VO/DTO. This would reduce a lot of boilerplate. A new PSR-7 version could greatly simplify working with Request objects by making use of public readonly properties on the interface rather than method calls. One could even argue that the current state of PHP actually encourages an "anti-pattern" of providing object data access through behavior rather than accessing properties directly because of the limitation in interfaces not having properties. > My though about this topic. Wouldn't allowing abstract properties in > abstract classes resolve the issue of 'enormous amount of boilerplate code' > without touching interfaces, Zoltán? > > Kind regards, > Jorg > No, because abstract classes aren't a replacement for interfaces. I find the Template Pattern to be a good use case for interfacing through abstract classes and they could benefit from abstract properties, but all of inheritance's shortcomings are still present in abstract classes and not on interfaces. -- Marco Deleu
Re: [PHP-DEV] PHP Package for PHP
On Thu, May 18, 2023 at 6:56 PM Rowan Tommins wrote: > On 18 May 2023 20:15:44 BST, Deleu wrote: > > I meant exactly the opposite. Monolog is an example of what PHP (is > missing > > === doesn't have enough of). There's hardly any reason to re-release it > > under the PHP umbrella. Monolog already won the log battle. I can't say > the > > same for virtually anything else, to be honest. Some folks might say that > > Guzzle won the HTTP battle, I just disagree and think we could have > > something better by default > > > Let's look at HTTP clients then. > > PHP is certainly lacking a good one built in. Using streams with > allow_url_fopen is serviceable for fetching a page, but not much else; the > curl functions are ... embarrassing. [..] On the other hand, a clean API with a much smaller feature set, which could > be used on its own for simple use cases, and be the low level > implementation for Guzzle, Symfony HttpClient, etc, would be extremely > useful. In other words, an overhaul of the curl functions to give the same > flexibility, but an API that feels more native to PHP, rather than a thin > wrapper around the C functions of libcurl. Let me start from here where we agree on. We start by designing a new PHP package to wrap cURL. Bear in mind for a minute that I started this thread with the intention of lowering the barrier of getting RFC approved and the code being maintained by PHP developers. After some good amount of bikeshedding we approve the first PHP package. It is fully covered by automation tests so that future maintenance is relatively easy. It gets released under the namespace Php\8.4\Curl. I'm going to be greedy here and assume we even get it bundled inside PHP. Before PHP 8.4 gets released we also work on Php\8.4\Strings package. For the sake of argument let's pretend that within 1 month of PHP 8.4 release we discover that the Curl package was actually really bad and we decide to rework it. A new RFC is approved and we bundle a new design under Php\8.5\Curl. Meanwhile Strings was a success and no new version is warranted. So Php\8.5\Strings does not need to exist. Now both new designs are still great and Php\8.6\Curl and Php\8.6\Strings do not need to exist either. Perhaps someone raises an RFC so that PHP 8.7 will unbundle/eject Php\8.4\Curl and keep only Php\8.5\Curl inside PHP. It's a breaking change, but one that just means we now move the code to being Composer-only instead of bundled inside PHP. It's a "deprecated" package that can just exist on GitHub for backwards compatibility. A few more years go by and another RFC comes in to abandon Php\8.4\Curl from the PHP Group. This whole story, from a user standpoint, screams stability. If a project starts using Php\8.4\Curl and gets so deep into it that it's too expensive for them to upgrade, they can just keep using it without upgrading to the 8.5 counterpart while still upgrading their PHP binary. If it gets unbundled, they can just `composer require` it. If years go by and the package gets abandoned, they can still fork it and pretty much no code change would be necessary. With namespaces, PHP Packages get to do "Editions" without all of the complexity of doing editions at the engine level. Written in PHP, it can easily get ejected out of the PHP binary and still be "backward-compatible". PHP seems to be at a corner where it's best not to do anything than to make another mistake. A mistake made in the design of the language takes decades to undo. I believe we can improve the language's basic functionality this way and slowly grow into wrapping most features needed by the majority of web applications. We could start with just wrapping libcurl in a nicer API and if it works out great we could do more until one day we end up even providing a slim HTTP Client. The PHP community as a whole (regardless of which framework camp you are in) as well as newcomers could only benefit from it. -- Marco Deleu
Re: [PHP-DEV] PHP Package for PHP
On Thu, May 18, 2023 at 2:35 PM Rowan Tommins wrote: > On Thu, 18 May 2023 at 16:27, Deleu wrote: > > Monolog is a great example of what PHP is missing - a single library for a > > purpose. I have never worked with any other library besides Monolog and I > > never worked on any project which didn't have it installed. Perhaps my > > bubble might be a limiting factor here, but I get a feeling that Monolog > is > > considered to be The Logging PHP Library. > > > > > Then in what sense is it "missing"? What value would be served by placing > an elephant logo on it, and renaming it "PHPLog™"? > I meant exactly the opposite. Monolog is an example of what PHP (is missing === doesn't have enough of). There's hardly any reason to re-release it under the PHP umbrella. Monolog already won the log battle. I can't say the same for virtually anything else, to be honest. Some folks might say that Guzzle won the HTTP battle, I just disagree and think we could have something better by default, such as Python's `request` Library, but I can also see such controversy being lost and leaving PHP without an HTTP Client built-in. That would be a matter for each individual RFC. > > Laravel's `Arr` class also didn't get scrutinized by PHP RFC so there's > no > > way to know whether it's all good, some good or all bad. > > > > > I don't think PHP's decision-making process can be held up as a shining > example of good governance, in contrast to everyone else's anarchy. I don't > know much about Laravel's governance, but I am quite sure every change is > discussed and iterated on before release. In fact, they probably have a > whole bunch of standards and processes that PHP is lacking, and would have > to invent to make any new library a success. > I didn't mean anything about PHP's governance, to be honest. I am, however, very aware of the community battle around frameworks. I like Laravel's Arr class, but there are PHP developers that hate all things Laravel. What PHP governance brings here is that if it can't be agreed on, it won't be included. So perhaps an RFC discussing PHP's Array functions could end up taking some of Laravel's implementations or none. My point here was mostly about the fact that a PHP Standard Package addition going through PHP RFC has a lower entry barrier compared to built in C, but a higher entry level than anybody in the PHP community creating a package they personally like for themselves. The combined experience of internals participants is at least pretty good to bring a lot of perspectives. -- Marco Deleu
Re: [PHP-DEV] PHP Package for PHP
On Thu, May 18, 2023 at 11:43 AM Reinis Rozitis wrote: > > I have worked with PHP for 14 years now and I know nothing about PEAR. > It either says something about me or about PEAR. > > Then the next logical question would be do you know what PECL is? :) > > But to be short my point is - before attempting to get new function(ality) > in core it (seems to me) that more realistic if you really want to achieve > that is at least by presenting some kind of working base blocks especially > when there are all the means to extend the language both on low level > (being an extension) or a pure-php package in any of the existing channels > (composer / push for repopulation of PEAR? etc). > My wish here is not to present a new functionality to core, but rather start a project which lowers the barrier for getting basic things into core. Sure, I could write a new Str class and fix all the problems I think the `str` and `str_` lib has. In fact, everyone can do that [1][2][3][4]. PHP current state actually encourages the language to have multiple competing implementations for the same thing because some past decisions are hard to be fixed and introducing things to the language are also hard. The competition and the diversity addressing all sort of problems is a strength in the PHP Community, but also a weakness in PHP's ability to provide a bare minimum that help newcomers to get started and veterans to only reach for deviation when it is made necessary. > > There is usually the argument - "if this is not in core no one (people on > shared environments/hosting) won't be able to use it" and so on.. The > counter to that are things like Imagick / redis / memcache(d) / APCu which > are vastly popular but still live outside core (obviously those are not > language rather than engine features). > > rr > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php I wouldn't argue in favour or against shared hosting. I haven't used that in a decade so I'm really not the best person to talk about that universe. If someone were to create a PHP Extension to rewrite some of PHP's functionality and/or cover PHP's standard library gaps, I know I wouldn't spend a minute of my time looking into it or installing it. I imagine that it would take many years until someone could actually build up a reputation and a library quality until it could start being considered for adoption. [1] https://github.com/spatie/string [2] https://laravel.com/api/9.x/Illuminate/Support/Str.html [3] https://symfony.com/doc/current/components/string.html [4] https://github.com/azjezz/psl/tree/next/src/Psl/Str -- Marco Deleu
Re: [PHP-DEV] PHP Package for PHP
On Thu, May 18, 2023 at 11:27 AM Rowan Tommins wrote: > On Thu, 18 May 2023 at 14:12, Deleu wrote: > > > > Or PEAR? > > > Like that particular path_join() request is exactly > > > > > > https://pear.php.net/package/File_Util/docs/latest/File/File_Util/File_Util.html#methodbuildPath > > > > > > I have worked with PHP for 14 years now and I know nothing about PEAR. It > > either says something about me or about PEAR. > > > > > For many years PEAR was the official package repository for PHP. The client > was shipped with every install of PHP, and still serves as the basis for > PECL, the official distribution for PHP extensions. > > From the point of most users, it has been entirely replaced by Composer, > and I think some of the reasons for that are very relevant to this > discussion: > > - PEAR required a package to be installed globally on a server; Composer > allows (and encourages) it to be local to a particular project > - PEAR was a "walled garden" - you had to request permission to publish a > new package, or take over an existing one; Composer is a "bazaar" - anyone > can publish a package to Packagist, and projects can be forked > - PEAR tried to be a cohesive ecosystem - it had a unified coding standard, > and a strong policy of package interoperability, aiming for a common "feel" > across all packages; Composer leaves developers to combine packages however > they want > > On the one hand, PEAR was a single "baseline" that everyone expected; on > the other hand, packages tended to be slow to adapt to new needs and > fashions, and inflexible to different environments. So instead, people > moved to: > > - Frameworks; which themselves have mostly adopted a "component-based" > approach interoperating via Composer packages > - Non-framework groups like The League of Extraordinary Packages > https://thephpleague.com/ > - Single packages that have become de facto standards - large projects like > Guzzle and Monolog; and smaller utilities that do one task well, like > Ramsey/UUID > Thanks for the history lesson, this is super useful information, indeed. Monolog is a great example of what PHP is missing - a single library for a purpose. I have never worked with any other library besides Monolog and I never worked on any project which didn't have it installed. Perhaps my bubble might be a limiting factor here, but I get a feeling that Monolog is considered to be The Logging PHP Library. Guzzle is a near 2nd, but not quite there, especially after Symfony built their own HTTP Client and further drove the community split. Laravel has an amazing `Arr` class that wraps most of PHP's array_* standard library and I love it and find it amazing, but it's a niche community within PHP. Newcomers might get exposed to community debates[1] that end up driving them away from taking advantage of a better array_* suite. Laravel's `Arr` class also didn't get scrutinized by PHP RFC so there's no way to know whether it's all good, some good or all bad. > > There are two ways I can see a "standard PHP package" working: > > - As a server-wide install, part of the distributed PHP. That inherits all > the downsides of PEAR, but might be appropriate for a fairly small subset > of really low-level functions. > - As a set of Composer packages, managed completely outside the PHP > lifecycle, in which case it's not clear how it would be different from all > the packages that are already out there. > > Bottom line, I think there is some merit in having part of the standard > library be written in PHP rather than C, but we'd still want to be very > conservative in what went in there, because most of the downsides of > locking it to the PHP release cycle would still be there, and Composer > seems to be serving the community pretty well for a lot of functionality. > > Regards, > -- > Rowan Tommins > [IMSoP] I also see both options for this to work, but honestly I have no strong feelings either way. For me it's pretty clear that a set of Composer packages offering standard libraries under the PHP namespace and limited to what gets approved by RFCs would be a lot different from all the packages that are all there because it takes away all the time and energy collectively spent in evaluating options and their reputations. We can get started with what PHP offers by default and delay the evaluation process until the PHP standard library no longer supports the use case. It's the standard option and is covered by PHP's reputation. If your use case is not standard, you might reach for a community-provided library that enhances the standard library needs or build your own instead of always having to use a community-provided library or build your own
Re: [PHP-DEV] PHP Package for PHP
On Thu, May 18, 2023 at 8:55 AM Reinis Rozitis wrote: > > Which begs the question of a PHP Package for PHP. Some benefits: > > > > - Written in PHP, it will allow a much wider pool of contributors than > the > scarce pool of C developers contributing to PHP source code. > > Aren't this what frameworks are for (Laravel / Yii / Symfony / Zend etc)? > I don't believe they are. What they do is try to fill the language gap by creating competing implementations for common tasks, which then led to the rise of PSR in an attempt to further address competing abstractions. We definitely can keep living like this and forget about this matter. My wish here is just to be able to address a shortcoming PHP has with its standard library. My interpretation is that the PHP standard library was born in a completely different era and was a source of unpleasantness. It is a burden of maintenance on C developers and it has very little room for mistakes since once it's embedded in the language a breaking change has a devastating impact, which led to the current state of: "if it can be done in userland, it most likely should unless there's extremely strong reason not to". The bar of improving the standard library is too high and userland does not have the ability to define one common implementation that can be used across every project. The only entity that could take a step towards improving this is the PHP project itself. Why should PHP take on such a burden? - It's a greenfield opportunity within the language. I get a vague sense that it slightly resembles Kotlin for Java or Typescript for Javascript. Such opportunity could make a huge difference. - The burden on the current contributors of internals would mostly be about RFCs and discussions. PHP developers would jump in to provide implementation and maintenance. If I'm wrong here, then the project can just die out. I like Dan's description of an RFC here: > It might be better to think of the RFC process for new features to be > a decision on "should this feature be in PHP?" rather than a "must > this feature be in PHP?". If the PHP community cannot come in together to provide the implementation of PHP code for an approved RFC, then the PHP community does not need the benefit of it. - Plenty of opportunities for mistakes. If a design/implementation turns out to be wrong, we can leverage namespaces to "fix that" while keeping backward compatibility for the language at a very low maintenance burden. - High opportunity for improved user experience. If PHP implementation of something doesn't work for your particular use case, you can just ignore it and implement your own. But if done right, we can likely address 80% of use cases with standard libraries and allow developers to leverage these implementations across every single PHP project with no extra effort for the user. - Improved perception of the language itself. This helps attract newcomers to the language and reduces the burden of learning some of the PHP quirks of its standard library. - Modernization of PHP standard offerings and a home for language improvements with a lower entry barrier Perhaps I'm just in a honeymoon trap with the idea which might be blinding me to its downsides. The only one I truly see is the amount of discussion and bikeshedding within PHP Internals until implementations land. I don't know how bad it could get and how it would affect contributors' emotional energy. But I don't expect it to be bad. I expect it to be PSR on steroids. And it would be for a limited time. There's only so much we can offer in a standard library. And then we can enjoy its benefits for many years to come. > Or PEAR? > Like that particular path_join() request is exactly > https://pear.php.net/package/File_Util/docs/latest/File/File_Util/File_Util.html#methodbuildPath > > rr I have worked with PHP for 14 years now and I know nothing about PEAR. It either says something about me or about PEAR. -- Marco Deleu
[PHP-DEV] PHP Package for PHP
Hi folks! Reading through https://externals.io/message/120323#120326 and https://externals.io/message/120323#120332, it reminded me of a few times I've seen similar debates on internals about "why not do this on userland?" and the consensus seems to be inclined to only take the maintenance burden of internals function if there's strong justification for it regardless of whether there's consensus of being useful or not. Which begs the question of a PHP Package for PHP. Some benefits: - Written in PHP, it will allow a much wider pool of contributors than the scarce pool of C developers contributing to PHP source code. - Being official means it inherits the trust PHP already has - Green field development in this day and age often comes with a great set of automation tests that drastically lowers the maintenance burden - Possibility to standardize a lot of common code that has countless userland implementations - If we make a mistake of implementing a bad design, the worst thing might be that we "wasted" a good word in a function or class name. As long as test coverage is there we can probably just keep it running for many years with little negative impact other than "yeah, PHP did a bad job at X". Such a project could benefit from the RFC process already in-place and voters could take into consideration the lower maintenance burden when voting for something that they think it's useful. One relevant downside is that internals might get flooded with RFCs for filling up some common functionalities for a few years until it dials down a bit. It may also lead to re-discussing PHP's entire standard library. The work to get started seems to be about: 1- Getting an RFC to approve this idea itself 2- Getting a repository to host the PHP package code. 3- CI/CD 4- Release Management 5- Versioning Strategy 6- Package naming convention 7- Distribution strategy (single package vs multiple sub-packages) 8- PHP developers and community contributions Anything I'm missing? Thoughts? -- Marco Deleu
Re: [PHP-DEV] Expansion of PHP Symbols?
classes on the same file. PHP Autoloading functionality is 90% there and we would just need function autoloading, type aliases definition and PSR-X + Composer static symbol scanner (something that seems to already exist?) to make it a great developer experience. If you don't use Composer, nothing gets worse (except maybe function autoloading + performance), but if you use composer already, this can be a seamless transition and perhaps even bring more interest towards preloading. To maybe beat up more on function autoloading, if I understand correctly the current open proposal sidesteps the performance impact by making function autoloading a "separate autoloading filtered by type" kind of mechanism. If you upgrade from PHP 8.x to 8.x+1 with no code changes, your performance impact is zero. Your first performance impact arises when you register a function autoloading (making it opt-in) & then you can choose to opt-in by using a strategy that perhaps allows you to fade away the performance impact with the Composer Static Scanner dumping mechanism. I feel like this all sounds too good to be true/possible because if it were easy, it would maybe have been done by now. Even if we park function autoloading altogether (for its controversy) and focus just on type aliases, the question remains: Why is it not possible to make Type Alias the same way that Enum was recently introduced? -- Marco Deleu
Re: [PHP-DEV] Expansion of PHP Symbols?
On Fri, Apr 21, 2023 at 6:02 AM Rowan Tommins
wrote:
> Hi Marco!
>
> I'll come back to type aliases in a second, but first:
>
> > can `function bar() {}` be a symbol?
>
> It already is. When you run foo('bar'), PHP has to look up what the
> definition of "foo" is in a table of functions. In principle,
> autoloading could work for those just the same way it does for classes
> ... except for one awkward feature which seemed like a good idea 15
> years ago. If you write this:
>
> namespace Foo {
> echo strlen('hello');
> }
>
> Should PHP lookup the function "\Foo\strlen", or the function "\strlen"?
> The "clever" answer 15 years ago was to do *both*: try the namespaced
> name first, then if it doesn't exist, try the global name. This does not
> happen for classes, only for functions and constants.
>
> This is a real pain for autoloading: how do you avoid repeatedly calling
> the autoloader looking for "\Foo\strlen", finding there's still no
> definition, and falling back to "\strlen"? That's one of the main points
> of discussion whenever function autoloading comes up.
>
>
This is super interesting, thank you for the info. I guess maybe I'm a bit
naive on why there would be controversy here. I see it kind of like this:
- PHP looks up \Foo\strlen. It's not on the Symbols table. Trigger autoload
for it.
- Autoload finds a definition, register it on the Symbols table and execute
\Foo\strlen
I'm guessing this already works today. Now let's see the other case:
- PHP looks up \Foo\strlen. It's not on the Symbols table. Trigger autoload
for it.
- Autoload does NOT find a definition, register in the Symbols table that
\Foo\strlen is undefined.
- PHP looks up \strlen. It's not on the Symbols table, trigger autoload for
it.
- Autoload finds a definition, registers in the Symbols table and executes
\strlen.
Since \Foo\strlen already had an autoload execution, it already had a
chance to be loaded, if it wasn't we can "cache" that result. However, if
the script is doing something crazy, we can let the definition of
`\Foo\strlen` be overwritten if it ever gets "naturally discovered as a
symbol". That is, if you e.g. try to use a class \Foo\Bar and autoloading
loads the file ./foo/Bar.php and inside that file there is a definition for
`\Foo\strlen`, even though `\Foo\strlen` has already been written as
"undefined", the Symbols table could overwrite the "undefined" value
instead of crashing with "\Foo\strlen already exists".
This wouldn't go against PHP's core nature and it would avoid triggering an
autoload for the same function over and over again even though it's
naturally expected that it will not exist.
I can imagine one would argue that caching every native function with a
huge amount of namespace with a "undefined" definition could take up some
memory space, but wouldn't that just encourage the PHP Community, PHP IDEs
and static analysers to promote top-level file `use function \strlen`,
avoid the recursive trial-and-error and avoid registering many namespaces
and consuming more memory? It's already natural (and not just in PHP) for
IDEs to just hide the entire import statement block, so :shrug:
Here at least I can understand why it's a bit controversial. The obvious
solution to me might not be an acceptable take for other people and it's
somewhat understandable.
> > Can `type Number = int|number;` be a symbol?
> > Can `type TwoInts = callable(int $x, int $y): int;` be a symbol?
>
> Fundamentally, yes. They'd probably need to occupy the same lookup table
> as classes - if I write "function foo(SomeType $someArg)", PHP doesn't
> know until it's looked it up whether "SomeType" is a type alias or class
> - but that's not a big problem.
>
> I think there is some discussion around whether people *want* it to work
> that way - should it be more like a "use" statement, and just take
> effect for the current file? Then there's questions around how to
> actually implement it, and do so efficiently. But creating a table of
> names to types isn't the hard part of the problem.
>
>From Rob's email (https://externals.io/message/120094#120097), the argument
against a simple "use" statement seems quite natural. I certainly don't
want to redefine "use int|float as Number" in every PHP file I work with,
so naturally we would go back to type alias definition, symbol registration
and autoloading. So I guess my final question is: what is fundamentally
different about Type Alias when compared to interfaces, classes, enums that
make this controversial?
--
Marco Deleu
Re: [PHP-DEV] Expansion of PHP Symbols?
On Fri, Apr 21, 2023 at 4:10 AM Robert Landers
wrote:
> Hey Deleu,
>
> I ended up on this list in the first place because I wanted to figure
> out how to implement type aliases. I can confidently say why no one
> wants to touch it with a ten-foot pole: implementing this will require
> refactoring the entire type system. There currently isn't a 'type
> table'; supporting type aliases will probably require one.
Hey Rob, thanks for this info! I just have some small follow-up for me to
make some sense of it.
What is fundamentally different about Type Alias as opposed to something
like Enums that was recently introduced?
```
enum Options{}
class Options{} // Fatal error: Cannot declare class Options, because the
name is already in use
```
What I would expect here is
```
type Number = int|float;
class Number {} // Fatal error: Cannot declare class Number, because the
name is already in use
```
When the engine needs to know about a type alias and it's not in the
symbols table, trigger autoload. When the type alias is registered, check
if it's value matches what was sent (Type checking). I can kind of imagine
the implementation of this could be somewhat awkward because it would
involve `instanceof`, `is_int()`, `is_float()`, `is_string()`, etc -
meaning we don't have a unified verification system/syntax that encapsulate
types and scalar types all at once, but it's not like we have infinite
scalar types so it's still doable?
> I was able
> to hack something together that used the import statements as a way to
> work without that much changes (I never got autoloading to work, but I
> suspect that was my unfamiliarity with the code, not that it was
> impossible):
>
> use int|float as Number;
>
> at the top and it would work with fairly minimal changes to the
> engine. Anything more complex or different required a huge
> refactoring. However, from previous discussions, when that syntax was
> brought up, it was shot down. It appears that people want code-wide
> aliases, which goes back to refactoring (to the point of
> re-implementing an entire type system) and people can't agree that
> it's a good idea in the first place (i.e., what if you think int|float
> is Number, but some other library has only float aliased to Number?)
> and then that can be solved via imports ... but how does that work?
>
What if you think `\Marco\Deleu\Stringable` is something that works like
PHP strings, but it turns out it's actually a math interface that only
works with numbers? I know I'm exaggerating, but it's only to make it more
obvious that namespaces have solved that problem a long time ago. A library
can use `\Lib1\Number = int|float` and make use of it internally and I can
also import that. If I want to import `\Lib1\Number` and `Lib2\Number`
simultaneously, we have
```
use \Lib1\Number as Lib1_Number;
use \Lib2\Number as Lib2_Number;
```
They can be different things and mean different things and be used
differently. PHP has "solved" this problem ages ago. If users want a
standard meaning for Numbers, PSR can do that. If there is consensus on
what `Number` should be, perhaps we will have a `psr/type-aliases` package
that defines common type aliases and everyone that wants it can use it for
interoperability.
Sorry if it sounds stupid or obviously broken, I really am just looking to
understand where my rationale flaw is.
--
Marco Deleu
Re: [PHP-DEV] [Discussion] Callable types via Interfaces
On Thu, Apr 20, 2023 at 8:23 PM Levi Morrison via internals < internals@lists.php.net> wrote: > I'm going to stop here. Two big things: > > 1. I think reducing verbosity can be left for the future. We don't > have to solve that right now. > What happens if I pass a short-closure? > > takeTwo(fn ($x, $y) => $x + $y); > > I would be annoyed if I had to write the type info, but particularly > the return type. > Sorry for the unhelpful email, but does anybody else see the irony here? It's just too funny to not be mentioned -- Marco Deleu
[PHP-DEV] Expansion of PHP Symbols?
Hi Internals, sorry for the potential long email, but I can't sleep and I
want to dump this out of my brain.
Just a quick intro, let's recap PHP simple nature with this index.php file:
```
https://wiki.php.net/rfc/core-autoloading) and Callable Interfaces (
https://externals.io/message/120083) and particularly this comment
https://externals.io/message/120083#120088 which I'll take a snippet here:
Mainly the type alias question. Every time I see callable types discussed,
> it immediately sidetracks into "how do we make that less fugly to write,
> because callable types are naturally very verbose?" That leads directly to
> typedefs/type aliases, which take one of two forms:
type TwoInts = callable(int $x, int $y): int
> type LinkedResponse = ResponseInterface
> which raises autoloading questions and means a dependency on a type
> defined in another package, in many cases
Here I want to raise the discussion about the little I know about PHP
symbols. If a symbol `interface Foo` is discovered and registered by PHP,
it will be usable as an interface throughout its entire execution. If the
symbol is not discovered and is used, it will trigger autoloading as a
last-chance before fatal error.
Can `type Number = int|number;` be a symbol?
Can `type TwoInts = callable(int $x, int $y): int;` be a symbol?
and lastly, can `function bar() {}` be a symbol?
Here is how I see that unfolding:
file-1.php
```
```
file-2.php
```
```
file-3.php
```
```
How do we solve this?
- Include/Require
- Custom Autoloading
- Composer/PSR-4
Sounds familiar?
PHP already has a namespace to solve for grouping of types such that
`\Foo\Bar` and `\Bar\Bar` can already co-exist because they are two
different symbols. We already rely on classes/interfaces/enums defined on
third-party packages, why not make type aliases work the same?
And if functions could be symbols, it would work out the same as well.
One limitation I see is that symbols cannot have conflicts.
Enum/Interfaces/Classes cannot be named exactly the same under the exact
same namespace. Type Alias would follow the same limitation. Function would
be able to escape one part of that limitation if the engine could prefix
every function name with `f_` or `fn_` when registering its symbol, making
it backward compatible and allowing `class Foo` and `function Foo`
co-exist, but not two functions called `Foo` (which is already an error
anyway).
Now one questionable user experience I see is defining:
- 1 Class = 1 File
- 1 Interface = 1 File
- 1 Enum = 1 File (this is already annoying)
- 1 function = 1 file
- 1 symbol = 1 file
But this user experience does not come from PHP's nature, but instead it
comes from Composer/PSR-4 because PSR-4 maps namespaces to directories and
symbols to files. We need a static analyser to scan our entire project,
discover every symbol and create a mapping such as:
- Symbol Class_Foo -> x.php
- Symbol Interface_Bar -> x.php
- Symbol Enum_Options -> y.php
- Symbol Enum_ExtraOptions -> y.php
- Symbol fn_foo -> z.php
so that our registered autoload can include/require the necessary file when
the symbol triggers an autoload. This static analyser already exists and is
called `composer dump-autoload`. It just has not implemented a PSR-X which
allows for this pattern?
In conclusion
PHP Scripts are very simple and dummy things and it already has a
limitation of symbol discovery. We have already built tools to work with
that limitation around autoloading/psr/composer. We could extend the PHP
Symbol system to include functions and type alises. If this can be done in
a backward-compatible manner, we can already integrate those into PSR-4
from day one. Lastly, we lift the social-construct limitation of 1 file = 1
symbol with PSR and Composer since PHP never really had this limitation
built-in. We come out of it with 3 major wins (from my pov):
- Function autoloading
- Type Aliasing
- Never creating 3 files for 3 Enums again
If you managed to read up to here, I apologize for late confessing I know
nearly nothing about PHP internals codebase. Is this obviously wrong and am
I just hallucinating a new awesome PHP version here?
--
Marco Deleu
Re: [PHP-DEV] [Discussion] Callable types via Interfaces
On Thu, Apr 20, 2023 at 2:25 PM Larry Garfield wrote: > But that runs quickly into the problem of verbosity, reusability, and type > aliases, and the discussion usually dies there. > Just out of curiosity, was there ever a discussion thread dedicated for Type aliases? I couldn't find it on externals.io and I was curious to know what are the challenges there since a lot of time and effort seem to have been put on trying to sidestep it. -- Marco Deleu
Re: [PHP-DEV] PHP Modules
On Tue, Apr 11, 2023, 11:32 AM Larry Garfield wrote: > But the same people will still complain just as loudly whenever that is, > because they haven't done anything about it for the past 17 years so > they're not going to now. > Do you know that for a fact or should this statement be classified as, and I'm quoting here, "BS"? >
Re: [PHP-DEV] Future stability of PHP?
On Tue, Apr 11, 2023 at 5:40 AM Alex Wells wrote: > On Tue, Apr 11, 2023 at 6:10 AM Deleu wrote: > >> I don't want to use those weird stuff, but I'm >> doing the best I can to replace every single line of old code that has >> been >> written in an era that "best practices for PHP development" were not what >> you and I know today. >> > > I still do not understand why you're expecting the whole PHP project to > put in enormous efforts to keep the backwards compatibility and solve your > problems (temporarily) instead of you doing so. What's stopping you from > using the last supported PHP version by that codebase and fixing or, worst > case scenario, rewriting it if you wish, while on that (non latest) PHP > version? What causes the desperation to update to the latest PHP? Is it new > features or security fixes, or both? > I don't *expect* the whole PHP project to do anything. Let me start by bringing up a quote: > [...] your thoughtful insight on how language changes [...] will help shape proposals in a much more significant way. Disclaimer: This quote is taken out of context, the original message can be found here: https://externals.io/message/110936#110937 As I've mentioned here before, I've seen a few folks bring up the message that I see on this quote as: Voting rights are not necessary to contribute to PHP Internals. PHP is an extremely large ecosystem and bringing community/user voices to internals can greatly help developers understand how the language is being used and how proposals can be shaped to help address concerns that are made aware. I'm not voicing my concerns in the hopes of making my problems your problems and that the PHP core developers should fix it for me. I have been going through a rewrite for the last 6 years and I expect to be done with it in the next 5. Every year we need to go back to the legacy spaghetti and upgrade it for security reasons. It's busywork and adds no real value to us. We still do it and we will keep doing it no matter what. But in the course of doing so, I lost coworkers to Typescript with a reasoning that it doesn't make sense to rewrite our product in a language that will keep breaking the codebase constantly. I'm not here to discuss the merits of their decision because if I 100% agreed with that decision, I wouldn't be here, I would be long gone and developing Typescript fulltime by now. But in my little bubble, losing highly talented PHP developers to Typescript has been a recurring situation and that loss of community members saddens me. So if you could please read my message as "here's what has happened in a small corner of the PHP community that is directly related to what OP has mentioned at the start of the thread (PHP stability). Maybe this is not new information to any of you here and there's nothing that can be improved on it unless someone drops 8 digits of money on the PHP project. Maybe that is a price that PHP has been willing to pay to keep on doing what it currently is doing. Or maybe there are some interesting things that can be taken into consideration. Do what you will with my participation. The only expectation I had when I joined this discussion was respect and that was almost completely met. -- Marco Deleu
Re: [PHP-DEV] Future stability of PHP?
On Mon, Apr 10, 2023 at 7:03 PM Larry > > Again, let's assume there is no question it will happen. The question for > you: What process for making it happen would you consider sufficiently > BC-friendly? What timeline? What level of pre-review? What reasonable > process would you propose that maximizes the ability of the language to > remove its own design bugs while minimizing the hassle for responsible > developers? (Responsible: They actually pay attention to upcoming changes > and prepare for them in less than 7 years.) > What I would consider sufficiently BC-friendly is having a cut-off. Any code written by the previous generation (folks that are long gone or retired by now) continue to work as it used to while I catch up in removing it from production systems. If the code was written in 2010 or earlier and uses $a++; with the expectation that it will result in "b", leave it as-is. If the code was written in 2018 or earlier, feel free to break it. Several discussions around this have happened, but unfortunately none landed anywhere. Whether it be a new opening tag of
Re: [PHP-DEV] Future stability of PHP?
On Mon, Apr 10, 2023 at 6:42 PM Arvids Godjuks wrote: > > > On Tue, 11 Apr 2023 at 00:03, Deleu wrote: > >> >> >> On Mon, Apr 10, 2023, 4:01 PM Arvids Godjuks >> wrote: >> >>> >>> >>> >>>> *snip to keep the email short* >>>> >>>> >>> Hello Deleu, I want to highlight your response specifically, because you >>> blame the wrong people here. >>> This is the failure of the business owner to plan accordingly and ignore >>> all the warnings for years and decades. That is if any developer raised any >>> concerns lately, which I also have seen quite a bit when "yes man" just >>> shove code into the meatgrinder for a year or two and then just move to the >>> next job: "It's not my problem, the next guy will deal with this". And that >>> feeds the vicious cycle, and the owner is either oblivious or does not >>> understand the implications because "well, it works, it generates money" at >>> the moment right until that plane hits the ground and things blow up. >>> I've handled a big legacy project, did major updates to it, seen how an >>> effort of 1 month of my time to drag it into the modern day paid off over >>> the next 6 months by picking up development speed by 3x with the same team >>> of 5 people + me. In 1 year we started to literally take away clients from >>> our competitors who could not keep up with us and we had a literal line of >>> clients to onboard, we had to scale our sales team 3x and had a backlog of >>> 6 months still. All stemmed from a single decision "I will tackle this, we >>> need it to update to newer PHP". Business owners were really stoked that >>> they actually listened to developers. >>> >>> You cannot expect to run code that was written 2 decades ago without >>> major updates on modern language versions. It's not possible for almost any >>> language that is being actively developed. Think laterally - instead of >>> hand-fixing every null check out there, introduce a library that can handle >>> data structures and handle the nulls for you en mass. Isolate the internals >>> and just pass already sanitized values into it. Suddenly you cut off like >>> 90% of the needed fixes that prevent you from running your code. It's still >>> needs fixing, but at least you give it good data to start with, so it does >>> not error out. >>> -- >>> >>> Arvīds Godjuks >>> +371 26 851 664 >>> arvids.godj...@gmail.com >>> Telegram: @psihius https://t.me/psihius >>> >> >> Thanks for your reply, I understand everything you mean here by improving >> a development flow. I've been responsible to for doing that improvement for >> the past 6 years and I'm pretty close to retiring 100% of the legacy code, >> but I still need a couple of years to do it. I have long ago convinced the >> people in my business that we need to pay this technical debt. >> >> You mentioned that I'm blaming the wrong people, but I'm not blaming >> anyone here. I have 4 teams working with me to replace our entire legacy, >> one bite at a time, but I lead only 1 of those teams. The other 3 teams >> have not only decided that the technical debt needs to be paid, but also >> its not worth it to pay it with PHP and have move to Typescript. >> >> My points are: >> >> - development practices has changed and we know it, but it takes time to >> shutdown legacy >> - we are actively working towards paying that technical debt and PHP >> improvements are great to help with it, but the deprecations aren't always. >> - like it or not, there is a community unhappy with how hard it has >> become to maintain a PHP codebase. >> >> I believe there's a lot more leeway in breaking BC and fast evolving the >> language around projects that have started in 2018+ with automation tests >> from day one. Introducing a BC break on PHP 8.3 about something that was >> first released on PHP 7.4 is orders of magnitude easier to deal with than >> BC breaks on things first Introduced on or before PHP 5.6. If we could just >> have a way to opt-in to a faster-paced language for all new code while not >> breaking PHP 5.6 features until the previous generation of software can be >> retired, that would be awesome. >> >>> > I do have to ask: How any of that is the concern of PHP the language, PHP > the project? This is pure and simple is a company issue. Now they have to > pay for their decision by probably buying some 3rd party extended support. > I think that's a very honest and on-point question. Which is somewhat related to what I meant to mention here: https://externals.io/message/119834#119846 but got called out as "spreading BS" by Larry here: https://externals.io/message/119834#119868 I don't agree with Larry and I think you're dead right. PHP has a limited resource and maybe it has decided that the "legacy community" is not a priority and/or not worth the work. If that's the decision, I have nothing else to argue and I can accept it. -- Marco Deleu
Re: [PHP-DEV] Future stability of PHP?
On Mon, Apr 10, 2023, 4:01 PM Arvids Godjuks wrote: > > > On Mon, 10 Apr 2023 at 21:30, Deleu wrote: > >> On Mon, Apr 10, 2023, 1:17 PM Pierre Joye wrote: >> >> > hello, >> > >> > >> > On Sun, Apr 9, 2023, 1:37 AM Stephan Soller < >> stephan.sol...@helionweb.de> >> > wrote: >> > >> > > Hello, >> > > >> > > I'm sorry if this isn't the correct mailing list for that discussion >> but >> > I >> > > couldn't find a more appropriate one where people actually know how >> the >> > > wind is >> > > blowing. >> > > >> > > A few days ago I migrated a project from PHP 7.1 to 8.2 and the >> amount of >> > > deprecations and fatal errors spooked me a bit (details below if >> you're >> > > interested). That got me wondering about the long-term stability of >> PHP >> > > (as in >> > > language and API breaks) and I looked at the RFCs. I got the >> impression >> > > that >> > > static typing has a lot of traction now and I have no idea of what the >> > > fallout >> > > might be of changing a dynamically typed language into a statically >> > > typed one. >> > >> > >> > I keep reading this in multiple languages, pr even more frameworks. >> > >> > I understand agency work, managers pushing new features instead of a >> > cleaning some legacy. >> > >> > however years of ignoring deprecation notices (very few were introduced >> > right before 8.0). >> > >> > Most of them could have been fixed within a couple of hours in any code >> > base, if they had tests. >> > >> > I would suggest, very very nicely, to review and rethink the development >> > flows of these projects instead of asking php to freeze. >> > >> > best, >> > Pierre >> > >> >> I resent the sentiment of "if your code or development process was exactly >> like mine you wouldn't be here complaining" and I believe nobody is asking >> PHP to freeze. Not everyone has the ability to fix every deprecation >> within >> a couple of hours and not everyone has tests. Yes, we get it, it's common >> knowledge nowadays that code without test is unmanageable, but if you >> inherited a 15 year old codebase developed by multiple developers in a >> start-up mentality producing code faster than they could actually plan for >> and with no tests, its going to take some time to clean that up and if I >> take longer than you would, does it mean I matter less as a PHP user? >> >> PHP 8 is pretty great to work with and a lot better than previous >> versions, >> but there was no opt-in aspect to a lot of PHP breakages. All that we're >> asking here is for a bit more forgiveness to existing code that was >> developed 2 decades ago by a complete different generation and still need >> to run today while we clean it up. >> >> > >> > > Hello Deleu, I want to highlight your response specifically, because you > blame the wrong people here. > This is the failure of the business owner to plan accordingly and ignore > all the warnings for years and decades. That is if any developer raised any > concerns lately, which I also have seen quite a bit when "yes man" just > shove code into the meatgrinder for a year or two and then just move to the > next job: "It's not my problem, the next guy will deal with this". And that > feeds the vicious cycle, and the owner is either oblivious or does not > understand the implications because "well, it works, it generates money" at > the moment right until that plane hits the ground and things blow up. > I've handled a big legacy project, did major updates to it, seen how an > effort of 1 month of my time to drag it into the modern day paid off over > the next 6 months by picking up development speed by 3x with the same team > of 5 people + me. In 1 year we started to literally take away clients from > our competitors who could not keep up with us and we had a literal line of > clients to onboard, we had to scale our sales team 3x and had a backlog of > 6 months still. All stemmed from a single decision "I will tackle this, we > need it to update to newer PHP". Business owners were really stoked that > they actually listened to developers. > > You cannot expect to run code that was written 2 decades ago without major > updates on modern language versions. It's not possible for almost any > language that is being activ
Re: [PHP-DEV] Future stability of PHP?
On Mon, Apr 10, 2023, 2:26 PM Larry Garfield wrote: > > No. Stop. This is not what Ilija said at all. It is FUD to the point of > disinformation, and is an insult to the hundreds of people that have > worked, mostly on their own time, to give you the most popular web language > in the world, for free. > I understand that you have misread my message as some kind of insult. I can get 100% behind the "misinformation" aspect, so please inform me if you can. > > There's a large world out there that thinks PHP is still PHP 4. > > Most of them that I've met are not PHP developers. They're JS or Python > or Ruby devs who like to hate on PHP as a way to build their own community > cred. > Yes. And they're succeeding at luring the best PHP engineers I've met on my career out of PHP. > > now being forced by the language to stay behind or rewrite > > This is BS. I have worked on a 20+ year old code base. It's BS. Stop > spreading BS. > Perhaps you'd like to read the rules and guidelines of participating in the PHP Internals and would like a chance to reword this? I would be happy to disregard this message and read a new one where you present your message with more clarity. > Perhaps the risk analyses et al that Mark Baker talked about would be more > likely to happen if core devs weren't insulted on a regular basis by people > making hyperbolic lies and trashing their existing efforts. > > I've written about this before, just recently. Please read it twice > before posting again and insulting the work of those who have given you a > platform for your career, for free. > > https://peakd.com/hive-168588/@crell/upgrading-php-upgrades I'm sorry you feel that way. Whatever message you're trying to get across has not reached me, at least. But I also know whatever message I'm trying to get across will not reach you. In fact, this is precisely the type of toxicity that habits Internals during controversial discussions. While you have decided that I'm a ungrateful enemy that wants to trash talk about volunteers work, I'm actually here spending my time advocating for things that I believe could improve on PHP out of pure selfish reasons: I don't want to leave PHP and I don't want to be forced to take a NodeJS job, but the little bubble I live in that's becoming the only way forward. On Twitter you see a lot of folks advocating for more voices and participation on Internals even if you don't have a vote. But when we come here to participate this is how we're received?
Re: [PHP-DEV] Future stability of PHP?
On Mon, Apr 10, 2023, 1:17 PM Pierre Joye wrote: > hello, > > > On Sun, Apr 9, 2023, 1:37 AM Stephan Soller > wrote: > > > Hello, > > > > I'm sorry if this isn't the correct mailing list for that discussion but > I > > couldn't find a more appropriate one where people actually know how the > > wind is > > blowing. > > > > A few days ago I migrated a project from PHP 7.1 to 8.2 and the amount of > > deprecations and fatal errors spooked me a bit (details below if you're > > interested). That got me wondering about the long-term stability of PHP > > (as in > > language and API breaks) and I looked at the RFCs. I got the impression > > that > > static typing has a lot of traction now and I have no idea of what the > > fallout > > might be of changing a dynamically typed language into a statically > > typed one. > > > I keep reading this in multiple languages, pr even more frameworks. > > I understand agency work, managers pushing new features instead of a > cleaning some legacy. > > however years of ignoring deprecation notices (very few were introduced > right before 8.0). > > Most of them could have been fixed within a couple of hours in any code > base, if they had tests. > > I would suggest, very very nicely, to review and rethink the development > flows of these projects instead of asking php to freeze. > > best, > Pierre > I resent the sentiment of "if your code or development process was exactly like mine you wouldn't be here complaining" and I believe nobody is asking PHP to freeze. Not everyone has the ability to fix every deprecation within a couple of hours and not everyone has tests. Yes, we get it, it's common knowledge nowadays that code without test is unmanageable, but if you inherited a 15 year old codebase developed by multiple developers in a start-up mentality producing code faster than they could actually plan for and with no tests, its going to take some time to clean that up and if I take longer than you would, does it mean I matter less as a PHP user? PHP 8 is pretty great to work with and a lot better than previous versions, but there was no opt-in aspect to a lot of PHP breakages. All that we're asking here is for a bit more forgiveness to existing code that was developed 2 decades ago by a complete different generation and still need to run today while we clean it up. >
Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading
On Mon, Apr 10, 2023 at 10:01 AM Ondřej Mirtes wrote: > I don’t like the proposed function names: > > autoload_register_class to me reads like “register this class for > autoloading”. If I observe the intended meaning correctly, it should be > called “register_class_autoloader”. > > Same for autoload_register_function - better name would be > “register_function_autoloader”. > > Other functions should be renamed accordingly. Function names should read > like a sentence, like a command. > > On Mon 10. 4. 2023 at 14:17, G. P. B. wrote: > > > Hello Internals, > > > > Dan and I would like to propose a new core autoloading mechanism that > fixes > > some minor design issues with the current class autoloading mechanism and > > introduce a brand-new function autoloading mechanism: > > https://wiki.php.net/rfc/core-autoloading > > > > The existing SPL autoloading functions would become aliases to the new > Core > > ones and will continue to work without any migrations needing to be > > performed. > > > > Hope to hear your opinions about this! > > > > Best regards, > > > > George P. Banyard > > > -- > > Ondřej Mirtes > I'm guessing autoload_* was chosen because PHP internal functions are bundled by prefix and register_* would not make a good bundle name for the autoloading functionality. What helps me when thinking about PHP internals function is to assume the first word is a class, such as: $autoload = new Autoload(); And then everything after the first underscore is a method name, such as $autoload->register_class();. What I can recommend in this case is to make them autoload_register_class_loader() and autload_unregister_class_loader(), but prefixing everything with register_* would be essentially $register = new Register();, but register what? -- Marco Deleu
Re: [PHP-DEV] Future stability of PHP?
On Sat, Apr 8, 2023, 6:04 PM Ilija Tovilo wrote: > > Sadly, there's a conflict of interest here. There are people who want > to keep running their existing websites without having to make any > changes, and there are people who are using PHP daily and would like > to see the language evolve. We would like to satisfy both of these > groups but that is difficult when they are often directly opposed. I > do think that if we only manage to satisfy the former, PHP will > gradually become less and less significant. That would be sad. > > Ilija That makes total sense to me. On the other hand, throwing the existing community out and chasing after a new community puts PHP at a very delicate spot. There's a large world out there that thinks PHP is still PHP 4. Of the large group of PHP adopters that stayed with the language for the last decade, a large set seem to have their interests neglected and are being forced into greenfield/rewrite. If you've bet money on PHP 15 years ago and you're now being forced by the language to stay behind or rewrite, what are the odds that PHP will keep being the betting choice?
Re: [PHP-DEV] Future stability of PHP?
On Sun, Apr 9, 2023, 7:10 PM Kamil Tekiela wrote: > > I'd rather say that the roadblocks people are facing in upgrading legacy > projects are not specific to PHP 8, but rather a technical debt acquired > over the past 10-15 years. Even if nothing would change in PHP 8, people > would still complain about the upgrade because of unrelated reasons. > > > Regards, > Kamil > I'm sorry for the double-answer but this snippet striked me a lot. I'm quite curious to read a follow up on what you mean by unrelated reasons here. Suppose a parallel universe that code written in PHP 5.6 runs without any changes in PHP 8.2. What unrelated changes would people have to not upgrade? If the code runs exactly the same, there's no warnings converted into exceptions that change code execution, no deprecations, no behavior changes, what is it that people would complain about? Or maybe when you wrote "Even if nothing would change in PHP 8" you meant something different than what I interpreted? >
Re: [PHP-DEV] Future stability of PHP?
On Sun, Apr 9, 2023 at 7:10 PM Kamil Tekiela wrote: > > But the cost is catastrophic. If you have a legacy codebase hanging over > your head you probably know how hard it is to upgrade it. > > I wonder about this every time I hear this claim. What exactly changed in > PHP 8.0 that made the upgrade path so difficult? The upgrade to PHP 9 may > be a little more difficult because of some of the recent deprecations, but > that's still years ahead of us. So what's exactly driving people away from > PHP 8? Why is the adoption dwindling? > > I'd rather say that the roadblocks people are facing in upgrading legacy > projects are not specific to PHP 8, but rather a technical debt acquired > over the past 10-15 years. Even if nothing would change in PHP 8, people > would still complain about the upgrade because of unrelated reasons. But > please prove me wrong. Is there actually any change in PHP 8.0 that is a > major source of work? > > If PHP went in the wrong direction, let's suggest something to fix it. If > there are no suggestions for improvement then what are people complaining > about? > > > Regards, > Kamil > Here are the top-of-my-head most relevant stuff I've read over the years on the matter. https://yoast.com/developer-blog/the-2020-wordpress-and-php-8-compatibility-report/ https://markbakeruk.net/2022/05/22/php-8-2-the-release-of-deprecations/ https://24daysindecember.net/2022/12/06/evolving-php/ https://24daysindecember.net/2022/12/19/maintenance-art/ https://mobile.twitter.com/jrf_nl/status/1459221549429542920 https://24daysindecember.net/2020/12/21/a-perfect-storm/ https://mobile.twitter.com/jrf_nl/status/1558589727766417411 Unfortunately I couldn't find where, but I remember reading that PHP 7.2 deprecation of non-countable types was one of the biggest "busywork" generator of the PHP 7 series. It made an extremely large impact at public and private projects across the world for something with questionable benefits. https://www.php.net/manual/en/migration72.incompatible.php#migration72.incompatible.warn-on-non-countable-types Over the course of PHP 7 and 8, there were significant concerns on how problematic PHP deprecations and breaking changes were. Now we're starting to see the result of such concerns being ignored. This isn't the first time someone mentions on PHP internals that it's getting harder and harder to stay with PHP, but it's never really received with an open mind. It's either "you don't have to run deprecation-free code" or "you've had years to get rid of that deprecation error, tough luck if you didn't". I love PHP and I built my career around it. I have zero interest in starting from scratch in another language, but I've lost count on how many projects, friends and companies around me have already made the switch to Typescript. It's getting harder and harder to argue in favour of staying with PHP. -- Marco Deleu
Re: [PHP-DEV] Future stability of PHP?
On Sat, Apr 8, 2023, 5:47 PM Dan Liebner wrote: > I agree with the OP's sentiment here. If I was starting a codebase from > scratch today, I'd probably go with Node. I find that writing modern > JavaScript is way easier than writing PHP these days, and the breaking > changes in newer PHP versions make writing code harder rather than easier. > PHP is the foundation for many legacy codebases, and breaking old projects > isn't really a great selling point of new PHP versions. > > Hopefully this scenario will affect enough people that 7.4 will continue to > be maintained by some group of people into the foreseeable future. > > Best, > Dan > Can't disagree with this statement. I love PHP. I have been working with it for 13 years now. I can also make things work with PHP 8+ and I get what it brings. But the cost is catastrophic. If you have a legacy codebase hanging over your head you probably know how hard it is to upgrade it. If you have greenfield project with SA and 100% coverage, it's a peach. But what's the point of starting a greenfield project in PHP while Typescript is right there? The cost of PHP maintenance and it's bad reputation certainly makes it a language only for those that got hooked into it a decade ago and not something that makes sense to recommend for newcomers. With each deprecation, PHP pushes out more devs and companies into a different path. >
Re: [PHP-DEV] RFC Idea - json_validate() validate schema
On Wed, Mar 1, 2023, 12:02 PM Michał Marcin Brzuchalski < michal.brzuchal...@gmail.com> wrote: > Hi Deleu, > > śr., 1 mar 2023 o 16:54 Deleu napisał(a): > >> >> >> On Wed, Mar 1, 2023 at 9:36 AM Michał Marcin Brzuchalski < >> michal.brzuchal...@gmail.com> wrote: >> >>> >>> Do we really need this in core? What makes it less usable as an >>> extension? >>> >>> Cheers, >>> Michał Marcin Brzuchalski >>> >>> > >>> >> >> Extensions are not easy to install and have a complex distribution system >> that differs greatly between Windows, Debian, Ubuntu, Alpine Linux, AWS >> Lambda, etc. I wish one day we could have something as simple and >> ubiquitous as Composer installing PHP extensions, but until then the less >> amount of extensions the better for end users. >> > > I agree with your last thought. The fewer extensions the better for end > users but what I have a problem with is constantly adding functions to the > standard library instead of writing a library that fulfills the need. > Along with extensions the fewer functions/classes are bundled the better > for end users. > > Cheers, > Michał Marcin Brzuchalski > If we're being practical here, json_validate has been proposed and accepted already, so the discussion is not whether to add a new function or not, but instead whether to improve it to also validate schema. So the concern doesn't seem relevant. But for the sake of argument, the addition of it has no negative impact on me while with extensions there are, so it's no-brainer for me. >
Re: [PHP-DEV] RFC Idea - json_validate() validate schema
On Wed, Mar 1, 2023 at 9:36 AM Michał Marcin Brzuchalski < michal.brzuchal...@gmail.com> wrote: > > Do we really need this in core? What makes it less usable as an extension? > > Cheers, > Michał Marcin Brzuchalski > > > > Extensions are not easy to install and have a complex distribution system that differs greatly between Windows, Debian, Ubuntu, Alpine Linux, AWS Lambda, etc. I wish one day we could have something as simple and ubiquitous as Composer installing PHP extensions, but until then the less amount of extensions the better for end users. -- Marco Deleu
Re: [PHP-DEV] RFC: code optimizations
On Wed, Mar 1, 2023 at 8:15 AM Max Kellermann wrote: > On 2023/03/01 06:37, Max Kellermann wrote: > > Indeed it appears Dmitry is right - code refactoring is generally NOT > > allowed (unless there is an explicit RFC vote, and I havn't seen one). > > IMO this is a bug in the process, and I'm trying to fix it. It should > be allowed to merge small incremental improvements without a dedicated > RFC. > > This is the first draft of my RFC: > https://wiki.php.net/rfc/code_optimizations > > Let's discuss. > > Max > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > I'm not a voter, but my two cents anyway, as that's the point of internals. Seems like there could be a historical reason this is the way it is. The RFC process involves proposing changes to the PHP language that has an impact on: - Core Developers - Extension Developers - Documentation - Release Managers - Libraries and Frameworks - Users of PHP - Server Admins (potentially) As such, the RFC process exists to provide the possibility of involvement of a larger community. Changes to existing code in the way that is described on this RFC has a direct impact on Core Developers and maybe Extension Developers and nobody else. I'm guessing the RFC process has never been used for it before because it mainly involves the folks developing the language itself and has no direct impact on everyone else. If Core Developers can agree, review and approve each other's code change, no RFC has ever been necessary. The problem now is that there's a dispute between core developers and there doesn't seem to be a way to resolve such dispute. The downside of this RFC is that it opens up the discussion of how to write internal code for PHP to a larger community that has no strong involvement in it with more potential to harm than improvements. All in all, Dmitry, Max and other core developers could try to find common ground, understand each other and see past the issue at hand. The language could always benefit from having more core contributors instead of less, so perhaps there's something that can be done so Max can feel more welcome. In contrast, a decade's worth of internal contributions from Dmitry shouldn't be dismissed and Max could try to better understand where Dmitry is coming from. I think a lot of senior developers can sympathise when new developers full of energy join the team and want to make drastic changes everywhere. It can feel like a golden retriever making a mess. But a fresh perspective and a diverse mindset can often find new solutions and improve the project in the long-term. Krakjoe and The PHP Foundation is trying to reduce the bus factor of PHP and Max is one way of achieving that. In conclusion, I don't think this RFC should move forward but if it does, it would be important for every voter to think whether this has a direct impact on their contribution to PHP or if it should be something left for folks that have skin in the game to decide. One last thing: if Max's change can be beneficial to the project, but are causing other issues such as merge conflicts or breaking stuff, send these stuff to him and ask him to see for himself the consequences of his changes. Maybe he can decide for himself that reverting is the best approach or maybe he can use his energy to fix even deeper issues. -- Marco Deleu
Re: [PHP-DEV] Class Re-implementation Mechanism
On Tue, Feb 21, 2023, 8:52 AM someniatko wrote:
> Hi again, internals
>
> My marathon of some crazy ideas continues :D, with less crazy one this
> time.
>
>
> ## Idea
>
> Allow "reimplementing" the non-static public API (that is public
> properties and methods, excluding constructor) of a class by other
> classes like this:
>
> ```php
> final class interface A {
> public string $s;
>
> public function __construct(string $s) { $this->s = $s; }
>
> public static function fromInt(int $i): self { return new
> self((string) $i); }
>
> public function foo(): int { return 42; }
> }
>
> final class B implements A {
> public string $s = 'hello';
>
> public function foo(): int { return 69; }
> }
>
> function usesA(A $param): void {}
>
> usesA(new B); // this works
> ```
>
>
> ## Explanation
>
> Consider there is a class like this:
>
> ```php
> final class Service {
> public function __construct(private SomeDependency $dependency) {}
> // ...
> }
>
> final class SomeDependency {
> // ...
> }
> ```
>
> We want to write some tests for the Service class, but we don't want
> to use a real SomeDependency instance
> during tests. A common approach is to either extract an interface
> (JUST to make it testable), or to drop the
> `final` keyword and allow extending the class.
>
> Both approaches have their flaws:
> - extracting an interface unnecessarily complicates the system, where
> only one "real" implementation of an interface is assumed.
> - dropping the `final` keyword allows for the rabbit-hole of
> inheritance abuse, like greatly described in this article:
> https://front-line-php.com/object-oriented
>
> I believe I came up with a better idea: what if we could leave both
> benefits of prohibiting the inheritance abuse and also allow not to
> clutter our namespace with excess entities like interfaces? I hereby
> suggest to combine the responsibilities of a class and an interface
> into one thing like that:
>
> ```php
> final class interface C {}
> final class D implements C {}
> ```
>
> Now other classes can "implement" this class as well. Introduction of
> the new syntax (`class interface`) also solves BC problem - if you
> want to forbid your classes to be reimplemented whatsoever, you can
> still stick to the `final class` syntax. Although it is also possible
> to allow "reimplementing" ANY class, then new syntax is not needed -
> but some library writers like Marco Pivetta could be sad about that I
> suppose.
>
> Soo..., what do you think? Could this be a valuable addition to the
> language?
>
> Regards,
> Illia / someniatko
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
Although I undeterstand and agree with the annoyance of both limitations
presented, I think one important factor that makes this an issue lies with
PSR-4 and autoloading. If you could declare the interface and the
implementation in the same file, as you do with Typescript, the drawback of
extracting an interface for testing would be greatly diminished.
Unfortunately undoing PSR-4 shortcomings and getting something baked into
Composer or PHP to address this seems fairly challenging.
Re: [PHP-DEV] Re: Official Preprocessor
On Thu, Feb 2, 2023, 11:22 AM someniatko wrote: > I'd like to also emphasize that the concept of compilation and static > type-checking / analysis is not foreign to the PHP community. Major > frameworks like Symfony already have a concept of compiling e.g. a DI > container, and static analyzers like Psalm, PHPStan and others are > actively used. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php I think the idea overall is pretty solid and could get a few community supporters. But the devil is in the details. 1. Making it official is a trade-off. It's the highest chance of widespread adoption and the heaviest burden on PHP Internals. 2. Who's going to fund it, develop it, maintain it? It's a significant project and a heavy burden. 3. What's the MVP? How do we measure usefulness, adoption and maintenance complexity? 4. Is it an aborttable idea? If things go south and can't be supported anymore, how bad for PHP adopters would it be? 5. How would voting on the spec be like? Complete years-work-hours spec or small incremental functionalities? 6. Is versioning tightly coupled with PHP version or does it have its own version support system targeting multiple php versions at the same time? Overall, I think PHP has been constantly losing popularity in favor of Typescript and a transpiler could create an exciting solution for some of PHP's problems, but it does not seem like a pet project.
Re: [PHP-DEV] [RFC] [Vote] Readonly amendments
> > > > Mocking > > > > This isn't a terribly compelling argument. Readonly classes are typically > value objects; it's rare that you will mock them as they will be used as > messages or results, and you'll end up doing assertions against them — not > mocking them. > > Anything else it would enable? If like me you have a lot of service-style classes with recursive autowired DI, making them all readonly is a no-brainer and mocking some of them sometimes make sense. I have no opinion in favor or against, but wanted to point out that to me value objects are less likely to be readonly than service classes, where mocking are common.
Re: [PHP-DEV] Introduce the abiltiy to use the first-call-callable syntax on non-static methods, statically
On Mon, Jan 23, 2023, 1:16 PM Ollie Read wrote: > Oh, I didn't mean to suggest that it automatically binds. > > My second suggestion for how to achieve this does require some sort of > automation. If you create a closure from Str::someMethod($arg1, $arg2) > where someMethod isn't static, it should create a closure with the > signature fn(Str $object, $arg1, $arg2), which would wrap a call to > [$object, 'someMethod]($arg1, $arg2). I think this starts to wonders in the realm of Partial Function Application https://wiki.php.net/rfc/partial_function_application
Re: [PHP-DEV] Re: [RFC][Vote] Asymmetric Visibility
> > > The vote has now closed. > > The final result is 14 Yes, 12 No, which is less than the required 66%. > The RFC is declined. > Highly interesting to see that there's a theoretical path with a different syntax that takes 4 voters to yes and change the outcome to 18/26, which would have been an approved RFC. Working with readonly nowadays I can kinda see how a-viz would be nice, but if I had a vote I'm also in the camp that didn't like the syntax. >
Re: [PHP-DEV] [RFC] Unicode Text Processing
On Thu, Dec 15, 2022, 3:16 PM Tim Düsterhus wrote: > > [1] The 'Text' class should likely be made final, because folks might > otherwise rely on a specific userland extension, preventing actual > interoperability. > I'm fond of final classes but in here I think it *adds* burden to core developers. As you said it yourself having a Type within PHP will help interoperability. Having this type be final will hurt interoperability because everyone's wrapper will be different. This may lead to the community requesting more changes to core. >
Re: [PHP-DEV] [RFC] Unicode Text Processing
On Thu, Dec 15, 2022 at 12:34 PM Derick Rethans wrote: > Hi, > > I have just published an initial draft of the "Unicode Text Processing" > RFC, a proposal to have performant unicode text processing always > available to PHP users, by introducing a new "Text" class. > > You can find it at: > https://wiki.php.net/rfc/unicode_text_processing > > I'm looking forwards to hearing your opinions, additions, and > suggestions — the RFC specifically asks for these in places. > > cheers, > Derick > I appreciate the work behind this RFC. Although I can't comment much on the utility itself as I never really used `ext-intl` or much of UTF-8/16 stuff, I think PHP lacks A LOT of built-in classes to make matters simpler and welcoming. Sure, anybody in userland could write a class, but that leads to lots of implementations and an overwhelming amount of choices to be made. If this class can cover 80% of the use-case, folks can extend it to build their remaining 20% advanced use-case and PHP becomes easier. I really look forward to more basic utility-classes built-in and ready to go. -- Marco Deleu
Re: [PHP-DEV] Revisiting RFC: Engine Warnings -- Undefined array index
> > Anyone surprised by any of the changes in recent versions that boil down > to "know your types and know if you actually have a variable" has been > living under a rock for the last 20 years. None of this has been a > secret. The language has been providing more and more tools to > know-your-types for years. > I have seen this type of comment here many times and I don't understand why it keeps being repeated. The world is made up of many rocks and we're all living under one of them. This whole thread is nothing but my-rock-is-the-only-rock-everyone-else-should-live-under type of comments. > And yes, I used to work on a system that didn't do that properly. (TYPO3, > ~800,000 LOC) It took me a few weeks, but we still managed to fix all of > these issues in mostly one-person-month, mostly with dropping "?? null" > around in various places. It's not the world-destroyer people make it out > to be. > Do you honestly think that everyone with a small/medium PHP project (500k~1M LOC) out there has someone as competent as you capable of achieving what you did? That is definitely a dream rock to live under. -- Marco Deleu
Re: [PHP-DEV] PHP support for matrix operations - BLAS, LAPACK.
On Sun, Dec 4, 2022, 8:43 PM j adams wrote: > I apologize if I have the wrong mailing list here. I'm hoping ot ask the > PHP developer community if there's any appetite for functions to handle > matrix operations and scientific computing. > > I took a course on machine learning which had us code solutions using > matlab/octave. This year I embarked on trying to translate those functions > to PHP and have been quite surprised to learn that pure php is quite > inefficient for matrix multiplication. I've been trying to chase down an > effective way to perform matrix operations in PHP and posting my questions > and progress on this forum at PHPBuilder: > > https://board.phpbuilder.com/d/10403480-converting-matlab-machine-learning-routines-to-php-need-matrix-operations > > Fast matrix operations seem to be absolutely critical for machine learning, > at least for Support Vector Machines and Neural Networks. I know that there > is a FANN extension, but it seems to me that it would be beneficial for > PHP's use in scientific applications if it had support -- either natively > or via some extension -- for matrix operations and possibly other > statistical or scientific computations. Python has numpy, for example. > > How does everyone feel about BLAS or LAPACK extension for PHP? I'm poorly > equipped to cook up such a thing, but these libraries already exist and > could offer great improvements in performance. > I remember studying some ML algorithms back in 2015 and I felt PHP was lacking a lot in terms of matrix operations, specially invert a matrix. It would have been cool to have some fundamental functionalities baked in. >
Re: [PHP-DEV] [RFC] [Discussion] Readonly class amendments
After reading GPB, Nicolas, Jordan and Larry's considerations, I no longer have any objections to this RFC. Here is my summary of it all: - It's very easy for everyone to wrongly interpret readonly as somewhat immutable, but it isn't (docs/education issue) - LSP is about the writer of the child class, not about PHP - If you don't want child classes to violate LSP, make your class `final readonly` - readonly as "constructor-init" properties mindset make it even stronger the argument that child classes should be free to choose their definition because constructors are special methods not bound by inheritance. Overall the most important aspect for me was that there was a pragmatic decision of supporting readonly properties as it covers most of the need without the whole hustle/complexity of asymmetric visibility and it was very good for Nicolas to bring up again that pragmatic notion. This doesn't have to be complex and limiting child classes makes it more complex. In the future, the education around readonly keyword will be that it has no bearings anywhere except the class that makes use of the keyword. -- Marco Deleu
Re: [PHP-DEV] [RFC] [Discussion] Readonly class amendments
On Thu, Nov 17, 2022 at 11:47 AM Marco Pivetta wrote:
> ```php
>
> /* readonly */ class ImmutableCounter {
> public function __construct(private readonly int $count) {}
> public function add1(): self { return new self($this->count + 1); }
> public function value(): int { return $this->count; }
> }
>
> // assuming the proposed RFC is in place, this is now possible:
> class MutableCounter extends ImmutableCounter {
> public function __construct(private int $count) {}
> public function add1(): self { return new self(++$this->count); }
> public function value(): int { return $this->count; }
> }
>
> $counter1 = new ImmutableCounter(0);
> $counter2 = $counter1->add1();
> $counter3 = $counter2->add1();
>
> var_dump([$counter1->value(), $counter2->value(), $counter3->value()]);
>
> $mutableCounter1 = new MutableCounter(0);
> $mutableCounter2 = $mutableCounter1->add1();
> $mutableCounter3 = $mutableCounter2->add1();
>
> var_dump([$mutableCounter1->value(), $mutableCounter2->value(),
> $mutableCounter3->value()]);
> ```
>
> ( https://3v4l.org/IDhRY )
>
> That's really really confusing, buggy, and, from a consumer PoV, broken
> (LSP violation too, transitively).
>
As I think more about this, there's nothing about the current RFC in this
code sample. What's breaking LSP here is the child class doing state
modification, not PHP. To further expand that rationale, PHP allows us to
create child classes. Whether that class will be LSP-safe or not is up to
us, not up to PHP.
However, the point still stands. Allowing child classes to break readonly
will make it easier to build code that breaks LSP. The question then
becomes: why is this being proposed and is it worth it?
As I read through the RFC, the only reason this is being proposed is
because "it breaks decoration via inheritance". Doesn't `final` cause the
same issue? How is this problem being handled if the class is marked as
final? If you can't extend a final class to build your "decoration via
inheritance", why can't the same argument be applied to readonly classes?
--
Marco Deleu
Re: [PHP-DEV] [RFC] [Discussion] Readonly class amendments
On Sat, Nov 26, 2022, 4:45 PM Máté Kocsis wrote: > We proposed this change because it wouldn't break anything that's already > not "broken". > > Regards: > Máté > The example provided already raised some eyebrows from people. I think the argument of "let's furthet enhance this 'broken' behavior" isn't that great. I find the ability of child class to ignore the parent readonly definition awkward at best. >
Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly
On Sun, Nov 13, 2022 at 5:09 PM Larry Garfield wrote: > Hi folks. Ilija is nearly done with the implementation for asymmetric > visibility and flushing out edge cases, but we've run into one design > question we'd like feedback on. > > There's two design decisions we've made at this point, both of which we > think are logical and reasonable: > > 1. If specified, the set visibility must be tighter than the get > visibility. So `protected protected(set)` and `protected public(set)` are > not permitted, for instance. > > 2. `readonly` is a "write once" flag that may be combined with asymmetric > visibility. If no set visibility is specified, `readoly` implies > `private(set)`, but a different set visibility may also be provided. > These are both reasonable rules. However, it creates a conflict. > Specifically, in the following cases: > To unsubscribe, visit: https://www.php.net/unsub.php > > The more I think about this, the more it makes more sense (to me) to simplify it even further; 1) The set visibility should be the same as the get visibility when one is not provided. That is: ``` public $var -> public public(set) $var protected $var -> protected protected(set) $var private $var -> private private(set) $var ``` The explicit declaration of same visibility can be disallowed e.g. `public public(set) $var` is not allowed, you must use `public $var` if you want visibility symmetry. However, if it simplifies implementation to allow it, why not? The behavior would already be in place anyway. 2) The readonly flag should no longer have an impact on the set visibility. This is again a conceptual breaking change, but one that can even be fixed with a SEARCH/REPLACE on a project scope. The "breaking change" is categorized as follows: The code `public readonly $var` used to be `public private(set) readonly $var` should become `public public(set) readonly $var` The code `protected readonly $var` used to be `protected private(set) readonly $var` should become `protected protected(set) readonly $var` The code `private readonly $var` should not have any change. -- Marco Deleu
Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly
> > > This is untrue. You can declare a private property identically in a > parent and child class, even readonly. I'm doing this now in a project. > It works, but would be unnecessary if the parent's property were > protected(set). > > --Larry Garfield > I do understand the slight complexity here (perhaps stronger in terms of implementation), but my assumption was that if a property is private and "the set visibility must be tighter", PHP would never assume `private protected(set) readonly`. In other words, if `private readonly` then `private private(set) readonly`, therefore nothing changes. You can keep the use of disjointed variables in inheritance provided they're all private. The only concern is when a property is declared protected, which then evaluates to what I mentioned on the previous email. I'm also under the stated assumption that `public public(set) readonly` is not something needed to be supported. -- Marco Deleu
Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly
> > > 2. `readonly` is a "write once" flag that may be combined with asymmetric > visibility. If no set visibility is specified, `readoly` implies > `private(set)`, but a different set visibility may also be provided. > > These are both reasonable rules. However, it creates a conflict. > Specifically, in the following cases: > > public public(set) readonly string $foo > > protected protected(set) readonly string $foo > What if the implicit rule for `readonly` is changed into `protected(set)`? Let's run with this for a minute. 1- It's not truly a CODE breaking change. Right now if you have a `protected readonly` property, you're either calling the parent constructor or you're never making use of the variable, otherwise you're getting a Fatal Error. 2- It's a CONCEPTUAL breaking change. If you've declared a `protected readonly` property, you may expect anyone in the inheritance chain to be calling your constructor. A new PHP version will warn you to either change your property into `protected private(set) readonly` (Rector might be able to do this) or accept the new behavior. 3- The two logical design choices can be kept. To be honest, I think asymmetric visibility seems way over complex for very little benefit, so I'm a bit against the entire feature, but if we were to have them, it would really be nicer to not have crazy shenanigans involved. -- Marco Deleu
Re: [PHP-DEV] Experimental features
On Wed, Oct 5, 2022, 7:54 AM juan carlos morales wrote: > > Apply a PECL strategy to try experimental features might not be the > convenient way always, for example, if we create a new ... sensitive > ... ini setting that affects the behavior of PHP somehow, then ... > maybe applying the PECL strategy might not be the most confortable way > to approach it, OR ... what about a new sensitive funtion in a "core > extension" like JSON? > Just to build up on this. I feel like Extensions are maybe a technical / development feature that may have the power to address the issue, but from a "Product" (PHP language as the product) this isn't the best. Anything behind extensions add a significant entry burden and reduce the reach for users of the product, be it for lack of trust, knowledge or lack of infrastructure that allows such changes. >
Re: [PHP-DEV] Error behaviour for max_input_vars
On Tue, Sep 13, 2022, 7:58 PM Mel Dafert wrote: > The options I see feasible are: > - A new ini setting `max_input_vars_abort` (default to 0), which, if set > to 1, will abort the request if there are more input variables than > allowed. > - A method to reliably detect whether the input vars were truncated (eg. > `function has_post_been_truncated(): bool`), so the application can > decide whether to abort or not. > - Deciding that `max_input_vars` is not relevant anymore and should be > handled by the likes of Apache and NGINX, thus changing the default to > `0` and removing the setting > over a deprecation period. Creating more ini settings is not very exciting. I do really like option 2 though.
Re: [PHP-DEV] RFC json_validate() - status: Under Discussion
On Mon, Aug 29, 2022 at 10:50 AM juan carlos morales < dev.juan.mora...@gmail.com> wrote: > There is still 1 open question on the RFC, and is about the return value. > > https://wiki.php.net/rfc/json_validate#open_issuesquestions > > I would appreciate your feedback on this. Even though I was told the > RFC can go with 2 votings, I would like to know your thoughts about > that open question, in short, the return value. > Has the option of returning a Result object been discussed/considered? Can it be an option? I imagine that if `json_validate(): JsonValidationResult` always returns a `JsonValidationResult` which contains a `public readonly bool $valid` and a `public readonly ?string $error` it would be better than both options on the table right now. The option of returning CLI-like results means that we will need a `if (! json_validate())` to treat a valid JSON (really awkward) and the option of using `json_last_error()` relies on an internal state instead of an immutable structure. Effectively, what we need is to return a complex structure which can contain a boolean and a string and that is a class/object. Thoughts? -- Marco Deleu
Re: [PHP-DEV] RFC json_validate() - status: Under Discussion
On Thu, Aug 25, 2022, 9:12 PM David Gebler wrote: > > I agree that the number of userland implementations for a "is_valid_json" > type function including in some widely used frameworks and systems > indicates there's some degree of demand in the ecosystem for validating a > JSON string. > I don't have an option about the rest of your email, but I wanted to point out that the vast userland need for validating JSON right now is being "hacked" for lack of a better functionality. Whether it's justifiable to bring this to core is up for debate, but I at least take it as a valid point that "asking a computer to do a task just to check whether it failed" is odd and limiting to say the least >
Re: [PHP-DEV] Re: [Concept] Extension methods
On Wed, Aug 10, 2022, 11:30 PM Rowan Tommins wrote: > > To be honest, I put them in that order more for "purity" reasons: if they > come before __call, they can change the existing behaviour of the class, by > defining an extension method with the same name as a "virtual" method > implemented with __call. That then becomes a very different feature. > I would argue in favor of extension having precedence over __call because 1) classes with __call wouldn't be able to be `extended` and 2) extensions could actually "fix" the ~ab~use of some use of __call. I suppose this would allow me to write an Extension that mimics the exact behavior of __call and actually avoid __call from being hit while still keeping the same behavior of the class.
Re: [PHP-DEV] [Concept] Extension methods
On Wed, Aug 10, 2022 at 5:16 PM Levi Morrison via internals <
internals@lists.php.net> wrote:
> > What are your thoughts?
>
> It's a fantastic feature that I've used in Rust, although there are
> some differences. First, it doesn't work for regular methods -- they
> have to be part of a trait. Secondly, in general a trait can only be
> implemented for a given type if it is in the package which defines
> that type, or in the package which defines the trait. Third, the trait
> must be in scope. These rules help people understand where the methods
> are coming from, which is particularly helpful for large code bases or
> teams.
>
> PHP doesn't really have tools for these kinds of restrictions, but I
> think it's necessary. You'd need some way to manage where extension
> methods are loaded, how they are found, and without pessimizing
> performance of method calls in general just because this feature
> exists.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
As I was thinking about how this feature would be cool, I was also worried
about how big of a mess it could become, given the lack of restrictions you
pointed out here. However, knowing how PHP works, I wonder if the following
could be made possible:
```
// Vendor File
namespace Illuminate\Support;
class Collection {}
// Extension File
namespace App\Whatever;
extension LaravelCollection on Collection {}
// Usage File
namespace App\Business;
use App\Whatever\Laravelcollection;
$collection = (new Collection())->extensionMethodAvailableHere();
```
The goal here is to
1- Disallow `use Class; use ExtensionClass` simultaneously (conflicting
symbols on compile-time?)
2- Bind the Base-class Symbol through the ExtensionClass symbol
3- Disallow two extensions to compete with each other
4- The user would always know that a symbol has a method either via 1-level
extension or from the original class directly - it doesn't come from
unknown places
I feel like this would be powerful enough to solve a lot of usability on
PHP OOP while not being crazy enough to create a nightmare on codebases and
the internals of the PHP Engine. Does this make sense?
--
Marco Deleu
Re: [PHP-DEV] [RFC] Asymmetric visibility
On Fri, Aug 5, 2022 at 7:09 PM Larry Garfield wrote: > Ilija Tovilo and I are happy to present the first new RFC for PHP 8.3: > Asymmetric Visibility. > > https://wiki.php.net/rfc/asymmetric-visibility > > Details are in the RFC, but it's largely a copy of Swift's support for the > same. > > -- > Larry Garfield > la...@garfieldtech.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > Just wanted to point out that I loved syntax proposals by Juliette and Mike. Any of them would be better. Making a better syntax for PHP would be better than consistency with Swift, IMO. But I'm also inclined to agree with Marco Pivetta that this change is a lot less exciting now that we have `readonly`. In extremely rare cases where I need to modify an attribute more than once, I just fallback to private + getter and the nice thing about it is that it creates a consistent mindset that if a property is being accessed via a getter, then the reader should be advised that the property may change depending on WHEN it's accessed. -- Marco Deleu
Re: [PHP-DEV] RFC Idea - is_json - looking for feedback
On Sat, Jul 30, 2022, 4:48 PM David Gebler wrote: > > > What I'm asking is what's the practical use for this proposed function? > Where are you likely to need to know if a string is valid JSON but not have > to (try to, with error handling) parse it almost immediately afterwards > anyway? > I'm still on the fence over the general idea, but I thought I could at least address this question in particular. I can definitely see it's usefulness on public HTTP API ingesting data (specially large data) where if the payload is a valid JSON, it gets stored and processed by a background queue, making it so that the HTTP layer can either reject the request with a 4xx status or accept it and only truly decode it on a separate process that may even be hosted by a separate server with larger memory size. >
Re: [PHP-DEV] Discussion about new Curl URL API and ext/curl improvements
On Thu, Jun 16, 2022, 9:10 AM Pierrick Charron wrote:
> Hi internals,
>
> Since its version 6.62.0 [1], libcurl features a brand new URL API [2] that
> can be used to parse and generate URLs, using libcurl’s own parser. One of
> the goals of this API is to tighten a problematic vulnerable area for
> applications where the URL parser library would believe one thing and
> libcurl another. This could and has sometimes led to security problems [3].
> The new API is handled base and composed of 5 new functions [4] (and one
> more since 7.80.0 to get more verbose information upon error).
>
> I started to work on an implementation [5] to expose this API to PHP
> userland in the curl extension so that PHP users can benefit from it. My
> first reflex was to stay consistent on how the extension is currently
> working and do a one to one mapping of the new curl functions. I got
> feedback from both Ilija and Christoph saying that the API is, I quote, "a
> bit clunky" which I can't disagree with.
>
> For a long time, ext/curl worked with handles as "curl resources" and
> functions mapped to the libcurl functions, but since PHP8.0 "curl
> resources" were converted to opaque classes with no methods. So my main
> goal here is to come up with a solution for the new Curl URL API, but maybe
> also to be consistent, make some changes to existing curl classes like
> `CurlHandle` to add methods and improve the current state of the extension.
>
> Here is the solution I would propose :
> - First of course keep all the current ext/curl functions as is not to
> break any compatibility (Seems obvious but just to be sure everybody is on
> the same page).
> - For consistency expose the new Curl URL API as functions mapped one to
> one to libcurl functions :
>
> function curl_url(?string $url = null): CurlUrl|false {}
> function curl_url_set(CurlUrl $url, int $part, string $content, int $flags
> = 0): bool {}
> function curl_url_get(CurlUrl $url, int $part, int $flags = 0):
> string|false {}
> function curl_url_errno(CurlUrl $url): int {}
> function curl_url_strerror(int $error_code): ?string {}
>
> - Add methods to the CurlUrl object to make it less opaque and expose an
> object oriented style API. I would keep it minimal and let userlanAd API
> provide higher level APIs as guzzle for example. (You can see the current
> implementation [5])
>
> final class CurlUrl implements Stringable
> {
> public function __construct(?string $url = null) {}
> public function get(int $part, int $flags = 0): string {}
> public function set(int $part, string $content, int $flags = 0): void
> {}
> public function getErrno(): int {}
> public function __toString(): string {}
> public function __clone() {}
> }
>
> - It would also be nice to add this object oriented API for existing
> CurlHandle, CurlMultiHandle and CurlShareHandle classes. For example the
> CurlHandle class would look like that (First implementation [6])
>
> final class CurlHandle
> {
> public function __construct(?string $url = null) {}
> public function setOpt(int $option, mixed $value): bool {}
> public function getInfo(?int $option = null): mixed {}
> public function exec(): string|bool {}
> public function escape(string $string): string|false {}
> public function unescape(string $string): string|false {}
> public function pause(int $flags): int {}
> public function getErrno(): int {}
> public function reset(): void;
> public function setOptArray(array $options): bool {}
> public function upkeep(): bool {}
> public function __clone() {}
> }
>
> As of right now I still have some unanswered questions like how should we
> handle errors on the new CurlUrl API ?
> - Throw `CurlUrlException` on both the procedural and object oriented style
> API (that's how current implementation works [5])
> - Throw `CurlUrlException` with the oriented style API, but return for
> example boolean/null on errors when user uses the procedural API ?
> - Always return null/booleans using both object oriented API and
> procedural API ?
>
> The same question applies if we add a new object oriented style API on
> existing classes. Current functions MUST stay unchanged but should we throw
> `CurlException` when the user uses the object oriented style API ? (That's
> what I would do) Or should we return the same result from OO and procedural
> API ? Should we make the new CurlApi consistent with that ?
>
> What are your thoughts about all this ? Any feedback on any of those
> subjects are more than welcome.
>
> Pierrick
>
> [1]
> https://daniel.haxhttps://
> github.com/adoy/php-src/tree/curl-object-apix.se/blog/2018/10/31/curl-7-62-0-moar-stuff/
>
Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3
On Sun, Jun 12, 2022 at 6:55 PM Rowan Tommins wrote: > > >It seems to me that you agree that there is a chance the proposed syntax > is > >going to be perceived as better and people will not want to use the old > >syntax anymore and that makes you not want to accept the RFC. > > No, it makes me want to make the new syntax as useful as possible. > On the sentiment, we can agree. It just happens that from where I'm standing, any change to the proposed syntax will make it less useful. -- Marco Aurélio Deleu
Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3
On Sun, Jun 12, 2022 at 2:29 PM Rowan Tommins wrote: > On 11/06/2022 23:01, Deleu wrote: > > The RFC does mention that the existing Anonymous Function Syntax > > remains untouched and will not be deprecated. Whether the new syntax > > is better for nearly all closures will be a personal choice. > > > I honestly don't think this is how it will be perceived. If this syntax > is approved, people will see "fn" as the "new, better way" and > "function" as the "old, annoying way". > And to me that's not an argument to deny what people want. > To put it a different way: imagine we had no closure support at all, and > decided that we needed two flavours, one with explicit capture and one > with implicit capture. Would we choose "function" and "fn" as keywords? > I often don't indulge such hypotheticals because we will never truly be able to make progress based on such an assumption. A breaking change that changes how closure works is just not gonna happen. Given the current state in the world we're in, what can we do to have a better DX on anonymous functions? > > > The previous discussions talked about use(*) or use(...) and most > > people I know that would love this RFC to pass would also dislike that > > alternative. It does not have the greatest asset for short closure: > > aesthetics. [...] All I can say is that use(*) is not a replacement > > for the RFC. > > > I think you're trying to have it both ways here: if you really believed > that the two syntaxes were going to live side by side, there would be no > reason for "aesthetics" to be any more important for one than the other. > > Some people are of the opinion that automatic capture should always have > been the default, and the current syntax is a mistake. I'm fine with > that opinion, but I want people to be honest about it rather than > pretending they're just adding a new option for a narrow use case. > > Honestly I don't think it was a mistake. It was designed more than a decade ago and there was no way of predicting the future. I've seen code written 20~10 years ago and I've seen code written 5~0 years ago. I think the best decision was taken at the time it was taken and the world of development has changed enough for us to make different decisions now. It's not that I'm trying to have it both ways, I'm just not assuming my view is the right one. I do believe that if such an RFC is approved, I will almost never reach for `function () use ()` anymore because I will prefer the short syntax. If I need a new scope I will reach for an invocable class. But that doesn't mean other teams/projects/people are forced to agree or follow the same practices as me or my team. > > > Any attempt to make it explicit defeats the purpose of the RFC. > > > That depends what you think the purpose of the RFC is, which is what I > want people to be honest about. > > If the purpose is to replace long lists of captured variables, an > explicit "capture all" syntax like "use(*)" achieves that purpose > perfectly fine. > > If someone decides to implement `function () use (*)` on a separate RFC, I would abstain from that because it's not something I'm interested in using and it doesn't address the aesthetic issue we have today. I just don't like it being considered an alternative to the current RFC because it's not. The purpose is to replace long lists of captured variables while addressing the aesthetic issue caused by `use ()`, which is the only place in the language we use this construct. It seems to me that you agree that there is a chance the proposed syntax is going to be perceived as better and people will not want to use the old syntax anymore and that makes you not want to accept the RFC. Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > -- Marco Aurélio Deleu
Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3
On Sat, Jun 11, 2022 at 11:14 PM Rowan Tommins
wrote:
> On 09/06/2022 17:34, Larry Garfield wrote:
> > Last year, Nuno Maduro and I put together an RFC for combining the
> multi-line capabilities of long-closures with the auto-capture compactness
> of short-closures ... Arnaud Le Blanc has now picked up the flag with an
> improved implementation ... The RFC has therefore been overhauled
> accordingly and is now ready for consideration.
> >
> > https://wiki.php.net/rfc/auto-capture-closure
>
>
> They may sound like the same thing, but to me "short closure syntax"
> (and a lot of the current RFC) implies that the new syntax is better for
> nearly all closures, and that once it is introduced, the old syntax
> would only really be there for compatibility - similar to how the []
> syntax replaces array() and list(). If that is the aim, it's not enough
> to assert that "the majority" of closures are very short; the syntax
> should stand up even when used for, say, a middleware handler in a
> micro-framework. As such, I think we need additional features to opt
> back out of capturing, and explicitly mark function- or block-scoped
> variables.
>
The RFC does mention that the existing Anonymous Function Syntax remains
untouched and will not be deprecated. Whether the new syntax is better for
nearly all closures will be a personal choice. If the new syntax doesn't
suit, say, a middleware handler, then we still can:
- reach for the old syntax
- use invocable classes
- call another method or function which creates a brand new scope and then
returns a function/callable.
>
> On the other hand, "auto-capturing" could be seen as a feature in its
> own right; something that users will opt into when it makes sense, while
> continuing to use explicit capture in others. If that is the aim, the
> proposed syntax is decidedly sub-optimal: to a new user, there is no
> obvious reason why "fn" and "function" should imply different semantics,
> or which one is which. A dedicated syntax such as use(*) or use(...)
> would be much clearer. We could even separately propose that "fn" and
> "function" be interchangeable everywhere, allowing combinations such as
> "fn() use(...) { return $x; }" and "function() => $x;"
>
The previous discussions talked about use(*) or use(...) and most people I
know that would love this RFC to pass would also dislike that alternative.
It does not have the greatest asset for short closure: aesthetics. Maybe my
personal bubble is not statistically relevant, but this is where PHP
Internals is lacking on surveying actual users of the language to help on
such matters. All I can say is that use(*) is not a replacement for the RFC.
>
> To go back to the point about variable scope: right now, if you're in a
> function, all variables are scoped to that function. With a tiny handful
> of exceptions (e.g. superglobals), access to variables from any other
> scope is always explicit - via parameters, "global", "use", "$this", and
> so on. If we think that should change, we should make that decision
> explicitly, not treat it as a side-effect of syntax.
>
Any attempt to make it explicit defeats the purpose of the RFC. The
auto-capturing means we don't have to write awkward code to access
variables. The only way we have to avoid awkward syntax (such as use
($var1, $var2)) is to declare an entire new invocable class and send the
parameters via the constructor. When many variables are involved, that may
still be a great option, but doing that just for 1 variable and 2 lines is
quite... sad. When I think of new accessors for this particular case, they
would either be innovative or verbose. If they are verbose, we already have
a syntax for that. If they are innovative, it would be an awkward
out-of-place situation that doesn't happen elsewhere in the language. Or I
lack the imagination to see a different result.
Ultimately, I see fn() as "an opt-in to not create a separate scope for a
function". PHP has several language constructs that may or may not create a
separate scope.
Delimite Scope: function, method, class, procedural file
Shared scope: if, for, foreach, include, require and fn
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Marco Aurélio Deleu
Re: [PHP-DEV] Re: Allow default parameters before non-default ones?
On Thu, Dec 9, 2021 at 6:48 AM Mark Randall wrote: > On 09/12/2021 05:22, André Hänsel wrote: > > This is very useful because I can add an optional parameter to a function > > and prevent users of my function from using the parameter in a positional > > way. This way I don't have to make a compatibility promise to never > change > > the position of this parameter. > > > I would much prefer we could find a way to give this proper support > rather than a hack. > > I frequently use large numbers of named arguments and would very much > like to be able to knock out the ability to use positional arguments, > thus ensuring I can change the order (e.g. inserting a new argument > after a related one) without a BC break. > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > If this were to happen, would it be an attribute to be added to the functions, a new keyword to declare named-parameter functions only or a different way to declare parameters? Are there other options? -- Marco Aurélio Deleu
Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties
On Tue, Nov 16, 2021 at 3:59 PM James Gilliland wrote: > On Tue, Nov 16, 2021 at 4:23 AM Rowan Tommins > wrote: > > > On 16/11/2021 09:27, Andreas Heigl wrote: > > > > > >> I see, yes, code that is 100% perfectly tested can get away without > > >> the language performing any error checking at all - the behaviour is > > >> all guaranteed by the tests. I would be very surprised if even 1% of > > >> PHP applications can claim such comprehensive tests. > > > > > > The topic here was that new code can verify the declaration of a > > > property by using tests. That does not need to happen on the language > > > level. I was never talking about adding tests for existing code. > > > > > > > > For most code bases, even new ones being written from scratch in PHP > > 8.0, that level of testing simply doesn't exist, and having the language > > tell you "hey, you wrote $this->loger instead of $this->logger" is a > > useful feature. And, in a lot of cases, more useful than having the > > language say "OK, I've created your dynamic $loger property for you", > > which is what currently happens. > > > > What you described there sounds like a warning and not a fatal error. Maybe > that's where some of the trepidation is coming from. I know I'm less > worried about the deprecation notice and more worried about what happens in > PHP 9 when it's a fatal error. > I can't say that this line of reasoning has its merits, but then there's no benefit to the engine itself. Issuing a warning and carry on materializing dynamic properties will never bring the original performance improvement that was part of the original state of the RFC. -- Marco Aurélio Deleu
Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties
On Tue, Nov 16, 2021, 00:36 wrote: > L.S., > > As some of you may have seen, I posted a thread on Twitter a few days > back referencing this RFC: > https://twitter.com/jrf_nl/status/1459221549429542920 > > I've been asked to post the link to the Twitter discussion in this > thread for visibility. > > The Twitter thread generated, and is still generating, quite a lot of > discussion, which I believe is a good thing and I'd like to thank > everyone of you who has been actively participating in these discussions > and has taken the time to read the various opinions. > > The thread, however, is not specifically about this RFC, but more about > the more poignant issue of the current pace of deprecations in PHP, the > impact of the workload these cause for open source project maintainers > and the stagnation I'm currently seeing in PHP open source releases and > innovation as a result of this. > > As I'm posting here now anyway, I'd like to leave the following feedback > for your consideration: > > From what I've gathered from responses and the added "Motivation" > section (thanks Nikita), this RFC is intended as a stepping stone > towards eventually removing support for dynamic properties from PHP > completely. > This only got cursory mention in the RFC and the RFC as it is, does not > lay out a clear path towards that end-goal. > If memory serves me right, Nikita planned to always leave dynamic properties bound to a single class (possibly stdClass as it is its natural use). That would have allowed for performance improvement on the engine. However, as we've seen from the Serializable RFC, planning out a 2-major change means voting today for a change that will only take place in 10 years. That's too long of a time to predict whether the change being voted even makes sense. As it currently stands, I believe the RFC outlines the best it can do with the context in which we are. If nothing else ever happens in the matter, we're left in a better place anyway. > What I miss in this RFC - and also oftentimes in other RFCs over the > past few years - are: > * The real reason behind this change proposal. "Modern code doesn't use > this" is not a reason and also not always true. > * An impact and workload analysis for userland PHP code, no matter how > tentative. > * Argumentation that this is the right stepping stone towards eventually > being able to achieve the end-goal of removing support altogether and a > tentative outline of what the path towards that end-goal will look like, > both in timeline, next steps and (tentative) criteria of when it would > be acceptable to take those steps. > I see a pattern in these discussions from two mindsets: one thinking about how we should design the future and another thinking about how we preserve the past. In the past static analyzes wasn't even a thing in PHP. Nowadays we produce code that is much more likely to be analyzable in the future than a decade or two ago. The camp of people that has to deal with code that "is better left untouched" will often find these type of RFC lacking in motivation i.e "why are you making me touch that code that I don't want to touch or shouldn't have to touch?". Likewise the people that has already suffered through these code and want to prevent them from being a constant problem will need little convincing that the change is good. > Without the above, the RFC as it currently is, is IMHO just creating > more busy-work without a clear path forward. > > Please also take note that while this deprecation may not have much of > an impact on applications which have full control over their server and > the PHP version on which the code is run, as those have a) full access > to server logs and b) can use tools like Rector to upgrade (once a > Rector for this has been written), this is a whole different ball-game > for open source. > > As pointed out before, static analysis tools (once written) can help, > but may struggle to analyse the code using dynamic properties correctly > in all cases. > > In the end, if this gets deprecated, the best way to find the potential > problematic instances, is, like always, a test suite with near full code > coverage to see all deprecations, but let's also be realistic: a full > test suite is a luxury few open source projects actually have. > > And even when a full test suite is available, and this is probably the > most important problem I see: **open source libraries are generally > building-blocks in a larger whole, where the library itself has no > control over how their users are using the code, let alone have any > indication of whether their users may be using or extending the library > in ways which _rely_ on dynamic properties.** > This uncertainty may lead to "abuse" of the attribute to prevent > introducing a breaking change. > I know you didn't mean it that way but I can't help but interpret this as a great motivation on why this RFC should be approved. It allows for a world to exist (in 3 years)
