Hi!
> - The individual symbolic operators, with no intrinsic meaning - e.g.
> overloading . for concatenation on strings but dot-product for
> vectors; or a DSL overloading << and >> for "into" and "out of".
Please no. I know it looks fancy and some languages love it, but for a
person not in on t
On 15 February 2020 22:05:52 GMT+00:00, jan.h.boeh...@gmx.de wrote:
>Some discussion points, I can think of, would be the naming of the
>methods
>(maybe naming them after the operator symbol and not the arithmetical
>operation they represent, e.g. __plus instead of __add) or putting the
>methods in
On 15 February 2020 20:10:30 GMT+00:00, "Paul M. Jones"
wrote:
>Hi all,
>
>> On Feb 15, 2020, at 02:01, Larry Garfield
>wrote:
>>
>> ... is this proposal intended to supplant HttpFoundation and PSR-7
>... ?
>
>This is question is answered in the RFC introduction
You've cut Larry's question in
On 15/02/2020 22:05, jan.h.boeh...@gmx.de wrote:
Hi internals,
What do you think about the RFC?
"If an operator is used with an object that does not overload this
operator, an NOTICE is triggered, which gives the user a hint about the
method that has to be overloaded. For backward compatibili
On 15-02-2020 13:07, Manuel Canga wrote:
> Do you think it is worth creating an RFC page about :: function ? I say that
> because I see that there are many voices against of :: function
Let us go back to the start of this thread. Your idea was to simplify
array_map('\My\I18N\i18n_translate'
On 11-02-2020 16:27, Levi Morrison via internals wrote:
> I have three immediate thoughts:
>
> 1. It should be `fn` or `function`; reserving a new word even if it's
> contextual is pointless here.
Note that even though these do not introduce a new keyword it does mean
that either of these would n
On 11-02-2020 12:13, Manuel Canga wrote:
> My proposal is ":func" in order to avoid full namespace in callback of
> functions. E.g:
>
> use function \My\I18N\i18n_translate;
>
> $mapped_array = array_map(i18n_translate::func, $array);
Something that did not occur to me before: Seeing the scope r
Hi internals,
based on the discussions here (https://externals.io/message/108300) and here
(https://github.com/php/php-src/pull/5156), I have created a proper RFC for
userspace operator overloading:
https://wiki.php.net/rfc/userspace_operator_overloading
The main differences to my original concep
Hi all,
> On Feb 15, 2020, at 02:01, Larry Garfield wrote:
>
> ... is this proposal intended to supplant HttpFoundation and PSR-7 ... ?
This is question is answered in the RFC introduction; quoting from there:
The SQLite “about” page says, “Think of SQLite not as a replacement
for Orac
On 15/02/2020 18:21, Mark Randall wrote:
I'm not so sure...
That incrementing a null works at all is a painful part of the
language spec that I would argue needs flushing down the toilet,
rather than further reinforcing.
The problem then is, where do you stop? There are dozens of places wh
On 15/02/2020 18:11, tyson andre wrote:
My opinion is that it'd be more consistent for `--` to work like `-= 1` (e.g.
become `-1`).
It might break some code, but that code was probably incorrect.
Yep, this is precisely the way I see it.
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internal
On 15/02/2020 17:44, Rowan Tommins wrote:
There is currently an odd inconsistency when using the decrement
operator on a null variable:
I'm not so sure...
That incrementing a null works at all is a painful part of the language
spec that I would argue needs flushing down the toilet, rather tha
My opinion is that it'd be more consistent for `--` to work like `-= 1` (e.g.
become `-1`).
It might break some code, but that code was probably incorrect.
Out of scope of the proposed RFC, but this reminds me of a similar issue:
Currently, the `++` and `--` operators do nothing to arrays or obje
Hi all,
There is currently an odd inconsistency when using the decrement
operator on a null variable:
$a = null; $a=$a+1; // int(1)
$a = null; $a+=1; // int(1)
$a = null; ++$a; // int(1)
$a = null; $a=$a-1; // int(-1)
$a = null; $a-=1; // int(-1)
$a = null; --$a; // null
I would like to prop
On Sat, Feb 15, 2020, at 6:07 AM, Manuel Canga wrote:
>
> En sáb, 15 feb 2020 09:22:41 +0100 Larry Garfield
> escribió
> > On Fri, Feb 14, 2020, at 1:04 AM, Manuel Canga wrote:
> >
> > > Maybe, bettern fn: * fn(callable $to_clsoure ): *closure ?
> > >
> > > I know fn is used i
On Fri, Feb 14, 2020 at 7:30 PM Rowan Tommins
wrote:
> On Fri, 14 Feb 2020 at 16:33, Nikita Popov wrote:
>
> > This constructor will initialize the corresponding properties. Now, the
> > behavior that would make most sense to me (if extension of the class is
> > allowed) is that MyPhpToken::getA
On Sat, Feb 15, 2020 at 3:33 PM Mark Randall wrote:
> Greetings,
>
> I offer a short RFC to add a new function, get_debug_type, which would
> return the type name of a variable, automatically resolving the class
> name in the event of it being an object.
>
> Unlike gettype, this function will ret
Hi Rowan,
I'm also on the opinion that making the mixed type the (implicit) default
is not a good idea.
However, I believe the uninitialized state is useful, what's more, it was
unavoidable
in order to properly support non-nullable object properties. But I don't
want to make
a case for this decis
Greetings,
I offer a short RFC to add a new function, get_debug_type, which would
return the type name of a variable, automatically resolving the class
name in the event of it being an object.
Unlike gettype, this function will return the true name of scalar
types, rather than their aliases, thus
Hi Larry,
I admit that this flag is not too interesting, but I believe it still has
its own merit. I can imagine that the flag could play well with property
accessors as well, however,
in my opinion, the main use-case of final properties generally doesn't
involve setters/set accessors.
> In that
En sáb, 15 feb 2020 09:22:41 +0100 Larry Garfield
escribió
> On Fri, Feb 14, 2020, at 1:04 AM, Manuel Canga wrote:
>
> > Maybe, bettern fn: * fn(callable $to_clsoure ): *closure ?
> >
> > I know fn is used in arrow functions. However, for that same reason fn is
> > the most
En sáb, 15 feb 2020 09:22:41 +0100 Larry Garfield
escribió
> On Fri, Feb 14, 2020, at 1:04 AM, Manuel Canga wrote:
>
> > Maybe, bettern fn: * fn(callable $to_clsoure ): *closure ?
> >
> > I know fn is used in arrow functions. However, for that same reason fn is
> > the most co
On Fri, Feb 14, 2020, at 1:04 AM, Manuel Canga wrote:
> Maybe, bettern fn: * fn(callable $to_clsoure ): *closure ?
>
> I know fn is used in arrow functions. However, for that same reason fn is
> the most convenient.
>
> Using dik examples( by the way, they are brilliant ):
Point of order: The
On Fri, Feb 14, 2020, at 7:22 AM, Máté Kocsis wrote:
> Hi Internals,
>
> I'd like to propose the idea of adding support for immutable/final/readonly
> properties in PHP 8.
>
> My plan is to add a new immutable/final/readonly (the name is up for
> debate) property modifier to the language so that
On Fri, Feb 14, 2020, at 10:47 AM, Benjamin Morel wrote:
> >
> > What about $query and $body? That would be closer to the terminology
> > used in HTTP RFCs.
>
>
>
> The problem is that $body is typically used to get the raw message body as
> a string or stream.
> I was thinking more something al
25 matches
Mail list logo
