> On 11 Apr 2019, at 00:32, M. W. Moe wrote:
>
> I have never seen ML programmers being improductive;
Great. I’ve never seen a pig crash a plane, therefore all pilots should be pigs?
Given your previous comments regarding removing “java impurities” it’s hard to
take anything you suggest seri
On 10/04/2019 22:30, Benjamin Morel wrote:
Your arguments are perfectly valid and make sense, I guess this is a matter
of not viewing different semantics for explicit and implicit cast as
inconsistencies.
It's an interesting discussion and I appreciate you engaging on it.
I wonder, perhaps, if
On 10 April 2019 21:56:41 BST, "Björn Larsson"
wrote:
>Could then the \($x) syntax be a good compromise between
>readability & implementation?
Personally, I don't find it "more readable"; on the one hand, it's one
character shorter; on the other, it stands out less from everything else.
My per
deprecate short closing tag
wrote:
>
> Finally!!! everybody will be able to parse my xml files with embedded
> php1!1 if I ever wrote one!!!
>
> Sorry for the sarcasm, please don't consider this as a personal attack. The
> whole community (not just you) considers short open tags poison because
Finally!!! everybody will be able to parse my xml files with embedded
php1!1 if I ever wrote one!!!
Sorry for the sarcasm, please don't consider this as a personal attack. The
whole community (not just you) considers short open tags poison because not
XML-compatible... while they use stuff lik
> That's exactly what it is, and thanks to null coalescence, you then have
> an easy available ability to either check if it succeeded, or default to
> another value.
Your arguments are perfectly valid and make sense, I guess this is a matter
of not viewing different semantics for explicit and imp
Den 2019-04-10 kl. 10:39, skrev Rowan Collins:
On Tue, 9 Apr 2019 at 11:20, Nikita Popov wrote:
The ==> syntax is the other one I implemented (
https://github.com/php/php-src/pull/3945). The implementation is based on
lexer lookahead, which is ugly but still manageable. I haven't seen much
s
Den 2019-04-09 kl. 11:54, skrev Nikita Popov:
Hi internals,
Inspired by Bob's recent RFC for concat precedence, I'd like to propose a
deprecation and removal of the left-associative behavior of ternaries.
Instead, explicit parentheses should be used:
https://wiki.php.net/rfc/ternary_associativi
> Le 10 avr. 2019 à 21:21, Stanislav Malyshev a écrit :
>
> Hi!
>
>> Inspired by Bob's recent RFC for concat precedence, I'd like to propose a
>> deprecation and removal of the left-associative behavior of ternaries.
>> Instead, explicit parentheses should be used:
>>
>> https://wiki.php.net
On Wed, Apr 10, 2019 at 1:22 PM Stanislav Malyshev wrote:
>
> Hi!
>
> > Inspired by Bob's recent RFC for concat precedence, I'd like to propose a
> > deprecation and removal of the left-associative behavior of ternaries.
> > Instead, explicit parentheses should be used:
> >
> > https://wiki.php.ne
Nikita Popov schrieb am Di., 9. Apr. 2019, 11:54:
> Hi internals,
>
> Inspired by Bob's recent RFC for concat precedence, I'd like to propose a
> deprecation and removal of the left-associative behavior of ternaries.
> Instead, explicit parentheses should be used:
>
> https://wiki.php.net/rfc/ter
Hi!
> Inspired by Bob's recent RFC for concat precedence, I'd like to propose a
> deprecation and removal of the left-associative behavior of ternaries.
> Instead, explicit parentheses should be used:
>
> https://wiki.php.net/rfc/ternary_associativity
Please, let's not mess with language syntax
On 10/04/2019 18:34, Benjamin Morel wrote:
So why would you have different semantics for implicit `(?int)` cast vs `:
?int` function return type cast, if they're both *out*?
Return type cast has the same semantics as parameter type cast.
I would have to disagree with this as I think of "return"
> Function arguments specify what goes *in* to a function, whereas casts
> and return types specify what comes *out* of the function.
So why would you have different semantics for implicit `(?int)` cast vs `:
?int` function return type cast, if they're both *out*?
Return type cast has the same sem
@Stephen Reay,
I have never seen ML programmers being improductive; that's because maybe
you witness people
unfit for it; math is less character and contextual i.e meanings change
according to environment;
it's fully readable to people fitted for it.
On Wed, Apr 10, 2019 at 10:18 AM M. W. Moe w
Hello,
this is not much the syntax which is problematic here but the implicit
lambda capture ruleset proposed; for that,
it would require (fully justified in this case) a preprocessing step hence
a language contextual analysis step
or what people call `static`.
On Wed, Apr 10, 2019 at 2:35 AM Ste
On 10/04/2019 17:15, Benjamin Morel wrote:
No offense, but how can casting semantics different from those already used
in implicit casting be intuitive?
As is implied from the name, an implicit cast is done because the code
needs it to, not because it has been told to by the caller. It is
nat
>
> I believe returning null in those situations makes the most intuative
> sense, yes.
No offense, but how can casting semantics different from those already used
in implicit casting be intuitive?
function a(int $x) { var_export($x); }
function b(?int $x) { var_export($x); }
a("12
On 10/04/2019 16:16, Guilliam Xavier wrote:
var_dump((?int) $obj); // would you want it to print `NULL`?
var_dump((?string) $obj); // would you want it to print `NULL`?
I believe returning null in those situations makes the most intuative
sense, yes.
> var_dump((int) $obj); // Notice, then p
On Wed, April 10, 2019 at 10:06 AM Gabriel O wrote:
> On 10 April 2019 4:48:38 PM Theodore Brown wrote:
> >
> > I for one would welcome consistent fatal errors for LSP violations,
> > to catch these kind of bugs as early as possible during development.
>
> Once again, nowadays warnings are conve
On Wed, Apr 10, 2019 at 4:34 PM Mark Randall wrote:
>
> (Continuing from my previous post in a different thread...)
>
> IMHO a cast such as ([?]type) would be better described as passing a
> mixed value through a function which has a return type of whatever is in
> the cast... the mechanics of tha
On Tue, Apr 9, 2019 at 11:05 AM Gabriel O wrote:
>> On 9. Apr 2019, at 17:35, Levi Morrison wrote:
>>
>> If you want the reverse to be true, then your code has bugs waiting to
>> show themselves. The earlier we can catch these bugs, the better.
>>
>> One thing to note is that return type informa
On Wed, Apr 10, 2019 at 12:52 PM Nikita Popov wrote:
>
> I'm a bit concerned that there are two possible semantics for what (?int)
> does:
>
> 1. What I would intuitively expect: A fallible integer cast. I.e. try to
> cast to integer and if not possible return null. So (?int) "foobar" becomes
> n
On 10/04/2019 13:03, Benjamin Morel wrote:
There is only one, if we align the semantics of explicit and implicit
casting: you wouldn't expect this:
function test(?int $bar) { var_export($bar); }
test("abc");
...to output 'null'?
(Continuing from my previous post in a different threa
> We could add support for this, but as the general consensus is that we'd
much rather remove support for unsetting declared object properties (if we
could cover the lazy loading use case in a different way), I don't think it
makes sense to allow this.
Ok, thanks. Just wanted to double check.
Not
On Wed, Apr 10, 2019 at 2:20 PM Benjamin Morel
wrote:
> Hi internals,
>
> I came across this when playing with static properties:
>
> class A {
> public static int $x;
> }
>
> // This throws, as expected:
> // Error: Typed static property A::$x must not be accessed before
Hi internals,
I came across this when playing with static properties:
class A {
public static int $x;
}
// This throws, as expected:
// Error: Typed static property A::$x must not be accessed before
initialization
echo A::$x;
// Once we initialize the property:
>
> I'm a bit concerned that there are two possible semantics for what (?int)
> does:
There is only one, if we align the semantics of explicit and implicit
casting: you wouldn't expect this:
function test(?int $bar) { var_export($bar); }
test("abc");
...to output 'null'?
--
Ben
On Sat, Apr 6, 2019 at 9:53 AM Guilliam Xavier
wrote:
> Hello internals,
>
> David and I would like to open the discussion on our joint RFC:
>
> https://wiki.php.net/rfc/nullable-casting
>
> Mainly, it would enable to use e.g. `(?int)$x` besides `(int)$x`.
>
> We are looking forward to your feedb
Hello Internals,
As there have been no further comments the voting for my RFC [1] to
deprecate PHP's
short open tags has started and will run for two (2) weeks.
Best regards
George P. Banyard
[1] https://wiki.php.net/rfc/deprecate_php_short_tags
>
> I'm somewhat split on this one.
> On the one hand, if I make an explicit cast, my intention is clear, make
> the best attempt to convert this string into a number. Trimming
> whitespace would be a natural consequence of that.
> On the other hand, I'm a stickler for consistency.
> On the balance
> On the balance of things, I would most certainly like to see leading and
> trailing whitespace render a string ineligible to be implicitly
> converted, but I'd be satisfied with (int)" 123 " converting without error.
>
Given that PHP seems to be gradually moving towards more type
strictness, wou
> On 10 Apr 2019, at 15:59, Robert Hickman wrote:
>
>> I'd just like to amplify this mention of 3rd party tooling: if we go with
>> something which requires complex lexer/parser rules, then every editor,
>> IDE, and static analysis tool will need to also work with that syntax.
>>
>
> Is this
I think that the RFC covers a great deal of possible syntaxes and their
tradeoffs.
`==>` requires *a lot* of changes to the current parser, and external
tooling as mentioned by Rowan.
It has not even been specified whether the `==>` syntax could land into PHP
7.4, or could require postponing to P
On Wed, 10 Apr 2019 at 09:59, Robert Hickman wrote:
> > I'd just like to amplify this mention of 3rd party tooling: if we go with
> > something which requires complex lexer/parser rules, then every editor,
> > IDE, and static analysis tool will need to also work with that syntax.
> >
>
> Is this
Hi, Gabriel,
On 10.04.19 10:33, Gabriel O wrote:
Those parentheses are important when having multiple argument
Please don't top post, thanks!
Thanks for pointing it out, I'm aware.
Still `===>` would better stand out to _me_ personally.
thanks,
- Markus
--
PHP Internals - PHP Runtime Devel
> I'd just like to amplify this mention of 3rd party tooling: if we go with
> something which requires complex lexer/parser rules, then every editor,
> IDE, and static analysis tool will need to also work with that syntax.
>
Is this actually a problem? Don't these tools make use of existing
parser
On Tue, 9 Apr 2019 at 11:20, Nikita Popov wrote:
> The ==> syntax is the other one I implemented (
> https://github.com/php/php-src/pull/3945). The implementation is based on
> lexer lookahead, which is ugly but still manageable. I haven't seen much
> support for this variant in this discussion t
Those parentheses are important when having multiple argument
On 10 April 2019 10:02:46 AM Markus Fischer wrote:
On 10.04.19 00:10, Robert Hickman wrote:
- $waithandles = $this->urls->map(fn($url) => $this->fetcher->fetch($url));
- $waithandles = $this->urls->map(\($url) => $this->fetcher->fe
On 09/04/2019 14:27, Robert Hickman wrote:
Why? Wouldn't it be nice to align the behaviour of implicit and explicit
casting, so that (int) "abc" throws a TypeError?
I'm somewhat split on this one.
On the one hand, if I make an explicit cast, my intention is clear, make
the best attempt to con
On 10.04.19 00:10, Robert Hickman wrote:
- $waithandles = $this->urls->map(fn($url) => $this->fetcher->fetch($url));
- $waithandles = $this->urls->map(\($url) => $this->fetcher->fetch($url));
- $waithandles = $this->urls->map($url ==> $this->fetcher->fetch($url));
I would say that when lambda fu
41 matches
Mail list logo
