>
> >> 2. DateInterval->days
> >>
> >> $interval = (new DateTime())->diff(new DateTime());
> >> var_dump($interval->days); // 0
> >> $refl = (new ReflectionObject($interval))->getProperty('days');
> >> var_dump($refl->isReadOnly()); // false
> >> var_dump($refl->isPublic()); // true
> >> $interval-
On 8/13/21 4:56 PM, Nikita Popov wrote:
On Thu, Aug 12, 2021 at 9:16 PM Marc wrote:
Hi,
As 8.1 adds readonly properties I wonder which build-in properties
should be defined readonly.
Currently I could find build-in readonly properties only on PDO and DOM.
Very incomplete list where reado
On Thu, Aug 12, 2021 at 9:16 PM Marc wrote:
> Hi,
>
> As 8.1 adds readonly properties I wonder which build-in properties
> should be defined readonly.
>
> Currently I could find build-in readonly properties only on PDO and DOM.
>
>
> Very incomplete list where readonly properties could make sense
I don't think the way it is going to be realeased is elegant solution
On Sat, Jul 17, 2021, 2:47 PM Andreas Leathley wrote:
> On 16.07.21 09:06, Nikita Popov wrote:
> > We cannot make properties readonly by default, because that would be a
> > major backwards compatibility break.
> >
> > If you'
On 16.07.21 09:06, Nikita Popov wrote:
We cannot make properties readonly by default, because that would be a
major backwards compatibility break.
If you're going for brevity, something you can do is omit the visibility
specifier, as it is public by default. "readonly int $prop" works.
Would i
> On Jul 17, 2021, at 1:40 AM, Eugene Sidelnyk wrote:
>
> > Having a "readonly" class where the properties are read-only by default
> > makes sense to me, but maybe the better way to do it is with an attribute?
>
> We already have such an attribute provided. It is called
> [`#[Immutable]`](htt
> Please don't top post. This is a bottom-post-centric list.
Can you please tell me what mailing client you use and what should I?
> if we were designing the language today we would do it very differently.
This reminds me working with legacy code in the team which says to write
the code in the
> Having a "readonly" class where the properties are read-only by default
makes sense to me, but maybe the better way to do it is with an attribute?
We already have such an attribute provided. It is called [`#[Immutable]`](
https://blog.jetbrains.com/phpstorm/2020/10/phpstorm-2020-3-eap-4/#immutab
> On Jul 16, 2021, at 6:12 AM, Bruce Weirdan wrote:
>
> On Fri, Jul 16, 2021 at 9:45 AM Eugene Sidelnyk wrote:
>
>> Readonly properties are really useful for DDD, where everything is going to
>> be immutable. It promotes best practices. However for people to use it,
>> syntax should be concise
On Fri, Jul 16, 2021, at 6:48 AM, Eugene Sidelnyk wrote:
> @Nikita Popov I'm not sure what you mean by saying
> this:
>
> > We're always explicit at the declaration site, it's const FOO, function
> foo, class Foo etc
>
>
> Regarding your message
>
> > Here mutability is decided by single $ ch
@Nikita Popov I'm not sure what you mean by saying
this:
> We're always explicit at the declaration site, it's const FOO, function
foo, class Foo etc
Regarding your message
> Here mutability is decided by single $ character in the declaration,
which doesn't have a particular obvious connectio
On Fri, Jul 16, 2021 at 9:45 AM Eugene Sidelnyk wrote:
> Readonly properties are really useful for DDD, where everything is going to
> be immutable. It promotes best practices. However for people to use it,
> syntax should be concise and brief.
If every property of the class is readonly it would
On Fri, Jul 16, 2021 at 10:11 AM Eugene Sidelnyk
wrote:
> Thanks for your response!
> Anyway, I probably put it wrong by saying "by default", so let me clarify
> myself.
>
> What I really mean is omitting the dollar sign. So everything remains the
> same with ordinary properties (which are mutabl
On 16/07/2021 09:11, Eugene Sidelnyk wrote:
Thanks for your response!
Anyway, I probably put it wrong by saying "by default", so let me clarify
myself.
What I really mean is omitting the dollar sign. So everything remains the
same with ordinary properties (which are mutable), and we introduce
Le 16/07/2021 à 10:11, Eugene Sidelnyk a écrit :
Thanks for your response!
Anyway, I probably put it wrong by saying "by default", so let me clarify
myself.
What I really mean is omitting the dollar sign. So everything remains the
same with ordinary properties (which are mutable), and we introdu
Thanks for your response!
Anyway, I probably put it wrong by saying "by default", so let me clarify
myself.
What I really mean is omitting the dollar sign. So everything remains the
same with ordinary properties (which are mutable), and we introduce
immutable (readonly) properties as another type
On Fri, Jul 16, 2021 at 8:45 AM Eugene Sidelnyk wrote:
> This is replica of github PR comments:
>
> Hi there!
> Isn't it better to simplify this a bit? I mean `readonly` keyword is really
> long to type every time we need such property. Earlier (in php7.3)
> properties were defined only with visi
On Wed, Jul 7, 2021, at 10:33 PM, Brent Roose wrote:
> > The property accessor RFC (which didn't get to a vote) discussed this, and
> > specifically proposed making properties part of the interface for...
> > basically all the reasons given here.
> >
>
> I thought the RFC didn't go to vote bec
Le 07/07/2021 à 23:16, Larry Garfield a écrit :
The property accessor RFC (which didn't get to a vote) discussed this, and
specifically proposed making properties part of the interface for... basically
all the reasons given here.
My preference would be to add property accessors in 8.2 (at leas
> On 7 Jul 2021, at 23:16, Larry Garfield wrote:
>
> On Wed, Jul 7, 2021, at 7:32 AM, Brent Roose wrote:
>> Hi internals
>>
>> With the readonly properties RFC almost certainly accepted, I'd like to
>> discuss an idea that's slightly related to them.
>>
>> One of the problems that readonly p
On Wed, Jul 7, 2021, at 7:32 AM, Brent Roose wrote:
> Hi internals
>
> With the readonly properties RFC almost certainly accepted, I'd like to
> discuss an idea that's slightly related to them.
>
> One of the problems that readonly properties solve is that they reduce
> the overhead of writing
Le 07/07/2021 à 14:32, Brent Roose a écrit :
Hi internals
With the readonly properties RFC almost certainly accepted, I'd like to discuss
an idea that's slightly related to them.
One of the problems that readonly properties solve is that they reduce the
overhead of writing getters and setters
22 matches
Mail list logo
