> On Mar 15, 2020, at 7:42 PM, tyson andre wrote:
>
> Hi Mike,
>
>> What I am about to say is ironic since I too often feel people are trying to
>> enforce their view of coding on the world,
>> but I do not think we want to give people tools to make it easier to work
>> with long functions/scr
Hi!
> As it's arisen on the list again, I've written a note detailing my
> view of the previous discussion:
>
> https://github.com/Danack/RfcCodex/blob/master/explicit_defaults.md
As the author of that RFC, I am not particularly sure how it can be
"improved", as main argument from what I underst
Hi Mike,
> What I am about to say is ironic since I too often feel people are trying to
> enforce their view of coding on the world,
> but I do not think we want to give people tools to make it easier to work
> with long functions/scripts.
Blocked-scoped variables is a tool which can make short
On Sun, Mar 15, 2020, at 4:44 PM, Máté Kocsis wrote:
> >
> > Avoiding that confusion will save the industry millions of dollars.
> >
>
> On the one hand, you are right, because currently it's not very useful to
> effectively provide two
> ways of declaring a constant. On the other hand however, if
Hi Rowan,
> Do you know how the equivalent code works with function-scoped variables?
> As far as I can see, returning from a function will successfully call multiple
> destructors even if one of them throws an exception. Could exiting block
> scope use that same algorithm?
PHP literally frees al
>
> Avoiding that confusion will save the industry millions of dollars.
>
On the one hand, you are right, because currently it's not very useful to
effectively provide two
ways of declaring a constant. On the other hand however, if we also
consider a longer term
aim of adding support for object de
> On Mar 15, 2020, at 2:53 PM, tyson andre wrote:
>
> Hi Mike,
>
>> What I would rather see are new features in PHP that encourage developer
>> to break functionality into shorter and simpler functions and methods, and
>> to minimize nesting.
>
> I would also like to see shorter functions in g
On Sun, Mar 15, 2020, at 8:48 AM, Marco Pivetta wrote:
> I think what will happen is that people will start requesting for read-only
> properties with default values to be over-writable-once
Exactly, I think that intuitively, developers will not see a default
value as an actual "write".
They will
Tyson Andre wrote:
Hi internals,
In PHP, variables are currently scoped to the function scope, and
can't be scoped to a block scope. This makes it difficult to reason
about how a variable will actually be used at a glance, especially in
long functions, or top-level statement lists of a file.
(
On 15/03/2020 18:17, tyson andre wrote:
If this feature freed variables when going out of scope,
it would be compiled more like the following (if there were multiple lets):
JavaScript doesn't have destructors, but PHP does, which makes the
implementation a tiny bit more complex.
```
try {
Hi Mike,
> What I would rather see are new features in PHP that encourage developer
> to break functionality into shorter and simpler functions and methods, and to
> minimize nesting.
I would also like to see shorter functions in general, but:
- Other developers may prefer long functions/script
On Sun, Mar 15, 2020, at 1:28 PM, Mike Schinkel wrote:
> More specifically regarding PHP, the purpose of your proposed feature
> appears to be to allow longer and more complex functions and
> methods and more deep nesting. However, I think we should not be
> encouraging people to write lo
On Sun, Mar 15, 2020, at 8:48 AM, Marco Pivetta wrote:
> Hey Máté,
>
> On Sun, Mar 15, 2020, 14:04 Máté Kocsis wrote:
>
> > Hi Marco,
> >
> > Yes, it still allows default values.
> >
> > The reason why I'm reluctant to disallow them is that this restriction
> > would feel a bit ad-hoc for me. I
Hi Tyson,
Normally I would be one to advocate for new features, but in the case I am
against the proposed feature.
I know it is a feature from Javascript, but I think it is maybe the nature of
Javascript prototypes makes it more useful though I am not sure as I do no
> Intuitively, I would expect this:
>
> {
> let $x = new Foo;
> $x->bar();
> }
> somethingElse();
>
> to be equivalent to this:
>
> let $x = new Foo;
> $x->bar();
> unset($x);
> somethingElse();
If this feature freed variables when going out of scope,
it would be compiled more like the f
Hi Tyson,
I think this is an interesting idea, but the way you describe it does
seem to introduce a lot of caveats and additional restrictions.
For instance, this feels very odd to me:
Correctness would be enforced as a best-effort at compile-time - the variables
would continue to only be f
> What you are suggesting is that a let statement would switch PHP to an
>altogether different mode where function-scoped and explicit global variables
>were suddenly disallowed and an error within that function (or only after the
>let?).
No, the variables with the *same name* as the variables
Am 15.03.2020 um 17:47 schrieb tyson andre :
> {
> let $myObject = new MyClass(), $flag = true;
> $myObject->process($flag);
> }
> // Accessing or setting $myObject or $flag outside a different let is an
> E_COMPILE_ERROR
> // because it was declared anywhere else in the function body
> // as
En mié, 11 mar 2020 11:09:13 +0100 Nikita Popov
escribió
> On Fri, Oct 11, 2019 at 4:11 PM Nikita Popov wrote:
>
> > On Fri, Oct 11, 2019 at 3:47 PM Marcio Almada
> > wrote:
> >
> >> Em sex, 11 de out de 2019 às 08:05, Nikita Popov
> >> escreveu:
> >> >
> >> > Hi,
>
Hi internals,
In PHP, variables are currently scoped to the function scope, and can't be
scoped to a block scope. This makes it difficult to reason about how a variable
will actually be used at a glance, especially in long functions, or top-level
statement lists of a file.
(or how the variable
On Sat, 14 Mar 2020 at 15:27, David Rodrigues wrote:
>
> I would like to propose the idea of having a keyword that can be used to
> use the default value of a parameter,
As it's arisen on the list again, I've written a note detailing my
view of the previous discussion:
https://github.com/Danack/
>
> On Sat, 14 Mar 2020 at 15:53, Christoph M. Becker
> wrote:
>
>> On 14.03.2020 at 16:27, David Rodrigues wrote:
>>
>> > I would like to propose the idea of having a keyword that can be used to
>> > use the default value of a parameter, without necessarily having to know
>> > it.
>>
>> FWIW, thi
Hey Máté,
On Sun, Mar 15, 2020, 14:04 Máté Kocsis wrote:
> Hi Marco,
>
> Yes, it still allows default values.
>
> The reason why I'm reluctant to disallow them is that this restriction
> would feel a bit ad-hoc for me. I mean, I wouldn't like to add another
> special rule for "write-once" proper
Hi Marco,
Yes, it still allows default values.
The reason why I'm reluctant to disallow them is that this restriction
would feel a bit ad-hoc for me. I mean, I wouldn't like to add another
special rule for "write-once" properties, unless there is a strong
argument for it. Besides, as far as I kno
24 matches
Mail list logo