Re: [PHP-DEV] [RFC] Propety Accessors v1.1

Clint Priest wrote: I certainly would not want to push through the door a low quality solution, I would never do that, but I have been working on this project myself for a year and each time I come back, having addressed the concerns of the last batch of opinions there are a whole new set of c

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

If at all possible, I'd rather not add extra keywords such as read-only and write-only to the language. If it's unnecessary than it shouldn't be done - that's my point of view. The question is thus "is read-only necessary?". The proposal brought up by someone else was using > private final set($va

RE: [PHP-DEV] [RFC] Propety Accessors v1.1

What about private final set($value) { } tells you that it's read only? There is a setter. From: Pierre Joye [mailto:pierre@gmail.com] Sent: Thursday, October 11, 2012 12:05 AM To: Clint Priest Cc: PHP internals; Jazzer Dane Subject: RE: [PHP-DEV] [RFC] Propety Accessors v1.1 On Oct 11, 20

RE: [PHP-DEV] [RFC] Propety Accessors v1.1

On Oct 11, 2012 5:00 AM, "Clint Priest" wrote: > > Why is everyone so dead set against read-only and write-only? > > I could not disagree more with you on what is "pretty" and "readable". > > To me: > > public read-only $hours { > get { ... } > } > > Is infinitely more readable and

RE: [PHP-DEV] [RFC] Propety Accessors v1.1

Why is everyone so dead set against read-only and write-only? I could not disagree more with you on what is "pretty" and "readable". To me: public read-only $hours { get { ... } } Is infinitely more readable and understandable than: public $hours { get() { ... }

RE: [PHP-DEV] [RFC] Propety Accessors v1.1

Hey Levi, I certainly would not want to push through the door a low quality solution, I would never do that, but I have been working on this project myself for a year and each time I come back, having addressed the concerns of the last batch of opinions there are a whole new set of concerns. I

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

This all sounds about right. In regards to #4 - read-only/write-only: I think that, from a "pretty syntax" point of view, private final set() {} and private final get() {} are definitely our best bets. But... from a logical point of view, I prefer read-only/write-only. private final get() {} is t

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

On 10/10/12 21:41, Jazzer Dane wrote: Here's my feedback on some current outstanding issues/suggestions: 1) Default value: I think having functionality for a default value is necessary, but I'm also thinking it may already be implementable within the current syntax. class Test { private $

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

Just a couple of quick remarks. Clint wrote: > I'm not even sure that automatic backing fields are even desired, I never felt the need to have them in C# and the only reason they were included is because they were a part of Dennis's original proposal. Automatic backing fields are indeed necessar

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

On Wed, Oct 10, 2012 at 6:35 PM, Clint Priest wrote: > I will come up with some way for people to vote on the issues at hand and > we can cast our votes and be done with it, then I will finish the project > and get it out the door. > > -Clint I very much appreciate your work in this area, Clint,

RE: [PHP-DEV] [RFC] Propety Accessors v1.1

Okay, I would like this to be the last time there are revisions to this RFC. To sum up the last few days of conversations, I have these down as points of contention: 1. Accessor functions should not be present on the object and callable directly, for example, $o->__getHours() should not be a

RE: [PHP-DEV] [RFC] Propety Accessors v1.1

Jazzer's example was extending an accessor and her statement about no way to stop the developer from doing what she did there without read-only is correct. There are other, more verbose and less simple ways to accomplish read-only and write-only (preventing sub-classes from defining a getter, et

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

> There's no way to stop the developer from doing that without read-only. Yes, there is - I don't even know why would write it that way - doesn't seem to make much sense. What you probably should be doing, is this: class A { private $seconds = 3600; public $hours { get() { return $this-

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

On Oct 8, 2012, at 10:07 PM, Denis Portnov wrote: > 08.10.2012 15:52, Clint Priest пишет: >> public $Hours { >> get { return $this->Seconds / 3600; } >> set { $this->Seconds = $value; } >> isset { return >> isset($t

RE: [PHP-DEV] [RFC] Propety Accessors v1.1

> On Wed, Oct 10, 2012 at 5:51 AM, Clint Priest wrote: > > I'm not even sure that automatic backing fields are even desired, I > > never felt the need to have them in C# and the only reason they were > > included is because they were a part of Dennis's original proposal. > > Eliminating them would

Re: [PHP-DEV] stream_get_line behaviour Bug #63240

Sent from my iPhone On 10 Oct, 2012, at 6:39 PM, Nicolai Scheer wrote: > Hi again! > > Thanks for your help an comments on the issue. > > cataphract commented on the stream_get_line behaviour (returning false > when used on an empty file) on the bug report page. > I do agree that reading on

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

On Wed, Oct 10, 2012 at 5:51 AM, Clint Priest wrote: > I'm not even sure that automatic backing fields are even desired, I never > felt the need to have them in C# and the only reason they were included is > because they were a part of Dennis's original proposal. Eliminating them > would eliminat

RE: [PHP-DEV] [RFC] Propety Accessors v1.1

On Wed, 2012-10-10 at 11:53 +, Clint Priest wrote: > > On 10 October 2012 01:16, Johannes Schlüter wrote: > > > Up until now reflection is leaky and is telling the truth. We should > > > either keep that or completely clean up reflection. > > > > Reflection should always tell the truth, or th

RE: [PHP-DEV] [RFC] Propety Accessors v1.1

> >> What concerns me with the current implementation is that it leaks > >> many implementation details, in particular the fact that the > >> accessors are implemented as *real* __getXYZ methods and automatic > >> implementations also use *real* $__XYZ properties. > > > I don't particularly see th

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

2012/10/10 Clint Priest : > While I agree it would be a "nice to have" it would also be un-necessary. > There are already ways to do precisely what is desired here by way of > ArrayAccess. > > class Addresses implements ArrayAccess { > offsetSet($offset, $value) { ... } > offsetG

RE: [PHP-DEV] [RFC] Propety Accessors v1.1

> > Second, I'd like to throw in the idea of array accessors. I mentioned > > this before, but did not get any response. > > > > public $Addresses { > > offsetSet($offset, $value) { ... } > > offsetGet() { ... } > > offsetUnset($offset) { ... } > > offsetExists($offset) { ... } > >

RE: [PHP-DEV] [RFC] Propety Accessors v1.1

> On 10 October 2012 01:16, Johannes Schlüter wrote: > > Up until now reflection is leaky and is telling the truth. We should > > either keep that or completely clean up reflection. > > Reflection should always tell the truth, or there is no point in it. > Unfortunately the "truth" here is subj

Re: [PHP-DEV] stream_get_line behaviour Bug #63240

Hi again! Thanks for your help an comments on the issue. cataphract commented on the stream_get_line behaviour (returning false when used on an empty file) on the bug report page. I do agree that reading on an empty file can be considered an error thus returning false, because there's nothing to

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

Here's my feedback on some current outstanding issues/suggestions: 1) Default value: I think having functionality for a default value is necessary, but I'm also thinking it may already be implementable within the current syntax. > class Test { > private $seconds; > public $hours { >

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

On 10 October 2012 08:46, Bernhard Schussek wrote: > Second, I'd like to throw in the idea of array accessors. I mentioned > this before, but did not get any response. > > public $Addresses { > offsetSet($offset, $value) { ... } > offsetGet() { ... } > offsetUnset($offset) { ... } >

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

On 10 October 2012 04:51, Clint Priest wrote: > Wow, I'm surprised by all the talk about this RFC this time around. I > posted this numerous times in the past trying to elicit feedback and got > little to none, so I took the time to write it as I thought it should be > written. Some of these thi

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

On 10 October 2012 01:16, Johannes Schlüter wrote: > Up until now reflection is leaky and is telling the truth. We should > either keep that or completely clean up reflection. Reflection should always tell the truth, or there is no point in it. On 10 October 2012 04:28, David Muir wrote: > That

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

Hi Clint, In order to achieve read-only and write-only, we could do something similar to this: /* Explicitly read-only, sub-classes may redefine the getter but may not define a setter */ public $Hours { get() { ... } final private set() {} } This would make the additional keyword superfl