e GMP, but the niche in PHP is smaller for
that use case.
Regards,
Illia / someniatko
riting boilerplate equals() 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
e
array "loses" its shape.
Regards,
Illia / someniatko
is a class-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 s
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
this for
`SQLite3Exception` as well.
Regards,
Illia / someniatko
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
onstructors - this 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,
is 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
cribe some use cases where this 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
l
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
o share my 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 al
> 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 ove
ments, 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
or (PHP 8.1), or
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
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 arguments
for instance,
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
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 the
> 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 impl
`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.
Just
> 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 strongl
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. Yo
32 matches
Mail list logo
