and maybe one day if public, protected, private, interface, abstract i.e
java impurities are finally removed:
class bar
{
owned var $m_a : float = 0.0;
var $b : object = null;
fn foo(int $x, int $y) : int
{ return fn($x) [&$y] { $x * $y; }; }
owned fn bar() : void
{ retur
Hello,
for now what I see is a bit of everything:
- adding a contextual keyword/alias to function
- enforce by reference
- a lack of coherence
too mockups (I like the arrow idea but won't ever replace `use`
functionalities)
"keeping the unnecessary arrow"
class bar
{
public fn foo(int $x, i
Hi internals,
This is my first write to this list but I've been followed
your discussions quite a while ago. For a brief introduction,
my name is Kosit, I'm a programmer from Thailand and I've been using
PHP since version 3 (for a short period before moving to PHP4).
I'm a fan of `fn` syntax and
> - $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 functions occurs in function calls I
Den 2019-04-09 kl. 17:23, skrev Björn Larsson:
Den 2019-04-09 kl. 12:19, skrev Nikita Popov:
On Tue, Apr 9, 2019 at 8:56 AM Björn Larsson
wrote:
Den 2019-04-08 kl. 16:06, skrev Nikita Popov:
On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov
wrote:
Hi internals,
Motivated by the recent list c
Hi Kalle,
You forgot to move to voting on the RFC index.
Cheers
Joe
On Tue, 9 Apr 2019, 19:07 Kalle Sommer Nielsen, wrote:
> Den tir. 9. apr. 2019 kl. 20.02 skrev Kalle Sommer Nielsen >:
> >
> > Evening Internals
> >
> > Apologies for the one day delay, but the voting for the RFC "Unbundle
>
Den tir. 9. apr. 2019 kl. 20.02 skrev Kalle Sommer Nielsen :
>
> Evening Internals
>
> Apologies for the one day delay, but the voting for the RFC "Unbundle
> ext/interbase" is open[1]. There is only one voting choice, which
> decides if the extension should be moved to PECL.
>
> Since this started
Evening Internals
Apologies for the one day delay, but the voting for the RFC "Unbundle
ext/interbase" is open[1]. There is only one voting choice, which
decides if the extension should be moved to PECL.
Since this started a day later than anticipated, then the voting will
naturally run for one e
> If you want the reverse to be true, then your code has bugs waiting to
> show themselves
I don’t, I just don’t want fatal errors in production when I upgrade library I
extend. Let me keep logging such issues and fix them later, instead of
producing hard crash for customers.
> The earlier
On Tue, Apr 9, 2019 at 9:00 AM Gabriel O wrote:
>
> I believe rfc deals with reverse situation
>
> On 9 April 2019 4:47:50 PM Dan Ackroyd wrote:
>
> > On Tue, 9 Apr 2019 at 11:58, Gabriel O wrote:
> >
> >> And this RFC conveniently shows only big LSP violation examples like array
> >> -> int, bu
Den 2019-04-09 kl. 12:19, skrev Nikita Popov:
On Tue, Apr 9, 2019 at 8:56 AM Björn Larsson
wrote:
Den 2019-04-08 kl. 16:06, skrev Nikita Popov:
On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov
wrote:
Hi internals,
Motivated by the recent list comprehensions RFC, I think it's time we
took
a
I believe rfc deals with reverse situation
On 9 April 2019 4:47:50 PM Dan Ackroyd wrote:
On Tue, 9 Apr 2019 at 11:58, Gabriel O wrote:
And this RFC conveniently shows only big LSP violation examples like array
-> int, but not widely used narrowing like mixed/object -> specific instance.
On Tue, 9 Apr 2019 at 11:58, Gabriel O wrote:
> And this RFC conveniently shows only big LSP violation examples like array ->
> int, but not widely used narrowing like mixed/object -> specific instance.
Type narrowing or contravariant parameters is properly supported for
PHP 7.4: https://wiki.
Le vendredi 5 avril 2019, 11:00:59 CEST Michał Brzuchalski a écrit :
> So we're talking about providing incomplete feature now, right?
As I understand it, the point is to make unpacking available to arrays, to be
consistent with function calls.
// This is already supported
$result = someFunction
On Tue, 9 Apr 2019 at 11:19, Bishop Bettini wrote:
> See also Bug 61915[1], which suggests leaving ? left and introducing ?? for
> right. Personally I don't see any benefit to keeping a ternary with left
> associativity.
>
?? wouldn't work, because that's now the null-coalescing operator. (I've
> Why? Wouldn't it be nice to align the behaviour of implicit and explicit
> casting, so that (int) "abc" throws a TypeError?
>
I agree with this. It would be odd if they behaved differently.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.
>
> I should probably clarify what I mean by explicit and implicit here. By
> explicit I mean anything using (int) casts or doing so internally
> (implicitly ^^) -- this *must* produce an integer in some way and does not
> have the option of rejecting the input. By implicit I mean other places
> ch
Hello, I am interested to know if this affects behaviour of following code:
putenv($this->colSize ? 'COLUMNS' : 'COLUMNS='.$this->colSize);
> On 9. Apr 2019, at 11:54, Nikita Popov wrote:
>
> Hi internals,
>
> Inspired by Bob's recent RFC for concat precedence, I'd like to propose a
> deprecat
On Tue, 9 Apr 2019, Nikita Popov wrote:
> On Tue, Apr 9, 2019 at 12:57 PM Derick Rethans wrote:
>
> > > think about the desired behavior of (int)?
> >
> > I think there should be no difference in behaviour between implicit and
> > explicit cases.
>
> So to rephrase my question: While I think th
On Tue, Apr 9, 2019 at 12:57 PM Derick Rethans wrote:
> On Tue, 9 Apr 2019, Nikita Popov wrote:
>
> > On Thu, Apr 4, 2019 at 1:16 AM Andrea Faulds wrote:
> >
> > > I'm kinda unsure how to go forward because of these points. I would
> like
> > > to see improved comparisons, and I would like to se
I see you are trying to solve inconsistency, but i would do it opposite way.
LSP errors should be warnings, they are not show stopper errors. It’s very much
possible code violating LSP keeps working correctly. And in modern PHP
development, everybody considers warnings as show stoppers anyway, s
On Tue, 9 Apr 2019, Nikita Popov wrote:
> On Thu, Apr 4, 2019 at 1:16 AM Andrea Faulds wrote:
>
> > I'm kinda unsure how to go forward because of these points. I would like
> > to see improved comparisons, and I would like to see the end of the
> > “non-well-formed” numeric string, and I think t
On Thu, Apr 4, 2019 at 1:16 AM Andrea Faulds wrote:
> Nikita Popov wrote:
> > I'm always a fan of making things stricter, but think that in this
> > particular case there are some additional considerations we should keep
> in
> > mind.
> >
> > 1. What is more important to me here than strictness
On Tue, 9 Apr 2019 at 10:54, Nikita Popov wrote:
> 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/tern
On Tue, Apr 9, 2019 at 8:56 AM Björn Larsson
wrote:
> Den 2019-04-08 kl. 16:06, skrev Nikita Popov:
>
> > On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov
> wrote:
> >
> >> Hi internals,
> >>
> >> Motivated by the recent list comprehensions RFC, I think it's time we
> took
> >> another look at short
On Tue, Apr 9, 2019 at 5:54 AM Nikita Popov wrote:
>
> 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_associativ
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_associativity
This RFC makes nested ternaries without disa
On Tue, Apr 9, 2019 at 4:25 AM Nikita Popov wrote:
> Hi internals,
>
> A small cleanup RFC for PHP 8: https://wiki.php.net/rfc/lsp_errors
>
> This makes all incompatible method signature (LSP) errors fatal, rather
> than only warning in some cases. Especially after
> https://wiki.php.net/rfc/para
Hello Internals,
Slightly later than expected but I will put the RFC to voting tomorrow if
no other discussion arises.
Also did some slight improvement to the RFC by adding a link to
PHP-CS-FIXER which can automatically
convert PHP's short open tags to the standard one and also added a Feedback
s
> On 5 Apr 2019, at 21:29, Larry Garfield wrote:
>
> On Thu, Apr 4, 2019, at 10:46 PM, Stephen Reay wrote:
>
>>> Discussion:
>>>
>>> For me, the inability to work with arrays is the big problem with the
>>> second approach. I very very often am type declaring my returns and
>>> parameters
On 09/04/2019 08:32, Guilliam Xavier wrote:
I do kind of like the idea in the RFC, but I think it needs a better
argument for it.
For your other points, I find that Claude Pache has given pretty good
arguments in the meantime (thanks!) =) (By the way, I also thought
about say, "nullable_intval()
Hi internals,
A small cleanup RFC for PHP 8: https://wiki.php.net/rfc/lsp_errors
This makes all incompatible method signature (LSP) errors fatal, rather
than only warning in some cases. Especially after
https://wiki.php.net/rfc/parameter-no-type-variance I don't think there's
any reason to keep t
Dan Ackroyd wrote:
>
> I'm guessing you don't actually have ths function getIntOrNull() in
> your code-base? To help me understand where this would be useful,
> could you provide some 'real-world' code where this would be useful?
Hello, thanks for digging in :)
Here's a "real-world" situation I
33 matches
Mail list logo
