On Mon, Mar 16, 2020, at 11:25 AM, Nicolas Grekas wrote:
> > > I repeat what I wrote before but all those problems would disappear if we
> > > were to bind the proposal to visibility:
> > > https://externals.io/message/108675#108753
> > >
> > > We could even consider splitting "read" and "write" in
> > I repeat what I wrote before but all those problems would disappear if we
> > were to bind the proposal to visibility:
> > https://externals.io/message/108675#108753
> >
> > We could even consider splitting "read" and "write" in two separate
> > keywords, each bound to visibility, isn't it?
>
>
On Mon, Mar 16, 2020, at 6:57 AM, Nicolas Grekas wrote:
> Le lun. 16 mars 2020 à 12:52, Máté Kocsis a écrit :
>
> > >
> > > The other one is the recently declined
> > > https://wiki.php.net/rfc/object-initializer. As it basically works by
> > > first
> > > creating the object normally (including
Le lun. 16 mars 2020 à 12:52, Máté Kocsis a écrit :
> >
> > The other one is the recently declined
> > https://wiki.php.net/rfc/object-initializer. As it basically works by
> > first
> > creating the object normally (including a possible constructor call), and
> > then assigning the specified pro
>
> The other one is the recently declined
> https://wiki.php.net/rfc/object-initializer. As it basically works by
> first
> creating the object normally (including a possible constructor call), and
> then assigning the specified properties, this would not be compatible with
> readonly properties t
On Mon, Mar 16, 2020 at 4:47 AM Rowan Tommins wrote:
> I'm sure different people will react differently, but my intuition is quite
> the opposite: I would probably call the inline assignment to the property
> an "initial value", not a "default value", and I would intuitively compare
> it to assign
On Mon, Mar 16, 2020 at 12:23 AM Larry Garfield
wrote:
> 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 pro
On Sun, 15 Mar 2020 at 21:41, Jakob Givoni wrote:
> 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, developer
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
>
> 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 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
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
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
Hey Máté,
Is the RFC still gonna allow default values (constants, at this point)?
While I don't see a major problem with it, it seems a bit weird...
On Sat, Mar 14, 2020, 12:00 Máté Kocsis wrote:
> Thank you, Larry, for your response! I share your opinion. However, I'd be
> curious if there is
Thank you, Larry, for your response! I share your opinion. However, I'd be
curious if there is anyone who doesn't?
As things currently stand, I plan to start the vote on Monday with an
unchanged proposal (+ an extended future scope section).
Máté
On Thu, Mar 12, 2020, at 8:57 AM, Máté Kocsis wrote:
> As you might noticed, I've not opened the vote yet. Partly because I was
> improving
> my implementation as well as the RFC itself (added some words about the
> inheritance
> implications), but the main reason is that a question arise in the
>
As you might noticed, I've not opened the vote yet. Partly because I was
improving
my implementation as well as the RFC itself (added some words about the
inheritance
implications), but the main reason is that a question arise in the
meanwhile.
Namely, "write-once" properties could in principle su
TL;DR; I plan to open the vote on Monday because the proposal feels complete
for me. Read more to find out why I think so.
Nicolas, do you have any specific use-case in mind that would require a
workaround
outlined in my previous email above the current possibilities (lazy
initialization,
unsettin
>
> I totally agree with this: there must be a way to work around the keyword -
> either via reflection or another means.
Via Reflection, it could be a new method `->setWritable(true)` (next to
> `->setAccessible(true)`).
>
I'm OK to support working around the keyword via reflection. Since my
imp
Le lun. 24 févr. 2020 à 21:35, Larry Garfield a
écrit :
> On Mon, Feb 24, 2020, at 7:55 AM, Rowan Tommins wrote:
> > On Fri, 21 Feb 2020 at 23:18, Larry Garfield
> wrote:
> >
> > > The with*() method style requires cloning the object. What happens to
> the
> > > locked status of a set property
Sorry, but I'd like to add a correction to my previous email.
After thinking about it, I realized that cloning is not that serious of a
problem in case of immutable objects, since it's also possible to create a
new instance instead of cloning. So it seems to be only a Developer
Experience concern
My original idea was to discuss cloning in connection with immutable
objects, - I think it's only a serious problem in that case - but we can
bring this discussion earlier of course, as readonly properties certainly
has some effect on the clonability of objects.
When I started working on implemen
On Mon, Feb 24, 2020, at 3:25 PM, Mike Schinkel wrote:
> > On Feb 23, 2020, at 12:06 PM, Larry Garfield wrote:
> >
> > On Sun, Feb 23, 2020, at 2:39 AM, Mike Schinkel wrote:
> >>> On Feb 21, 2020, at 6:17 PM, Larry Garfield
> >>> wrote:
> >>> I'm totally on board for better value object support
Mike Schinkel wrote:
On Feb 21, 2020, at 6:17 PM, Larry Garfield
wrote:
Separate visibility for internal and external access is a separate
matter. (Also potentially useful, but not part of the write-once
proposal at the moment.)
This just hit me, so I think I will mention it.
The culture
> On Feb 24, 2020, at 8:55 AM, Rowan Tommins wrote:
>
> As with typed properties, I wonder if there's a way we can introduce
Now you are talking! This gives me hope after my dejected last comment on the
list.
-Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe
> On Feb 23, 2020, at 12:06 PM, Larry Garfield wrote:
>
> On Sun, Feb 23, 2020, at 2:39 AM, Mike Schinkel wrote:
>>> On Feb 21, 2020, at 6:17 PM, Larry Garfield wrote:
>>> I'm totally on board for better value object support, so that's a good
>>> motive for me. The question I have is whether t
On Mon, Feb 24, 2020, at 7:55 AM, Rowan Tommins wrote:
> On Fri, 21 Feb 2020 at 23:18, Larry Garfield wrote:
>
> > The with*() method style requires cloning the object. What happens to the
> > locked status of a set property if the object is cloned? Are they then
> > settable again, or do they
On Fri, 21 Feb 2020 at 23:18, Larry Garfield wrote:
> The with*() method style requires cloning the object. What happens to the
> locked status of a set property if the object is cloned? Are they then
> settable again, or do they come pre-locked?
>
> Neither of those seem good, now that I think
On Mon, Feb 24, 2020, 09:19 Rowan Tommins wrote:
> On 24 February 2020 03:26:19 GMT+00:00, Marco Pivetta
> wrote:
> >The solution is trivial: don't use cloning:
> >
> >final class Foo
> >{
> >public function withBar($bar):self {
> >$instance = new self();
> >$instance->foo =
On 24 February 2020 03:26:19 GMT+00:00, Marco Pivetta
wrote:
>The solution is trivial: don't use cloning:
>
>final class Foo
>{
>public function withBar($bar):self {
>$instance = new self();
>$instance->foo = $foo;
>// more assignments here - unavoidable
>retur
Hey Larry,
On Sun, Feb 23, 2020, 18:06 Larry Garfield wrote:
>
> It does not.
>
> 1) Race condition if I assume that a public write-once property is a
> materialized value, but access it before it gets materialized.
>
This is alrey true for any public typed properties without default values,
On Sun, Feb 23, 2020, at 2:39 AM, Mike Schinkel wrote:
> > On Feb 21, 2020, at 6:17 PM, Larry Garfield wrote:
> > I'm totally on board for better value object support, so that's a good
> > motive for me. The question I have is whether this is really a good
> > stepping stone in that direction o
> On Feb 21, 2020, at 6:17 PM, Larry Garfield wrote:
> I'm totally on board for better value object support, so that's a good motive
> for me. The question I have is whether this is really a good stepping stone
> in that direction or if it would lead down a wrong path and lock us into too
> mu
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 itself
On Fri, Feb 21, 2020, at 4:29 AM, Máté Kocsis wrote:
> >
> > Yeah, I'm definitely thinking in relation to the earlier discussion, since
> > I think they're all inter-related. (This, property accessors, and constant
> > expressions.)
> >
>
> The biggest question is whether it's worth to support bo
>
> Of course, that does leave the question of how often you need one or the
> other. Maybe just the asymmetric visibility is sufficient for most
> practical purposes, in which case it may not be worthwhile to introduce
> readonly properties as a separate feature.
>
The examples shown in my previo
>
> Yeah, I'm definitely thinking in relation to the earlier discussion, since
> I think they're all inter-related. (This, property accessors, and constant
> expressions.)
>
The biggest question is whether it's worth to support both readonly
properties and property accessors. My answer is clear y
On Thu, Feb 20, 2020, at 3:06 AM, Nikita Popov wrote:
> On Thu, Feb 20, 2020 at 1:27 AM Matthew Brown
> wrote:
>
> > Someone recently requested something similar for a PHP static analysis tool
> > I wrote (https://psalm.dev/r/f75997a263), though that version only allows
> > lazy initialisation in
On Thu, Feb 20, 2020 at 1:27 AM Matthew Brown
wrote:
> Someone recently requested something similar for a PHP static analysis tool
> I wrote (https://psalm.dev/r/f75997a263), though that version only allows
> lazy initialisation inside the class in which a given property is declared.
>
> Personal
>
> I would expect that operating on one of these properties before it's
> initialized will throw an error:
>
Actually, the RFC only says that the "immutability" of properties is
guaranteed after initialization.
We could of course change this premise, but that would make some important
use-cases (
Someone recently requested something similar for a PHP static analysis tool
I wrote (https://psalm.dev/r/f75997a263), though that version only allows
lazy initialisation inside the class in which a given property is declared.
Personally I don't like either approach – I think per-property getters a
On Wed, Feb 19, 2020, at 1:36 PM, Marco Pivetta wrote:
> On Wed, Feb 19, 2020, 19:51 Larry Garfield wrote:
>
> > On Wed, Feb 19, 2020, at 11:05 AM, Máté Kocsis wrote:
> > > Hi Internals,
> > >
> > > I'd like to move my RFC forward to the discussion phase:
> > > https://wiki.php.net/rfc/write_once
On Wed, Feb 19, 2020, 19:51 Larry Garfield wrote:
> On Wed, Feb 19, 2020, at 11:05 AM, Máté Kocsis wrote:
> > Hi Internals,
> >
> > I'd like to move my RFC forward to the discussion phase:
> > https://wiki.php.net/rfc/write_once_properties
> >
> > In short, I propose to add support for a new prop
On Wed, Feb 19, 2020, at 11:05 AM, Máté Kocsis wrote:
> Hi Internals,
>
> I'd like to move my RFC forward to the discussion phase:
> https://wiki.php.net/rfc/write_once_properties
>
> In short, I propose to add support for a new property modifier that would
> allow properties to be initialized, b
Hey Mark,
Asking here as well, so that others are aware: is
`unset($this->aPropertyThatWasNotInitializedBefore)` still working with
this patch?
Also, are the semantics around `__get`, `__set` and `__isset` the same as
with typed properties?
In the RFC, you have `unset($foo->c)` as disallowed: th
Hi Internals,
I'd like to move my RFC forward to the discussion phase:
https://wiki.php.net/rfc/write_once_properties
In short, I propose to add support for a new property modifier that would
allow properties to be initialized, but not modified afterwards.
Cheers,
Máté Kocsis
47 matches
Mail list logo
