() methods which just forward
equals() to the nested objects
- standardize such comparisons on the language level
Of course how exactly this operator looks may be changed, `~=` is just an
example.
WDYT?
Regards,
Illia / someniatko
ay "loses" its shape.
Regards,
Illia / someniatko
-wrapper of a
value of lack thereof: it's either `Some` or `None`. I also maintain
a similar library https://packagist.org/packages/someniatko/result-type
which fixes some shortcomings of the original one related to the static
analysis, but this is another story. Basically what the stats tell us
Got it, thank you for explaining.
Regards,
Illia / someniatko
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ter to do this for
`SQLite3Exception` as well.
Regards,
Illia / someniatko
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
his feature also translates to PHP code. If
my suggestion ever becomes an RFC, this way of implementing it may become a
separate vote I suppose.
Regards,
Illia / someniatko
> This sounds interesting but it breaks some expectations.
>
> Interesting because you can have any class act as an interface for other
> classes with the interface being built up of any public properties or method
> that exists on that class.
In my original suggestion, it's not like any class,
e addition to the language?
Regards,
Illia / someniatko
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
s feature will be useful? I see
it's coming from statically typed / compiled languages like C++, but in
such languages compiler must know variable type in order to manage memory
properly. As PHP is an interpreted language, it doesn't have this problem.
Regards,
Illia / someniatko
Hi,
These all are valid concerns! I cannot speak about management and cost
issues though, as I am not an active PHP dev team member.
> 3. What's the MVP? How do we measure usefulness, adoption and maintenance
> complexity?
As a shot in the dark, the first step could be implementation of typed
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
thoughts with you
and propose something for consideration.
Regards,
Illia / someniatko
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
> What's convenient about `Foo::{$bar}` vs `constant(Foo::class . '::' .
> $bar)`? I'm a bit confused by this :|
>
> Is it the few keystrokes added?
Even if ignoring syntax / convenience bikeshedding, I find it a really
valuable addition to the language self-consistency. It's symmetrical
to the
> To solve this, I propose adding an ARRAY_UNIQUE_IDENTICAL option that
> can be passed to array_uniques $flags which uses identical operator
> (===) semantics. Internally it uses a new hashmap that allows using
> arbitrary PHP values as keys to efficiently remove duplicates. This is
> slightly
, which are not related to the work amount :P
Thank you for your work!
Regards,
someniatko
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
polyfill the `is_literal()` function to always return `true` and be
able to both take advantage of PHP 8.1 and work on the earlier
versions.
I hope these points will be really considered, and PHP's type system
will evolve into more robust and strong one. (offtopic: hoping we will
have typed vector and di
ay take user input, i.e. you could
explicitly state "this function does only work with literal strings".
Regards,
someniatko
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
> Unless there is any significant feedback, I'll be calling a vote for this RFC
> sometime late this week (Thursday/Friday-ish).
Hi! As a regular PHP developer, I am very interested in having this
quality-of-life feature: it allows code whose intent is more
functional-ish (mapping input
nce,
some future RFC moves them into a special `PHP\Array` namespace, which
would probably never happen, but it's allowed to dream), it could look
like this:
```php
$array|>map($fn1, ?)|>filter(?, $fn2);
$array->map($fn1)->filter($fn2);
```
A bit longer (due to 2.), but not that much, actu
"people" you refer to are, because, well, I
am among the people using PHP daily, and I would personally prefer a
more generic solution, which the Pipe Operator currently is.
Best wishes,
someniatko
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
map($somefunction, ?);
```
Best wishes,
someniatko
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
```
Best wishes,
someniatko
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
> The GitHub PR supports this, and there is even a comment there saying
> we should show this in the RFC. We'll get that updated.
Thank you for the quick reaction and for your work!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
> Greetings, Internalians!
>
> I would like to offer for your consideration another RFC, specifically syntax
> for partial function application.
>
> https://wiki.php.net/rfc/partial_function_application
Thank you again for one more wonderful language change! I am sure this
is a huge step into
> Should we be planning ahead for some future where union and intersection
> types can be mixed and design the reflection API accordingly? I worry that
> if we have a ReflectionIntersectionType, and a ReflectionUnionType, that
> ReflectionIntersectionAndUnionType is just going to make both
`match` is an expression, where as if-else construction is not. This
allows for combining it with a potential future feature of single line
functions and methods. For example (hypothetical syntax is used):
```
function getNumberKind(int $number) => match {
$number > 0 => NumberKind::POSITIVE,
Hello Internals,
Here is a small comparison table based on current feedback, maybe it
will bring some objective clarity to the discussion:
(markdown below)
Impact|`@@`|`#[]`
---|---|---
BC break|virtualy nonexistent|slightly broader: `##[` comments are now broken.
Parser|no technical problems by
> I think going from forbidding
> return types on ctors to requiring them to be void is one step to far.
I am afraid you've slightly misunderstood the intention of this RFC.
It is proposed that it is impossible to return anything from the
constructor, not that you have to add ": void" to it.
--
> I've reworded some things and added more information on short
> circuiting. Functionality wise the RFC has remained the same.
>
> Since there was little negative feedback I'd like to put this feature
> to a vote in ~1 week. If you have any concerns or criticism please let
> me know in time.
> This would seem to fit your use case with Shoop quite well:
> rather than Shoop::array($array)->first()->unfold(), you would just call
> $array->first(). It's fairly high on a lot of people's wish lists, but
> there's a lot of details to get right in both design and implementation,
> so I
I do agree with Marco that this is a step in a wrong direction. Our
goal should be not ensuring that a prop is not rewritten outside, but
rather that it is not re-written at all. It makes no sense to rewrite
a property in majority of cases:
1. fields of an DTO - nay. Should be immutable instead.
31 matches
Mail list logo
