On Tue, 14 Nov 2023 at 18:49, Robert Landers wrote:
>
> On Tue, Nov 14, 2023 at 1:39 PM Andreas Hennings wrote:
> >
> > Hello Robert,
> >
> > On Tue, 14 Nov 2023 at 11:09, Robert Landers
> > wrote:
> > >
> > > Andreas,
> > >
>
On Tue, 14 Nov 2023 at 02:08, David Gebler wrote:
>
> On Sun, Nov 12, 2023 at 8:20 PM Andreas Hennings
> wrote:
>
> > So to me, this alone is an argument to implement this natively.
> > The other argument is that it is kind of sad how the current functions
> > do
Hello Robert,
On Tue, 14 Nov 2023 at 11:09, Robert Landers wrote:
>
> Andreas,
>
> Just out of curiosity, what is the use case for this? I can't really
> think of a practical case where strict checking is needed for these
> functions. Usually, you have a really good idea of what is in the
>
On Sat, 11 Nov 2023 at 20:43, Andreas Hennings wrote:
>
> Hello David,
>
> On Sat, 11 Nov 2023 at 20:04, David Gebler wrote:
> >
> > On Sat, Nov 11, 2023 at 6:05 PM Andreas Hennings
> > wrote:
> >
> > > Hello internals,
> > > I noticed t
Hello David,
On Sat, 11 Nov 2023 at 20:04, David Gebler wrote:
>
> On Sat, Nov 11, 2023 at 6:05 PM Andreas Hennings
> wrote:
>
> > Hello internals,
> > I noticed that array functions like array_diff(), array_intersect()
> > etc use weak comparison.
> >
&
Hello internals,
I noticed that array functions like array_diff(), array_intersect()
etc use weak comparison.
E.g.
array_diff([0, '', false, null], [null])
only leaves [0].
This makes these functions useless for a number of applications.
Also it can lead to unpleasant surprises, if a developer
Hello Ilija,
On Sat, 17 Jun 2023 at 13:27, Ilija Tovilo wrote:
>
> Hi Andreas
>
> On Fri, Jun 16, 2023 at 9:23 PM Andreas Hennings wrote:
> >
> > Hello list,
> > I don't know if something like this was already proposed in the past,
> > I did not find anything
Hello Rowan, Ilja,
(sorry I did not see these replies sooner, I do some forwarding but it failed)
On Sat, 17 Jun 2023 at 16:59, Rowan Tommins wrote:
>
> On 17/06/2023 12:26, Ilija Tovilo wrote:
> > I don't believe blocks for general expressions are that useful in PHP
> > due to the lack of block
Hello list,
I don't know if something like this was already proposed in the past,
I did not find anything.
Sometimes it would be nice to have a code block inside an expression, like this:
public function f(string $key) {
return $this->cache[$key] ??= {
// Calculate a value for $key.
On Tue, 30 May 2023 at 22:45, Larry Garfield wrote:
>
> On Tue, May 30, 2023, at 7:34 PM, Andreas Hennings wrote:
> > On Tue, 30 May 2023 at 19:12, Larry Garfield wrote:
> >>
> >> I've run into this issue in my attribute library as well
> >> (https://githu
On Tue, 30 May 2023 at 19:12, Larry Garfield wrote:
>
> I've run into this issue in my attribute library as well
> (https://github.com/Crell/AttributeUtils). What I do there is allow
> attributes to opt-in to a callback method via interface. For example:
>
> #[\Attribute]
> class
On Tue, 30 May 2023 at 18:48, Larry Garfield wrote:
>
>
>
> --
> Larry Garfield
> la...@garfieldtech.com
>
> On Tue, May 30, 2023, at 2:42 AM, Andreas Hennings wrote:
> > Hello list,
> > this proposal will be useful in combination with "Declaration-a
b9f03b310#file-test_array_group-php
> >> 3. Another example, addressing the problem of increasing subsequences is
> >> very simple with `array_group`:
> >> https://gist.github.com/bor0/b5f449bfe85440d96abd933b9f03b310#file-test_array_incr_subseqs-php
> >>
&g
$group = [];
}
$group[] = $value;
$prev = $value;
}
if ($group) {
$groups[] = $group;
}
return $groups;
}
On Tue, 30 May 2023 at 18:21, Andreas Hennings wrote:
>
> Thank you, this clarifies and it confirms my initial assumption of
> what you are proposi
ces is very
> simple with `array_group`:
> https://gist.github.com/bor0/b5f449bfe85440d96abd933b9f03b310#file-test_array_incr_subseqs-php
>
> Best,
>
> Boro
>
> > On 30.5.2023, at 16:57, Andreas Hennings wrote:
> >
> > Hello Boro,
> > I think you should i
Hello Boro,
I think you should include the "expected result" in your code examples.
Maybe this is in your patch file, but I don't think we want to look at
that for discussion.
Cheers
Andreas
On Tue, 30 May 2023 at 13:35, Boro Sitnikovski wrote:
>
> Hello all,
>
> As per the How To Create an RFC
On Tue, 30 May 2023 at 15:14, Stephen Reay wrote:
>
> (Resending to the list without all the history because qmail complained about
> message size)
>
>
> >>
> >> Hi Andreas,
> >>
> >> I too have wondered (and I think asked in room11?) about such a concept.
> >> >From memory the general response
On Tue, 30 May 2023 at 05:22, Stephen Reay wrote:
>
>
>
> > On 30 May 2023, at 07:48, Andreas Hennings wrote:
> >
> > Hello internals,
> > I am picking up an idea that was mentioned by Benjamin Eberlei in the past.
> > https://externals.io/message/1102
Hello list,
this proposal will be useful in combination with "Declaration-aware attributes"
Problem
Currently, ReflectionMethod is not aware of the original class, if the
method is declared in a parent class.
Methods that are called during a discovery algorithm that need to
process a
I just notice a flaw in my thinking.
On Tue, 30 May 2023 at 02:48, Andreas Hennings wrote:
>
> Note that for methods, we typically need to know the method reflector
> _and_ the class reflector, because the method could be defined in a
> base class.
This is true when doing a dis
Thanks for the feedback!
On Tue, 30 May 2023 at 03:43, Dusk wrote:
>
> On May 29, 2023, at 17:48, Andreas Hennings wrote:
> > Quite often I found myself writing attribute classes that need to fill
> > some default values or do some validation based on the symbol the
> &g
public readonly string $y,
) {}
}
On Tue, 30 May 2023 at 02:48, Andreas Hennings wrote:
>
> Hello internals,
> I am picking up an idea that was mentioned by Benjamin Eberlei in the past.
> https://externals.io/message/110217#110395
> (we probably had the idea independently, bu
Hello internals,
I am picking up an idea that was mentioned by Benjamin Eberlei in the past.
https://externals.io/message/110217#110395
(we probably had the idea independently, but Benjamin's is the first
post where I see it mentioned in the list)
Quite often I found myself writing attribute
On Tue, 18 Apr 2023 at 22:01, Bob Magic wrote:
>
> > [1] In fact if the right hand side of with may be an expression that
> > evaluates to an array, folks wouldn't need to learn new syntax at all:
> >
> > $newProperties = [ "foo" => "bar" ];
> > clone $object with $newProperties;
> >
> >
> The biggest advantage of Nicolas' proposal over “clone with” is that it could
> be made part of the interface contract whether a method modifies the object
> state. So the PSR-7 ResponseInterface could look like the following:
> [..]
> public clone function withStatus($code, $reasonPhrase =
Hello Máté, internals,
I have been waiting for this to happen :)
Some feedback
> However, in some cases it would be useful to reference property names as
> expressions, e.g. when one needs to use “clone with” in a foreach loop where
> the index is the property name and the loop variable is the
> I have the feeling I'm missing something, but how would this compare to
array join
Array join does neither append nor replace if a numeric index already exists.
But you can do [...$arr0, ...$arr1].
https://3v4l.org/CIinR
print json_encode([
[...['a', 'b'], ...['c', 'd']], // [a, b, c, d]
Hello,
the RFC seems like a good idea to me.
However, I do not see any mention of plus operator on arrays, e.g. ['a' =>
'A'] + ['b' => 'B']. The array_reduce() would support this, but I think
array_sum() would not, because of the return type. I just think this should
be made more explicit.
--
On Thu, 21 Apr 2022 at 11:18, Rowan Tommins wrote:
>
> On Wed, 20 Apr 2022 at 19:16, Claude Pache wrote:
>
> > > You make a very important claim in your bug report:
> > >
> > > > However, in real world, is_callable() is almost never given totally
> > arbitrary stuff
> > >
> > > My concern is
A deprecation warning on is_callable() would imply that in a future
version of PHP that call will be illegal.
But this is not the case.
is_callable() is meant to accept any value, and return true or false.
is_callable('static::method') will still be a valid call in future
versions, only the result
> sketch out a more complete picture for the type
system. We can implement it in pieces and parts, but we should have a goal
in mind for where we want to land.
I think the type system in psalm is pretty cool. It does have fixed
literal values, but also deeply structured array types.
But:
- I
Hello list.
Another potential benefit of such interfaces can be polyfills.
PHP 8.x: class ReflectionClass implements Reflector, AttributesHaving {..}
PHP 7.x. class UserlandReflectionClass extends ReflectionClass
implements AttributesHaving {..}
function f(AttributesHaving $reflector) {
On Tue, 1 Mar 2022 at 21:03, DANIEL VARGAS MUCCILLO
wrote:
>
> >
> > I *think* all Reflector children support attributes, so it may not need a
> > separate interface.
>
>
> ReflectionZendExtension and ReflectionExtension are currently the only ones
> who implement Reflector but don't support
ybody who is afraid of some disruption and debate in this mailing list:
Think of the disruption it would cause if your house gets bombed, the
freedom in your country is threatened, your family has to flee the
country.
-- Andreas Hennings
>
>
> > I have put something on my
On Thu, 13 Jan 2022 at 15:36, Andreas Hennings wrote:
>
> Hello list,
> I want to bring up a topic that has bothered me whenever I use traits.
> I don't have a solution proposal for it, yet, unfortunately.
> I was going to comment in the other thread about traits, but it seems
Hello list,
I want to bring up a topic that has bothered me whenever I use traits.
I don't have a solution proposal for it, yet, unfortunately.
I was going to comment in the other thread about traits, but it seems
better suited for a new discussion.
--
Traits allow to share code between
On Wed, 5 Jan 2022 at 20:11, Jordan LeDoux wrote:
>
>
>
> On Wed, Jan 5, 2022 at 6:33 AM Andreas Hennings wrote:
>>
>> Hello Jordan,
>> do you have any thoughts about these symmetric/left/right modifiers,
>> to get rid of the $operandPos parameter?
>>
of the RFC?
Cheers
Andreas
On Tue, 4 Jan 2022 at 00:27, Andreas Hennings wrote:
>
> Hello Jordan,
>
> I have another note about the RFC.
> (I am not sure what's the policy, if we should continue _all_
> discussion here or go back to the RFC thread. Hope it's ok here.)
>
>
On Tue, 4 Jan 2022 at 03:23, Jordan LeDoux wrote:
>
>
>
> On Mon, Jan 3, 2022 at 4:05 PM Andreas Hennings wrote:
>>
>> To me it is not surprising that an RFC like this would be controversial.
>> We could enter a wonderful new era of value objects with operators,
On Mon, 3 Jan 2022 at 22:15, Jordan LeDoux wrote:
>
> On Mon, Jan 3, 2022 at 9:07 AM Pierre wrote:
>
> > I forgot to answer to that, specifically. I'd much more prefer to have
> > an explicit `equals(object $other): bool` (magic or not, really I do not
> > care) single method for equality only,
Hello Jordan,
I have another note about the RFC.
(I am not sure what's the policy, if we should continue _all_
discussion here or go back to the RFC thread. Hope it's ok here.)
OperandPosition::LeftSide
OperandPosition::RightSide
I wonder if this is the best way to model this.
Especially, it
On Mon, 3 Jan 2022 at 16:00, Marco Pivetta wrote:
>
> Hey Andreas,
>
> On Mon, Jan 3, 2022 at 3:40 PM Andreas Hennings wrote:
>>
>> I imagine that operator overloads can improve DX for these use cases,
>> but at a cost for the overall language.
>>
>
One question that just occured to me:
Why allow the "public" keyword for visibility, if operators are public
automatically, and "private" and "protected" are not allowed?
Do we plan for private/protected operators in the future?
Shouldn't we eliminate meaningless choice?
On Mon, 3 Jan 2022 at
On Mon, 3 Jan 2022 at 02:07, Marco Pivetta wrote:
>
> Hey Jordan,
>
> I've voted "no" on this one: infix functions may have been interesting, but
> adding a whole new type system around operators is really not worth it,
> given:
>
> * Added AST nodes
> * Added method definitions for niche
On Sun, 2 Jan 2022 at 06:20, Michael Morris wrote:
>
> On Sat, Jan 1, 2022 at 10:47 PM Kirill Nesmeyanov wrote:
>
> >
> > >Суббота, 1 января 2022, 17:41 +03:00 от Rowan Tommins <
> > rowan.coll...@gmail.com>:
> > >
> > >On 31/12/2021 00:21, Kirill Nesmeyanov wrote:
> > >> I support this behavior
On Tue, 21 Dec 2021 at 23:20, Jordan LeDoux wrote:
>
>
>
> On Tue, Dec 21, 2021 at 5:47 AM Andreas Hennings wrote:
>>
>> I see the "Implied Operators" section.
>> I assume this means that a new instance will be created, and stored on
>> the same v
On Tue, 21 Dec 2021 at 02:57, Jordan LeDoux wrote:
>
>
>
> On Mon, Dec 20, 2021 at 4:43 PM Andreas Hennings wrote:
>>
>> > The exact position of where that trade-off is 'worth it' is going to
>> > be different for different people. But one of the areas where P
On Tue, 21 Dec 2021 at 10:13, Rowan Tommins wrote:
>
> On 21/12/2021 00:43, Andreas Hennings wrote:
> > I think the example in the RFC is interesting, but not ideal to
> > advertise the RFC.
> > The example is with native scalar types and build-in operator
> > impl
On Tue, 21 Dec 2021 at 00:03, Dan Ackroyd wrote:
>
> On Fri, 17 Dec 2021 at 18:36, Stanislav Malyshev wrote:
> >
> > When reading
> > this code: $foo * $bar - how do I know which of the ways you took and
> > where should I look for the code that is responsible for it? When I see
> >
On Fri, 17 Dec 2021 at 00:25, Larry Garfield wrote:
>
> On Thu, Dec 16, 2021, at 1:24 PM, Andreas Hennings wrote:
>
> > I see the distinction in overloading based on the object type on the
> > left, vs overloading based on parameter types.
> >
> > For a method c
On Thu, 16 Dec 2021 at 19:20, Dan Ackroyd wrote:
>
> On Thu, 16 Dec 2021 at 12:21, Andreas Hennings wrote:
>
> > Methods and functions have searchable and clickable names. Operators don't.
> > The "searchable" applies to grep searches in code, but also google
>
Hello internals,
some concerns I have about operator overloading.
(I have seen and played with operator overloading long time ago in
C++, this is my background for these points.)
1. Searchable names.
Methods and functions have searchable and clickable names. Operators don't.
The
Oct 2021 at 08:18, Andreas Hennings wrote:
>
> On Sat, 2 Oct 2021 at 16:37, tyson andre wrote:
> >
> > Hi Andreas,
> >
> > > Hello list,
> > > I would like to propose new methods for ReflectionType, that would
> > > allow treating ReflectionNamed
On Sun, 3 Oct 2021 at 07:40, Sebastian Bergmann wrote:
>
> Am 02.10.2021 um 16:37 schrieb tyson andre:
> > `ReflectionType->allowsValue(mixed $value, bool $strict = true): bool`
>
> Not having to implement and maintain that functionality in userland would
> be brilliant and much appreciated.
On Sat, 2 Oct 2021 at 16:37, tyson andre wrote:
>
> Hi Andreas,
>
> > Hello list,
> > I would like to propose new methods for ReflectionType, that would
> > allow treating ReflectionNamedType and ReflectionUnionType in a
> > unified way.
> > This would eliminate the need for if (.. instanceof) in
Hello list,
I would like to propose new methods for ReflectionType, that would
allow treating ReflectionNamedType and ReflectionUnionType in a
unified way.
This would eliminate the need for if (.. instanceof) in many use cases.
Some details can still be discussed, e.g. whether 'null' should be
Hello Levi,
I thought it was clear.
By static "factory" method I just mean any static method that returns an object.
Don't interpret too much into the term :)
So to clarify, here is an example:
class OtherAttribute {}
class MyAttribute {
public function __construct(string $name) {..}
Hello list,
currently, the default mode for attributes is to create a new class.
For general initializers, with
https://wiki.php.net/rfc/new_in_initializers we get the option to call
'new C()' for parameter default values, attribute arguments, etc.
Personally I find class construction to be
On Sat, 14 Aug 2021 at 15:05, Larry Garfield wrote:
>
> On Sat, Aug 14, 2021, at 7:48 AM, G. P. B. wrote:
> > On Sat, 14 Aug 2021 at 10:55, Deleu wrote:
> >
> > > Hi Jordan,
> > >
> > > Does it make sense to explain in the RFC the difference between never and
> > > mixed in this context? The RFC
On Wed, 8 Sept 2021 at 23:00, Rowan Tommins wrote:
>
> On 08/09/2021 16:37, Mike Schinkel wrote:
>
> > All future code that needs to refer to the class name will still refer to
> > `stdClass`, so we won't be gaining much by creating an alias.
>
>
> Just to be clear, the only code that would need
hard-coded internal implementation when calling
json_encode() or converting to array.
https://3v4l.org/rAc4K
I think we would want something more clean and transparent.
On Wed, 8 Sept 2021 at 21:58, Andreas Hennings wrote:
>
> On Wed, 8 Sept 2021 at 18:33, Lynn wrote:
> >
> &
On Wed, 8 Sept 2021 at 18:33, Lynn wrote:
>
> On Wed, Sep 8, 2021 at 5:38 PM Mike Schinkel wrote:
>
> > A couple more things; add a `JSON_OUTPUT_DYNAMIC_OBJECT` flag to output to
> > DynamicObject for `json_decode()`, add a 3rd parameter for flags to
> > var_export() for the same reason, a
$source['a0']['b01'] = 5;On Wed, 8 Sept 2021 at 16:48, Andreas
Hennings wrote:
>
> On Wed, 8 Sept 2021 at 16:10, Andreas Hennings wrote:
> >
> > Thanks for the feedback so far!
> >
> > On Wed, 8 Sept 2021 at 10:13, Marco Pivetta wrote:
> > >
> >
On Wed, 8 Sept 2021 at 16:10, Andreas Hennings wrote:
>
> Thanks for the feedback so far!
>
> On Wed, 8 Sept 2021 at 10:13, Marco Pivetta wrote:
> >
> > Heyo,
> >
> > On Wed, 8 Sep 2021, 02:19 Andreas Hennings, wrote:
> >>
> >> Hello
Thanks for the feedback so far!
On Wed, 8 Sept 2021 at 10:13, Marco Pivetta wrote:
>
> Heyo,
>
> On Wed, 8 Sep 2021, 02:19 Andreas Hennings, wrote:
>>
>> Hello internals,
>>
>> The function array_column() would be much more useful if there was an
>>
Hello internals,
The function array_column() would be much more useful if there was an
option to preserve the original array keys.
I can create an RFC, but I think it is better to first discuss the options.
This is requested in different places on the web, e.g.
On Sun, 25 Apr 2021 at 21:27, Larry Garfield wrote:
>
> 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
>
> It includes an implementation by
On Thu, 1 Apr 2021 at 15:05, Matthew Brown wrote:
>
> On Tue, 30 Mar 2021 at 13:51, Ilija Tovilo wrote:
>
> > Hi Matthew
> >
> > > I like the proposal. I also support the covariance.
> > >
> > > One question though.
> > > The RFC mentions possible future use of "nothing" as a bottom type for
> >
On Wed, 31 Mar 2021 at 14:41, Ilija Tovilo wrote:
>
> Hi internals
>
> On Wed, Mar 31, 2021 at 2:14 PM Andreas Hennings wrote:
> >
> > Also check my comment in the other thread:
> > If in the future we want a "bottom type" that also works for parameters
&g
Also check my comment in the other thread:
If in the future we want a "bottom type" that also works for parameters
(generics or abstract methods), should we create a new keyword, or should
we attempt to find a keyword now that works for all cases?
Neither "never" nor "noreturn" seems suitable for
Hello,
I like the proposal. I also support the covariance.
One question though.
The RFC mentions possible future use of "nothing" as a bottom type for
parameters in generics. This makes a lot of sense to me. Even without
generics, it could be used for parameters in abstract methods.
So why not
On Wed, 16 Sep 2020 at 04:00, Josh Bruce wrote:
>
> > * If PHP had either convention or special handling for _ or $_ as a
> “ignore this” destination, I wouldn’t have made the proposal. However, it
> doesn’t; _ can (apparently!) be a constant, and is also a function, and $_
> has no special
Interesting stuff!
https://wiki.php.net/rfc/constructor_promotion
I see this for the first time, but I like it :)
Now to your proposal.
Just to make sure I understand:
Would this map the parameters by name or by index?
-> I assume by index, it makes more sense.
Does it map to parent constructor
Good point about the static typing!
On Mon, 27 Jul 2020 at 20:40, Rowan Tommins wrote:
> Hi Andreas,
>
>
> On 27/07/2020 00:41, Andreas Hennings wrote:
> > 1. Calls with named arguments can only happen on:
> >- explicitly named functions (e.g. no call_user_func(
On Mon, 27 Jul 2020 at 03:18, tyson andre wrote:
> Hi Andreas Hennings,
>
> > 1. Calls with named arguments can only happen on:
> > - explicitly named functions (e.g. no call_user_func()).
> > - constructor calls with an explicitly named class.
> > - object m
reen');
This would be undesirably verbose for long interface names..
-
Best
Andreas
On Fri, 24 Jul 2020 at 18:14, Andreas Hennings wrote:
> TLDR
> Only consider parameter names from a type-hinted interface, ignore
> parameter names from the actual
TLDR
Only consider parameter names from a type-hinted interface, ignore
parameter names from the actual class.
-
I had a look at
https://wiki.php.net/rfc/named_params#to_parameter_name_changes_during_inheritance
Indeed I have concerns about this, because a call with named arguments
would
and there are people or
projects which want to do things their own way.
And of course there is the time before agreements are reached in specific
conventions, where people produce code which could be one way or the other.
I don't see a contradiction here.
Greetings
Andreas
> > Exactly my poi
it to be more universally usable.
>
> Last but not least, just to reiterate, the `: void` return type is
> optional and you don't need to specify it.
>
Exactly my point. "Optional" means people will make arbitrary choices and
argue about it, or look for a convention
Hi
The RFC introduces what I call a "meaningless choice", by making something
possible that is currently illegal, but which does not change behavior.
https://3v4l.org/daeEm
It forces organisations, frameworks or the php-fig group to introduce yet
another coding convention to decide whether or
Note that a comparison callback can also be broken in other ways:
- It could contain a loop, e.g. 'a' < 'b', 'b' < 'c', 'c' < 'a'.
- It could have alternating return values in subsequent calls with the same
arguments.
This kind of misbehavior cannot be easily detected.
The best we can do is make
When writing immutable classes, I want to be able to set properties in
static factories and in wither methods.
Once the new instance is sent to the outside world, its properties can be
locked to prevent further modification.
This sounds to me like we need different modes. Either the object
On Tue, 4 Feb 2020 at 22:19, Larry Garfield wrote:
> On Tue, Feb 4, 2020, at 12:40 PM, Aimeos | Norbert Sendetzky wrote:
> > Am 04.02.20 um 19:17 schrieb Rowan Tommins:
> > > I think Larry's point was that the flexibility of PHP's array type
> makes it
> > > really hard to pin down whether a
On Thu, 9 Jan 2020 at 20:53, Dik Takken wrote:
> On 09-01-2020 17:52, Andreas Hennings wrote:
> > On Thu, 9 Jan 2020 at 16:31, Nikita Popov wrote:
> >
> >> On Thu, Jan 9, 2020 at 4:06 PM Rowan Tommins
> >> wrote:
> >>
> >> An argument c
On Thu, 9 Jan 2020 at 16:31, Nikita Popov wrote:
> On Thu, Jan 9, 2020 at 4:06 PM Rowan Tommins
> wrote:
>
> > On Thu, 9 Jan 2020 at 14:23, Andreas Hennings
> wrote:
> >
> > > > However, $this is not a real type, and it is unclear what the
> advantag
On Thu, 9 Jan 2020 at 15:22, Andreas Hennings wrote:
> > However, $this is not a real type, and it is unclear what the advantage
> of specifying $this rather than static would be from a type system level
> perspective.
>
> Perhaps not from a "type system level", but
> However, $this is not a real type, and it is unclear what the advantage
of specifying $this rather than static would be from a type system level
perspective.
Perhaps not from a "type system level", but from a more broad "enforced
contract" level.
E.g. IDEs or code inspection tools can warn if a
On Sun, 24 Nov 2019 at 16:55, CHU Zhaowei wrote:
> > This proposal is not obsolete by the implementation of union types (i.e.
> > array|Traversable) because union data types are types/interfaces
> > combined by OR. "arrayable" is a combination of OR and AND:
> >
> > array|ArrayAccess
>
> True.
On Wed, 30 Oct 2019 at 22:06, Rowan Tommins wrote:
>
> Hi Dik,
>
> On 29/10/2019 21:44, Dik Takken wrote:
> > Opcache already performs type inference. [...]
> > Here is an interesting read on the subject:
> >
> > https://depositonce.tu-berlin.de/bitstream/11303/7919/3/popov_etal_2017.pdf
>
>
>
On Fri, 25 Oct 2019 at 12:27, Andreas Hennings wrote:
>
> On Fri, 25 Oct 2019 at 12:21, Rowan Tommins wrote:
> >
> > On Thu, 24 Oct 2019 at 22:20, Kosit Supanyo wrote:
> >
> > > But I think this functionality should be of something like pipeline
> > >
On Fri, 25 Oct 2019 at 12:21, Rowan Tommins wrote:
>
> On Thu, 24 Oct 2019 at 22:20, Kosit Supanyo wrote:
>
> > But I think this functionality should be of something like pipeline
> > operator:
> >
> > // send tmp variable to the next expression unconditionally
> > $ret = $_SERVER['fname'] |>
On Thu, 24 Oct 2019 at 23:49, Ken Stanley wrote:
>
> On Thu, Oct 24, 2019 at 4:29 PM Andreas Hennings wrote:
>>
>> On Thu, 24 Oct 2019 at 20:59, Ken Stanley wrote:
>> >
>> > On Thu, Oct 24, 2019 at 1:33 PM Dan Ackroyd wrote:
>> >
>> &
On Fri, 25 Oct 2019 at 01:28, Sara Golemon wrote:
>
> On Thu, Oct 24, 2019 at 12:46 PM Stephen Reay
> wrote:
>
> > This sounds like an alternative approach (for solving the same basic
> > problem) to the nullsafe operator discussed a while back, no?
>
> https://wiki.php.net/rfc/nullsafe_calls
>
On Fri, 25 Oct 2019 at 01:24, Sara Golemon wrote:
>
> On Thu, Oct 24, 2019 at 4:55 PM Ken Stanley wrote:
>
> > > isset($_SERVER['fname']) && $user->setName($_SERVER['fname']);
> > >
> > > Will return boolean.
> > >
> >
> > Just testing the waters: Is there any appetite to have AND and OR behave
On Thu, 24 Oct 2019 at 20:59, Ken Stanley wrote:
>
> On Thu, Oct 24, 2019 at 1:33 PM Dan Ackroyd wrote:
>
> > On Thu, 24 Oct 2019 at 18:21, Ken Stanley wrote:
> > >
> > > Since PHP 7.0 brought forward the Null Coalescing Operator (??), writing
> > > more succinct code for how to handle null
I agree with the distinction described by Nikita.
There are definitely cases where a special return value is still the
best option.
In addition I would say in some cases it can be useful to have both
versions available: One that returns FALSE or NULL, another that
throws an exception.
This is for
What about a new keyword in addition to "catch"?
(exact keyword would be up for discussion)
try {
}
catchExit ($exit) {
}
Or, how far would we get if we do not make this catchable, and
(perhaps) not run any "finally" block?
Could this already solve some of the technical problems, without
On Fri, 11 Oct 2019 at 12:25, Nikita Popov wrote:
>
> Hi internals,
>
> One thing that I feel gets lost when discussion is spread over multiple
> proposals is the following fact:
>
> Purely syntactical deprecations, such as the recently discussed case of
> backticks, but also the already accepted
I would think that whichever code currently calls exit() is already
expecting and accepting all the consequences, and assumes that this
won't ever be caught.
So, would it be an option to keep exit() as it is, and introduce a new
syntax construction?
Places where I have seen exit() were not
On Fri, 11 Oct 2019 at 10:18, Nikita Popov wrote:
>
> On Thu, Sep 12, 2019 at 2:17 PM Nikita Popov wrote:
>
> > Hi internals,
> >
> > I've opened the vote on //wiki.php.net/rfc/engine_warnings.
> >
> > There are 4 votes, all of them independent. The first 3 are for specific
> > cases that were
1 - 100 of 197 matches
Mail list logo
