Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Extra shorthand declaration

[Jazzer Dane]

Is the only intended benefit behind this proposal the ability to seamlessly
extend a seemingly normal property as an accessor?

On Fri, Oct 26, 2012 at 3:43 AM, Clint Priest  wrote:

> I'm opening up several new threads to get discussion going on the
> remaining "being debated" categories referenced in this 1.1 -> 1.2 change
> spec:
> https://wiki.php.net/rfc/**propertygetsetsyntax-as-**
> implemented/change-requests
>
> --**--**
> 
> *Extra shorthand declaration*
>
> Allow extra short declaration of an accessor:
>
> class TimePeriod {
> public DateTime $date;
> }
>
> /* Would be equivalent to this */
>
> class TimePeriod {
> public $date {
> get() { return $this->date; }
> set(DateTime $value) { $this->date = $value;}
> }
> }
>
> --**--**
> 
> Thoughts?
>
> --
> -Clint
>
>

Re: [PHP-DEV] [RFC] Accessors : read-only / write-only keywords

[Jazzer Dane]

Nikita brought up a good point:
There aren't all that many scripts that use final methods, which could very
well be the same fate for final property accessor methods.

Due to the very possible unpopularity of whatever magic syntax/keyword we
could potentially come up with, we *could *alternatively trash any magic
read/write-only keywords/syntax and just allow people to manually throw a
read-only exception.

Opinions?

On Sat, Oct 20, 2012 at 3:15 AM, Pierre Joye  wrote:

> On Sat, Oct 20, 2012 at 1:07 AM, Clint Priest  wrote:
> > I had thought of a deviation on some of the ideas presented to get rid
> of read-only/write-only while still keeping the ability to maintain their
> effect, if we so decide that the feature is wanted.  Here it is:
> >
> > class TimePeriod {
> > private $Seconds;
> >
> > public $Hours {
> > get() { return $this->Hours; }
> > final set NULL;
> > }
> > }
> >
> > It's close to what's been suggested but is pretty clear that there IS NO
> SETTER it could not be called within the class and since its final it
> cannot be over-ridden.  I've included this in the change tracking document.
> >
> > Thoughts?
>
> Sorry but I don't like it, it makes me think that there is no setter
> but I could set the property manually (yes, that's not an actual one
> but putting myself in the shoes of a lambda user).
>
> I actually prefer the read-only syntax, while we have to make it clear
> and not confusin (see Niki's reply in this post).
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Accessors : read-only / write-only keywords

[Jazzer Dane]

Nikita, there appears to be a slight misunderstanding. You're initial email
was worded in a way that I presumed you were attacking the final keyword
entirely, not just final methods. You are correct in that many PHP
frameworks don't have final *functions*.

My pushing for the read-only functionality is that it, in my opinion,
necessary for cohesiveness with the final keyword.

The read-only implementation we are still working on creating is
essentially a magic version of

> final set() { throw new ReadonlyPropertyException; }
>

In regards to your third point: Clint sent an email a few days wherein he
implied you were the driving factor behind automatic accessors. Sorry for
the confusion.

Asymmetric accessor visibility is a different subject. It's moderately
convenient but I'm worried there's too much magic going on in the
background and it's not apparent what the syntax means. We should probably
open up another discussion thread for this subject, though.

On Sat, Oct 20, 2012 at 2:52 AM, Nikita Popov  wrote:

> On Sat, Oct 20, 2012 at 11:31 AM, Jazzer Dane 
> wrote:
> > The final keyword is used, especially in sizable OOP applications.
> Claiming
> > it supposedly isn't used very often anymore - even if it were true - is
> not
> > an excuse to exclude the "read-only"-esque functionality in this RFC.
> Firstly, I didn't make that claim out of thin air, I actually checked
> how many final methods are used in ZF and Symfony (which are my usual
> reference projects due to their large size) and from that concluded
> that "nearly never" is a very accurate description. It could obviously
> be that those two projects are somehow special and everyone else uses
> large amounts of final methods ;)
>
> Secondly, low anticipated use is actually a very good reason to
> exclude functionality. One shouldn't add features from which you know
> right from the start that nearly no-one will use them.
>
> Thirdly, I don't want to exclude the possibility of enforcing
> read-only-ness through the hierarchy. I just don't want to provide a
> dedicated syntax for such an edge case. As already mentioned, there
> already are sufficiently simple ways to do this:
>
> // read-only for all classes in the hierarchy, only the current one
> can read
> final private set();
> // absolutely read-only
> final private set() { throw new ReadonlyPropertyException; }
>
> The latter is even rather clear about the intention ;)
>
> > My top choice is final get;, which would work quite well and
> non-ambiguously
> > if we don't implement Nikita's proposed automatic accessor functions or
> > implement it in a noticeably different syntax.
> Not sure where you got that, but automatic accessor implementations
> are not my idea, they were part of the original proposal. I wanted to
> remove them, but later we found that they are necessary for various
> aspects of the RFC, in particular asymmetric accessor visibility
> (public $foo { get; protected set; }). Unless you want to drop that
> too automatic implementations have to stay.
>
> Nikita
>

Re: [PHP-DEV] [RFC] Accessors : read-only / write-only keywords

[Jazzer Dane]

I'll agree with you in regards to your analysis of Clint's proposed syntax.

In terms of your questioning the idea around "read-only", this is how I
think about it:
Class A created  property accessor $z that you can not set. Class B can
extend me just fine, but they can not alter that basic rule that I laid out
for my and all my children's property accessor $z: You can not set it.

This makes sense to me, and I feel like it is control that the developer
should have.

If we were to translate *final set NULL;* (or whatever implementation we
choose to use) to a more manual implementation, it may look something like
this:

public $property {
>   final get() { ... }
>   final set($value) { throw new Exception("You can't set $property. It is
> read only."); }
> }
>

On Sat, Oct 20, 2012 at 2:40 AM, Stas Malyshev wrote:

> Hi!
>
> > get() { return $this->Hours; }
> > final set NULL;
>
> It looks like some unobvious piece of magic - what exactly "set NULL"
> means? There's no obvious parsing of this thing for somebody that
> doesn't already know what the magic means. I'd rather have people
> implement a method throwing exception manually than have this. It's
> unclear what is relationship between "set" (is it a variable? a
> constant? a method?) and "NULL" (what NULL here means? is it assignment
> of NULL to set? is it declaration of NULL with type "set"?) and it does
> not parse naturally with almost any background.
>
> Thinking about it for a while, the whole idea of "this class can never
> have this method implemented" looks a bit strange to me - I don't think
> I've ever encountered such concept in OOP. You can say "I implement it
> this way and you can't override it" but NULL does not suggest any
> natural implementation.
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Accessors : read-only / write-only keywords

[Jazzer Dane]

The usage of the syntax in C# is moderately unimportant. This is a
different language, and property accessors are part of numerous languages -
not just C#. That being said, it's not that big of a deal, as it seems that
most people are in a consensus that we do not want to to be adding any sort
of read only keyword.

The final keyword *is* used, especially in sizable OOP applications.
Claiming it supposedly isn't used very often anymore - even if it were true
- is not an excuse to exclude the "read-only"-esque functionality in this
RFC.

Amaury brings up an interesting point in that write-only essentially makes
the accessor a method. In my opinion, this needs to be further discussed as
to whether or not we do or do not need write-only. If there are no good
real-world implementations of it other than making a property act like a
method, then we should probably can that idea.

Read-only is still necessary, though in a different syntax. Being able to
set a "final"-esque functionality on the get property accessor function -
as to protect from certain cases, however few there may be - is, in my
opinion, an important, necessary piece of this RFC.


I think const has too many issues, and thus we shouldn't use it. When
setting a variable to a constant in PHP, it changes the way the variable is
called. From *$this->property* or *$variable* to *$this::property *or*variable
*. Even with const, we still have the same issue that we had with numerous
of the previous proposals:

> // Which one?
>
public $property {
>   const get();
>   const get;
>   const get() {}
>   final private get;
>   final private get();
>   final get NULL;
> }
>
> // This is what I assume Amaury would prefer, correct? We're not going
> with the colon syntax, though, so this example is out of the question...
>
public:const $property {
>   set() { ... }
> }
>

Considering we aren't using the colon solution proposed by Amaury, const
still doesn't solve the solution and would just add confusion if we were to
implement it in whatever solution we come up with.


Let's look over our other past and current implementations and proposals:

> public $property {
>   final get;
>   final get();
>   final get NULL;
>   final private get() {} // RFC 1.2 Current Implemented Proposal
> }
>
> // And of course, from RFC 1.1
> public read-only $property {
>   set() { ... }
> }
>

My top choice is *final get;*, which would work quite well and
non-ambiguously if we don't implement Nikita's proposed automatic accessor
functions or implement it in a noticeably different syntax.

It's the easiest to write, and it's pretty obvious that it isn't extendable
and doesn't actually do anything, and thus is arguably visually read-only.

My opinion of Clint's proposed *final get NULL;* is a bit meh - the null
keyword is just spat up on the code and the syntax is a bit too..
unfamiliar for my preference. It would make a lot more sense if it was *final
get = NULL;* but I don't think we should go that route.

On Sat, Oct 20, 2012 at 2:05 AM, Nikita Popov  wrote:

> On Sat, Oct 20, 2012 at 9:29 AM, Amaury Bouchard 
> wrote:
> >   read-only => final set null;
> > It begins to be verbose.
> >
> > As I said many times, why don't you want to use the "const" keyword? It
> > already exists and is pretty well understood by everybody.
> Could you maybe explain where exactly "const" would be used? Please
> don't forget that we do not use your "foo:bar" syntax, so where would
> the "const" go with the currently used syntax?
>
> Anyway, I'd like to give a quick comment on read-only: I mainly don't
> like the keyword because it doesn't do what I expect it to do. When I
> first glanced over the RFC I thought that read-only was a way to
> define read-only properties (i.e. properties that can only be set via
> default value or in the constructor) along the lines of "public
> read-only $name = 'FooBar';". This is what the "readonly" modifier
> means in C# (which is the language the RFC is adopted from mainly). In
> C# readonly can *not* be added to properties with accessors, only to
> simple fields. With the current RFC / the original proposal
> "read-only" gets a completely different meaning.
>
> I think that the behavior of the modifier in C# is useful, whereas its
> behavior in the original accessors proposal is mostly pointless. I
> mean, why would you need to strictly enforce that a property is
> read-only throughout the inheritance hierarchy? From an interfacing
> (LSP) point of view it's not of importance whether an additional set
> accessor is added, as long as the get accessor stays. I would guess
> that "read-only" will be used about as much as "final" is used today.
> And "final" is nearly never used.
>
> That's why I really don't think that we need any kind of special
> syntax for this. If you do happen to be the rare case where you need
> to enforce the read-only-ness throughout the hierarchy, you can always
> use the "final private set()" approach (maybe even throwing an
> exception fr

Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2

[Jazzer Dane]

Yes, I'm aware - I thought of the clash with Nikita's proposal while
writing mine, but decided not to bring it up. If we were to go with my
proposed syntax, then one of two things would have to happen.
1) Don't auto implement get/set. *On a similar note, what's the difference
between using a property accessor that auto implements get/set* and a
normal property?
2) As you said, differentiate between get; and get();. The issue this
creates is obvious, and in my opinion this isn't a viable solution.

For the record, *read_only* and even moreso *readonly* are, in my opinion,
nicer than *read-only*.

On Tue, Oct 16, 2012 at 5:10 AM, Clint Priest  wrote:

>  This would conflict with the concept of auto-implementation, which if we
> went with Nikita’s suggestion, would make an undefined body setter actually
> set the property it shadows.
>
> ** **
>
> For example 
>
> ** **
>
> class a {
>
> public $prop {
>
> get() { … }
>
> final set($x); 
>
> }
>
> }
>
> ** **
>
> Would have final set() translate to final set($x) { $this->prop = $x; }***
> *
>
> ** **
>
> We **could** have it be that final set; or final set(); ß Without the ()
> or without the ($x) specifically mean that it is read-only but the clarity
> goes WAY down.  It is not at all intuitive that any of those things means
> ‘read-only’
>
> ** **
>
> Why is everyone so against the two new keywords?  I’m told there has been
> talk long ago about having them as keywords anyway.  Is it the dash?
>
> ** **
>
> Is this more palatable?
>
> ** **
>
> public readonly $prop { 
>
> get() { }
>
> }
>
> ** **
>
> Or
>
> ** **
>
> public read_only $prop { … }
>
> ** **
>
> Specifically, read-only actually has the advantage that one of the few
> ways that it would break BC is if someone had defined a variable named
> $read and attempted to subtract a constant or string of ‘only’ from it.***
> *
>
> ** **
>
> $read = 5;
>
> echo $read-only; // Yields 5
>
> ** **
>
> with define(‘only’, 2);
>
> ** **
>
> echo $read-only; // Becomes 3
>
> ** **
>
> I find it highly unlikely that someone would have been using $read-only or
> $write-only since variables cannot have dashes in them, he interpreter sees
> that as a subtraction and as shown above it would be nonsensical to have
> written PHP like that.
>
> ** **
>
> ** **
>
> *From:* Jazzer Dane [mailto:tbprogram...@gmail.com]
> *Sent:* Tuesday, October 16, 2012 6:45 AM
> *To:* Clint Priest
> *Cc:* Stas Malyshev; internals@lists.php.net
> *Subject:* Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
>
> ** **
>
> private final get/set() {} is indeed not a read/write only functionality.
> I really would like to keep new keywords out of whatever syntax is
> implemented, but I think the latest proposal can and should be improved
> upon.
>
> I've been thinking about this quite a bit.
> To reiterate the initial problem, although we can disable get/set by not
> including it in the accessor, the reason we need read/write only is,
> without it, there is no way to not allow subclasses to add set/get to their
> parent's accessor.
>
> Going with the idea that not including get/set disables them, what about
> this syntax:
>
> class MyObject
> {
>   public $property {
> get() { ... }
> final set; // Defining an accessor function without body is virtually
> the same as not defining the accessor function at all, i.e. this property
> accessor can not be set.
>   }
> }
>
> $object = new MyObject();
> $propertyValue = $object->property; // Works
> $object->property = 10; // Does not work, set not allowed
>
>
> By "disabling" accessor functions that don't provide a body, we can easily
> imitate read/write arguably better than what the current RFC is capable of,
> and use exceptions that already exist (same as the exception thrown if the
> accessor function is never defined in the property accessor).
>
> On Tue, Oct 16, 2012 at 4:19 AM, Clint Priest  wrote:
> 
>
> Hey Stas, a bunch of this has already been covered but I will attempt to
> answer each of these as is my current understanding of "the hives"
> decision... :P
>
>
> > 1. Accessors IMO should be regular PHP methods that PHP generates with
> two additional things:
> > a. Their name is generated by PHP
> > b. Their argument set is def

Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2

[Jazzer Dane]

private final get/set() {} is indeed not a read/write only functionality. I
really would like to keep new keywords out of whatever syntax is
implemented, but I think the latest proposal can and should be improved
upon.

I've been thinking about this quite a bit.
To reiterate the initial problem, although we can disable get/set by not
including it in the accessor, the reason we need read/write only is,
without it, there is no way to not allow subclasses to add set/get to their
parent's accessor.

Going with the idea that not including get/set disables them, what about
this syntax:

> class MyObject
> {
>   public $property {
> get() { ... }
> final set; // Defining an accessor function without body is virtually
> the same as not defining the accessor function at all, i.e. this property
> accessor can not be set.
>   }
> }
>
> $object = new MyObject();
> $propertyValue = $object->property; // Works
> $object->property = 10; // Does not work, set not allowed
>

By "disabling" accessor functions that don't provide a body, we can easily
imitate read/write arguably better than what the current RFC is capable of,
and use exceptions that already exist (same as the exception thrown if the
accessor function is never defined in the property accessor).

On Tue, Oct 16, 2012 at 4:19 AM, Clint Priest  wrote:

> Hey Stas, a bunch of this has already been covered but I will attempt to
> answer each of these as is my current understanding of "the hives"
> decision... :P
>
> > 1. Accessors IMO should be regular PHP methods that PHP generates with
> two additional things:
> > a. Their name is generated by PHP
> > b. Their argument set is defined by the accessor pattern (i.e. same
> thing as __get/__set).
> > We should keep the amount of magic and special cases to the minimum, the
> engine is complex enough as it is.
> > This of course includes the full range of options available for the
> methods - final, reflection, call scenarios, etc.
>
> This is the way it is, though Nikita strongly disagrees that they should
> be "callable, visible" methods on the object and I agree with Nikita on
> this issue, I never did like the idea that __getHours() and __setHours()
> were methods of a class just because of an accessor definition, which is
> why I worked to have Reflection hide that fact.  If I were to go about this
> again, they probably will not be methods of the class.  Internally there is
> little requiring an op_array to be attached to a class in order to be
> executed.
>
> > 2. isset is defined as:
> > isset() { return $this->Hours != NULL; } This does not seem to
> be correct - != NULL does not work like isset now.
> > Try this:
> > class A { public $x = 0; }
> > $a = new A;
> > var_dump(isset($a->x));
> > var_dump($a->x != NULL);
> > This needs to be fixed - generated isset() should be defined to work
> exactly like regular isset and actually use the same code path.
> > Argument to isset() call can be retrieved using accessor but it should
> not differ from isset() result in any possible way or situation
> > (including error situations - e.g. notices, etc.)
>
> The reason that = NULL and != NULL was chosen is because isset() and
> unset() are special states that are available only to a variable or
> property, since a get/set do not return a real property they cannot be used
> with isset/unset.  Now that there has been discussion of an accessor being
> a real property shadowed by get/set, standard isset/unset could potentially
> be used against the underlying property.
>
> > 3. How references and complex cases are handled? Didn't find anything
> about it, e.g. how it handles $foo->bar++, $foo->bar[] = 1,
> > $foo->bar[123] = 4, etc. ($foo->bar being property with get/set defined
> of course)? How $foobar =& $foo->bar is handled? The sort()
> > case mentions by-ref return but does not explicitly mention all other
> cases.
> > These need to be covered explicitly in the RFC.
>
> This is covered in the RFC, perhaps not clearly enough (let me know how I
> could expand on it further for clarity).  To answer each of your questions,
> you can think of what would happen as if it were a function call.  For
> example, if you did $foo->bar()[123] = 4 you would be modifying a
> return-by-val.  If bar were instead defined as returning a reference, then
> it would indeed work as you expect above.  $foobar = &$foo->bar would work
> as expected as long as the getter is returning a reference as well.
>
> I, perhaps mistakenly, assumed that if return-by-ref and sort() worked
> properly, then all other "usages of references" should equally work the
> same, is that not right?  If it's not right, why not?
>
> > 4. We have some LSP controls now in place to ensure non-LSP overrides
> generate E_STRICT. Will this be the case for properties too?
> > Meaning, what happens if you add overriding protected getter to a
> property that was previously fully public - thus violating the LSP?
>
> Certainly, this basic object oriented functional

Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2

[Jazzer Dane]

Excuse my late-night-influenced terminology, the word "empty" is much more
suitable than "does not have".
And this "solution" really is more of a hack or work-around than a solution.

I do think that there is a better way to go about implementing
read/write-only, but nothing has come to mind as of yet - at least nothing
that doesn't completely change major aspects of this RFC.

On Tue, Oct 16, 2012 at 3:59 AM, Stas Malyshev wrote:

> Hi!
>
> > I apologize for my confusing terminology - let me elaborate. There are
> > no special syntaxes. The below code should help clear things up a bit:
> >
> > class MyClass {
> >   private $otherProperty;
> >   public $property {
> > get() {}; // Does not "have a body", as there is no code between
> > the curly braces.
>
> It does have a body. This body is just default empty method body
> returning null - which does not throw any exceptions and is completely
> indistinguishable from the outside from property being equal to null.
> I'm not sure it's what the intent of *-only variable is, though I guess
> it is a way to hack around it. I wonder however if it can be done better.
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>

Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2

[Jazzer Dane]

I apologize for my confusing terminology - let me elaborate. There are no
special syntaxes. The below code should help clear things up a bit:

class MyClass {
>   private $otherProperty;
>   public $property {
> get() {}; // Does not "have a body", as there is no code between the
> curly braces.
> set($value) { $this->otherProperty = $value; } // Does "have a body",
> as there IS code between the curly braces.
>   }
> }
>

On Tue, Oct 16, 2012 at 3:48 AM, Stas Malyshev wrote:

> Hi!
>
> > Stas, the proposed "solution" thus far is to make the getter or setter
> > final and private and not have a body. This would naturally throw an
> > exception if it was accessed from anywhere but the class it was defined.
> > The class it was defined in has to remember that it is virtually a
> > read/write only accessor.
>
> What you mean by "not have a body" - is there special syntax for
> body-less methods introduced? Then it should be in the RFC. How it is
> implemented - what exactly is stored in the function table then?
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>

Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2

[Jazzer Dane]

Stas, the proposed "solution" thus far is to make the getter or setter
final and private and not have a body. This would naturally throw an
exception if it was accessed from anywhere but the class it was defined.
The class it was defined in has to remember that it is virtually a
read/write only accessor.
Although it has not been proposed yet, perhaps the above can be further
enforced by automatically throwing an exception whenever a getter/setter
exists but does not have a body.

Nevertheless, the "solution" is, as you can see, pretty loose right now,
and I definitely wouldn't object to hearing and discussing alternative
proposals.

On Tue, Oct 16, 2012 at 3:18 AM, Stas Malyshev wrote:

> Hi!
>
> > In regards to #11, yes, you'd just write {}. I imagine you could also
>
> This doesn't work for the same class (and for traits which put things in
> the context of the same class) - it would not behave as "no setter", it
> would behave as "there's a setter doing nothing". Is this the proposed
> solution?
>
> Exception is a possibility but then everybody would do it differently
> which reduces the value of standardizing it (the whole point of having
> accessors since otherwise we could just do __get and throw exceptions).
>
> > We went through multiple alternative options to read/write-only, and the
> > implementation you see in the 1.2 RFC is the most widely agreed upon
> > proposal. I don't doubt that there is room for improvement in this area,
> > but we haven't had any further proposals as of yet.
>
> Actually, I do not see anything explicitly said in the proposal that
> works for the cases outlined above. I wanted to just make sure if that
> means "no solution currently" (then should be on TODO list) or "we have
> a solution but it's not outlined in the RFC" (should be added then).
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>

Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2

[Jazzer Dane]

In regards to #11, yes, you'd just write {}. I imagine you could also just
throw an exception. Maybe an exception could be thrown automatically if
there is no code between the braces. Though this doesn't really directly
relate to providing the ability to disable get/set in an accessor.

The only class that would ever be able to logically attempt to use the
empty getter/setter would be the very one that you define the accessor in.

We went through multiple alternative options to read/write-only, and the
implementation you see in the 1.2 RFC is the most widely agreed upon
proposal. I don't doubt that there is room for improvement in this area,
but we haven't had any further proposals as of yet.


On Tue, Oct 16, 2012 at 2:43 AM, Stas Malyshev wrote:

> Hi!
>
> > #5: From what I understand, an extending class can not override an
> > accessor with a non-accessor.
>
> This should be in the RFC then - along with what exactly happens. Note
> that this will represent a sort of BC break in terms that you could have
> two properties $a before, but if you change implementation of $a in base
> class from plain old property to accessor property, the child class
> would break. Which is not good, since compatible changes in parent class
> should not break child classes - and which will also impede adoption of
> this feature, since you can not guarantee no child class does it.
>
> > #11: If you set an accessor's get or set to /final private/, you are not
> > able to extend and it are only able to invoke it from the current class.
> > If you don't invoke it, then it is virtually read or write only.
>
> I get this, but what do you write as a method body if you want to just
> disallow it? Do you write just {}? Then it's not good for get() since
> get() is supposed to return a value, and also not good for set() since
> base class still can call private methods, and we want set() to be not
> available for everybody.
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>

Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2

[Jazzer Dane]

#2: I agree with you here - this is problematic. isset/unset accessors that
invoke the isset/unset function should actually invoke the function rather
than being compared to null, as that isn't the same as isset.

#5: From what I understand, an extending class can not override an accessor
with a non-accessor.

#11: If you set an accessor's get or set to *final private*, you are not
able to extend and it are only able to invoke it from the current class. If
you don't invoke it, then it is virtually read or write only.


On Tue, Oct 16, 2012 at 2:12 AM, Stas Malyshev wrote:

> Hi!
>
> > https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
>
> My feedback on the RFC:
>
> 1. Accessors IMO should be regular PHP methods that PHP generates with
> two additional things:
> a. Their name is generated by PHP
> b. Their argument set is defined by the accessor pattern (i.e. same
> thing as __get/__set).
> We should keep the amount of magic and special cases to the minimum, the
> engine is complex enough as it is.
> This of course includes the full range of options available for the
> methods - final, reflection, call scenarios, etc.
>
> 2. isset is defined as:
> isset() { return $this->Hours != NULL; }
> This does not seem to be correct - != NULL does not work like isset now.
> Try this:
> class A { public $x = 0; }
> $a = new A;
> var_dump(isset($a->x));
> var_dump($a->x != NULL);
> This needs to be fixed - generated isset() should be defined to work
> exactly like regular isset and actually use the same code path. Argument
> to isset() call can be retrieved using accessor but it should not differ
> from isset() result in any possible way or situation (including error
> situations - e.g. notices, etc.)
>
> 3. How references and complex cases are handled? Didn't find anything
> about it, e.g. how it handles $foo->bar++, $foo->bar[] = 1,
> $foo->bar[123] = 4, etc. ($foo->bar being property with get/set defined
> of course)? How $foobar =& $foo->bar is handled? The sort() case
> mentions by-ref return but does not explicitly mention all other cases.
> These need to be covered explicitly in the RFC.
>
> 4. We have some LSP controls now in place to ensure non-LSP overrides
> generate E_STRICT. Will this be the case for properties too? Meaning,
> what happens if you add overriding protected getter to a property that
> was previously fully public - thus violating the LSP?
>
> 5. What happens if you override accessor property with plain old
> variable property? I.e.:
>
> class A {
>protected $secret {
> get() { return "secret"; }
>   }
> }
>
> class B extends A {
>public $secret = "not a secret anymore";
> }
>
> Also, what happens here if A extends B in the same scenario (this refers
> to the #4 too).
>
> 6. Thinking more about isset/unset - why not make isset/unset always be
> the default unless overridden? I can't really see the case where you
> want echo $foo->bar to work but if(isset($foo->bar)) echo $foo->bar to
> not work. I think isset() and unset() should always use automatic
> implementations by default (fixed in accord with #2 of course).
>
> 7. "Error messaging" section is not clear. Some examples would help -
> what is being translated to what?
>
> 8. "Static accessors" section is not clear, namely this one:
> This yielded the possibility that a getter call was being made while it
> should not be allowed (if there was no getter defined) and so pass_two()
> was changed to look for these non-backpatched illegal static getter
> calls and a compile time error is produced.
>
> When the code is compiled, the class definition (and, in fact, the name
> of the class we're talking about) may not be available, so how can you
> known if certain property of this class has getters defined?
>
> Also, I'm not sure what is the thing about backpatching and converting
> to function calls - I think it should work via engine handlers just as
> the rest of the things work in the engine, is it not the case? If not,
> it should be made the case.
>
> 9. This:
> Eliminate the ability for an accessor to be called via $o→__getHours(),
> the accessor functions will be completely unavailable for use except as
> property references ($o→Hours)
>
> I think it a mistake. More magic and complication in the engine is not a
> good thing and would require tons of special case checks in all places
> where we deal with functions. I think it is wrong - if we create a
> callable entity, it should be callable. __ in the name is the indication
> enough that you're dealing with special method and you should tread
> carefully, we should not go out of our way to mess up the engine to
> prevent it.
>
> 10. I'm not sure what the point about debug_backtrace() is but again, we
> should not create more complicated magic there, it just should show what
> really is happening.
>
> 11. About read-only/write-only thing - I like not having the keywords,
> but it is still not clear how final produces read-only property - do I
> say somethin

Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces

[Jazzer Dane]

I prefer the current syntax to your proposal because:

1) It is not at all obvious which side is which. Example:
*protected:private
*Is protected* *for get? Or set? The average PHP developer will have no
idea. In fact, they likely won't know that they even correlate to get and
set.

2) There is no such syntax already in PHP.  (And on a more personal note, I
don't think I've ever seen that syntax in any other language that I've
worked in before. Which means it's even *more-so* out of people's comfort
zones.)

The current read/write syntax works, and none of the discussion I've read
thus far would sway me towards any other option.

That being said, I wouldn't contest to hearing - in more detail - your
reasoning behind why we should use it instead of the current syntax.

On Tue, Oct 16, 2012 at 12:39 AM, Amaury Bouchard  wrote:

> 2012/10/15 Clint Priest 
>
> > Also, your "should be valid" statement implies that you feel properties
> > and accessors are the same and they are not, internally.  When a class
> > attempts to implement an interface a "function check" is done and since
> > there is no __getXX() function defined it would fail to implementation
> > check against an interface.
> >
> > I cannot stress enough that properties != accessors in any way except the
> > syntax in which they are used ($o->xyz) or ($o->xyz = 1), that is their
> > *only* similarity.
>
>
> I disagree. That's why I said this is a matter of choice. A philosophical
> choice.
> I don't see properties and accessors like different things which are
> accidentally written the same. Accessors are a layer upon properties. It's
> a magical layer, trying to mimic accessors.
> It's a bit like aspect-oriented programming: you can add layer but the core
> is still the same (from a developper point of view, not from the PHP
> interpreter point of view).
>
>
> See another argument: My proposal for read/write accessibility definition.
> When I suggested to allow this syntax: "public:private $abc;"
> some people objected that it's the same than "public $abc { get; private
> set; }"
>
> So, if I understand what you said, for you it's deeply different and
> comparing them is like comparing apples and oranges. I disagree. I still
> think my syntax is better (and could be implemented with better
> performance), but it's normal to compare them, because they (can) offer
> pretty much the same functionnalities.
>

Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces

[Jazzer Dane]

I'm going to agree with David here. It is most sensible to either allow
properties AND accessors in interfaces, or don't allow either of them.
__get/__set is a different subject that I'd rather not dig into while
discussing this RFC.

On Mon, Oct 15, 2012 at 8:43 PM, David Muir  wrote:

> On 16/10/12 13:37, Clint Priest wrote:
>
>> On Mon, Oct 15, 2012 at 6:02 PM, Clint Priest
>>>  wrote:
>>>
 > >Because fundamentally interfaces are designed to explain a way of
 communicating and properties are symmetrical and non-

>>> >observable.
>>>
 > >
 > >The implementing class cannot "know" when a property has changed.

>>> >
>>> >Do you agree that there is nothing that distinguishes
>>> >
>>> >class A {
>>> > public $v;
>>> >}
>>> >
>>> >from
>>> >
>>> >class B {
>>> >private $_v;
>>> >public $v { get { return $this->v; }; set($n) { $this->v = $n; }} }
>>> >
>>> >when it comes to a client of B reading and writing to $b->v ? That's
>>> the entire point of accessors: being able to seamlessly intercept
>>> >usages of properties with custom code.
>>> >
>>> >If you define an interface saying interface A { public $v { get;set;} }
>>> you are only saying to the user: objects of type A will have a
>>> >property $v that you can read and write to.
>>> >Whether it is a set of accessors or a property belongs to the
>>> implementation detail of the class implementing A, the user should not
>>> >be able to see a difference when interacting with the class, as he will
>>> do it through $obj->v and $obj->v = ...;
>>> >
>>> >I can understand why we might not want that in PHP in order to simplify
>>> the implementation, but it we follow logical reasoning I
>>> >can't see why we shouldn't implement that.
>>> >
>>>
>> I'm not sure I understand what you're getting at here Etienne, this
>> thread was about interfaces but now you're talking about two classes...
>>
>>
> From an interface standpoint, both classes implement the same property.
> One as a literal property, the other as an accessor. The point being, from
> the code consuming the class, a property and accessor are the same thing.
> Interfaces are about contracts between an implementation and a consumer, so
> the actual implementation is irrelevant. What matters is how the
> implementation is accessed by the consumer. If it is via property syntax,
> then it *is* a property, even though the actual implementation might be a
> property, an accessor or (in theory) even __get/__set.
>
> Cheers,
> David
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2

[Jazzer Dane]

One of the reasons the current syntax, as seen below, was chosen, is for
typehints - yes.

> public $property {
>   get() { ... }
>   set{TypeHint $value) { ... }
> }
>
The other reason it was chosen was to specifically get rid of the magic
$value that appeared out of thin air. If typehints become possible without
having to specify it in the set accessor, I'd still argue that the syntax
needs to stay as, in my opinion, it is the most cohesive and sensible
syntax that was proposed - even compared to:

> public $property {
>   get { ... }
>   set { ... }
> }
>


In terms of interfaces, Clint's reason for allowing accessors in interfaces
is moderately sensible: to remain cohesive with the already allowed __get
and __set magic methods that are usable in interfaces.* That's the
underlying issue.* If we want to require an object to be able to be
converted to a string, we can sensibly put __toString in the interface. But
what does forcefully implementing __get or __set do for the object? What
does it tell us about how we're able to use it? It relates to properties in
arguably such a manner that we(i.e. accessing the object's API) nor the
interface should care about. But that's an argument for another day.

So what do we do right now, then? If we allow it in interfaces, my main
worry is that people will put the accessor in an interface just because
they can't put a property, and they'd use the accessor as a normal, basic
property.


And finally, in terms of protected backing properties: It seems nice, but,
and I'm sure Clint will clarify on this, I'm not so sure that's really what
accessors are supposed to be used for. If people want a typehinted
property, then we should allow them to create a typehinted property rather
than forcing them to use accessors.

On Sun, Oct 14, 2012 at 5:50 AM, Nikita Popov  wrote:

> On Fri, Oct 12, 2012 at 7:23 AM, Clint Priest  wrote:
> > Alright, here is the updated RFC as per discussions for the last few
> days:
> >
> > https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
> >
> > If you could read it over, make sure I have all of your concerns
> correctly addressed and we can leave this open for the two week waiting
> period while I make the final code changes.
> >
> > -Clint
>
> So here comes my round of feedback on the current proposal.
>
> But before getting to that: I have collected a bit of data how getter
> and setter are currently used in Symfony and ZF:
> https://gist.github.com/3884203 Mainly so I get a better overview of
> the situation, but might be of interest for other people involved in
> this discussion too.
>
> So, my points on the proposal, in no particular order:
>
> 1. Typehints
> -
>
> The last revision of the proposal added the ability to typehint the
> set() accessor, so that's a good start. Still I would like to go a bit
> further on this point. My data says that about 20-30% of all setters
> are typehinted and it is highly probable that if we had scalar
> typehints (as I'm sure we will have in the future) that number would
> be even larger. In particular I would like to have an easy way to
> typehint if I *don't* want to override any additional behavior.
> Currently that would require me to write something along the lines of
> this:
>
> protected $_date;
> public $date {
> get() { return $this->_date; }
> set(DateTime $date) { $this->_date = $date; }
> }
>
> This is a rather lot of boilerplate code just to add a typehint. With
> automatic properties this might be reduced to this:
>
> public $date {
> get();
> set(DateTime $date);
> }
>
> This is already a lot nicer, because I don't have to implement the
> same getting and setting pattern again and again, but I still find
> that it doesn't do a particularly good job at conveying its intention.
> Rather, what that code *really* wants to say is just this:
>
> public DateTime $date;
>
> I think that it would be very beneficial to support this syntax,
> because I think that a large part of the use of the accessor proposal
> will just be type checking. But if we indeed want to syntax we should
> reconsider the get {} set { $value; } syntax again, because as I
> understand it the new get() {} set($value) {} syntax was mainly
> introduced to deal with setter typehints. If we chose to allow
> typehints before the property name, then that wouldn't be necessary
> anymore.
>
> 2. Interfaces
> --
>
> I already mentioned this before, but I'll reiterate it here again:
> Currently properties and properties with accessors are handled
> different with regards to interfaces. In particular, if you have an
> interface such as follows:
>
> interface Extension {
> public $name { get; }
> // more stuff
> }
>
> then the following is not a valid implementation of the interface:
>
> class FooExtension implements Extension {
> public $name = 'foo';
> // more stuff
> }
>
> This does not make sen

Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2

[Jazzer Dane]

I like it.
I assume that, in regards to static properties, the static keyword works
just as well as self and parent, correct?

On Thu, Oct 11, 2012 at 10:23 PM, Clint Priest  wrote:

> Alright, here is the updated RFC as per discussions for the last few days:
>
> https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
>
> If you could read it over, make sure I have all of your concerns correctly
> addressed and we can leave this open for the two week waiting period while
> I make the final code changes.
>
> -Clint
>
>

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

[Jazzer Dane]

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($value) {}
>
and

> private final get() {}
>
With no code in-between the braces, the functions are not accessible, not
extensible, and pointless. Thus we could arguably use them as alternatives
to the proposed read/write-only syntax.
But, in my previous emai,l I brought up the fact that this proposal isn't
that logically sound. The above lines of code don't exactly mean that
get/set aren't allowed... but at the same time, I don't know of any
scenarios where a developer would want to use private final get/set wherein
null is always returned or nothing is ever set.

The fact that this proposal is consistent with the language is a plus to
me. But I don't think it's enough - I don't like the logical
inconsistencies it brings.

If I were to vote between the two as to which gets implemented into PHP, I
would probably lean towards read/write-only, but I'm not a fan of either.
In the end, we need it to be logical. Good looking, consistent syntax is
nice, but having something behave even a little bit illogically is not at
all okay.

On Wed, Oct 10, 2012 at 7:59 PM, 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 understandable than:
>
> ** **
>
> public $hours {
>
> get() { ... }
>
> private final set($value) { … }
>
> }
>
> ** **
>
> The latter implies that it can be “set” within the right context
> (internally to the class), which is precisely the opposite of what is
> desired (read only).
>
> ** **
>
> *From:* Jazzer Dane [mailto:tbprogram...@gmail.com]
> *Sent:* Wednesday, October 10, 2012 9:18 PM
> *To:* Clint Priest
> *Cc:* internals@lists.php.net
>
> *Subject:* 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 technically saying it will always return null.
> private final set() {} is technically saying that setting doesn't do
> anything - but it still works.
>
> But I don't see any sane scenario where someone would want to do the
> above. Therefore, it may just be best to use them in place of the currently
> proposed read-only/write-only.
>
>  On Wed, Oct 10, 2012 at 5:35 PM, Clint Priest 
> wrote:
>
> 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 allowed.
> 2.  Preferred syntax for accessors should be "public set($value) { ... }"
> with no "magic" $value (with possible type hinting)
> 3.  Automatically implemented get; set; with auto-backing field should be
> eliminated as this is not necessary for PHP and is confusing most everyone.
> 4.  read-only / write-only keywords, keep them or get rid of them?  There
> is no directly suitable replacement but I believe a private final set() { }
> will take care of it, even though it much more verbose.
> 5.  Error handling for thrown exceptions should be made more appropriate
> for accessors
> 6.  The "truth" of reflection.  Should it reveal details internal to how
> PHP works on the inside or should it reflect the way PHP presents it as
> options?
>
> Did I miss anything?
>
>
> 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
>
> ** **
>

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

[Jazzer Dane]

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 technically saying it will always return null.
private final set() {} is technically saying that setting doesn't do
anything - but it still works.

But I don't see any sane scenario where someone would want to do the above.
Therefore, it may just be best to use them in place of the currently
proposed read-only/write-only.

On Wed, Oct 10, 2012 at 5:35 PM, Clint Priest  wrote:

> 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 allowed.
> 2.  Preferred syntax for accessors should be "public set($value) { ... }"
> with no "magic" $value (with possible type hinting)
> 3.  Automatically implemented get; set; with auto-backing field should be
> eliminated as this is not necessary for PHP and is confusing most everyone.
> 4.  read-only / write-only keywords, keep them or get rid of them?  There
> is no directly suitable replacement but I believe a private final set() { }
> will take care of it, even though it much more verbose.
> 5.  Error handling for thrown exceptions should be made more appropriate
> for accessors
> 6.  The "truth" of reflection.  Should it reveal details internal to how
> PHP works on the inside or should it reflect the way PHP presents it as
> options?
>
> Did I miss anything?
>
>
> 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
>

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

[Jazzer Dane]

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 {
> get() {
> if(!is_null($this->seconds)) {
> return $this->seconds;
> } else {
> return 10; // 10 is default
> }
> }
> }
> }
>
The above should work fine in many scenarios, right?
We could perhaps then claim that the issue may rather be that we need
access to the variable *$hours* itself inside of the get/set/etc functions,
which I think has been brought up before - though I'm not so sure how
sensible that is. Whether we need that or not is up in the air.


2) read-only and write-only is ugly. While this is a bias, I think we can
do better.

One idea I had is exactly what bernhard suggesting - using *final private
set() {}* to achieve read-only functionality.
My problem with this implementation is that it's not as logical as I'd
prefer. In my eyes, from a logical point of view, just the fact that set is
there means that it works. Thus it just so happens that, while setting the
variable doesn't error out, it does absolutely nothing.
While I don't see any real world scenarios where people would want this
behavior, I still am wrestling with this proposed implementation, as I
think that, logically speaking, set should work but just not do anything.
Whether or not this is illogical is arguably none of our concern - it's the
coder's concern. Hmm.

I'd definitely like to explore other alternatives to this solution.
Already proposed:

> public read-only $property {
> get() { ... }
> }
> public $property {
> get() { ... }
> final private set() {};
> }
>

I'm going to throw out some alternatives just for the sake of it. They may
be more illogical than I'd prefer, but I'm just trying to get the juices
flowing:

> public $property {
> get() { ... }
> final private set;
> }
> public $property {
> get() { ... }
> final private set();
> }
> public $property {
> get_only() { ... } // Same as get but implies read only; set not
> allowed to be defined. In case of set_only and get_only, top one has
> precedence.
> }
> public $property {
> set(read_only);
> get() { ... }
> }
> public $property {
> read_only; // or read_only();
> get() { ... }
> }
>


3) I'll agree with Leigh here:

> I don't like the fact that accessors and their associated properties are
> implemented as direct (yet slightly obfuscated/hidden) elements of the
> containing class. It's unintuitive (I'd even go as far as saying confusing).
>


4) In regards to array accessors, it'd be nice to have but not at all
necessary.

On Wed, Oct 10, 2012 at 2:29 AM, Leigh  wrote:

> 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) { ... }
> > offsetExists($offset) { ... }
> > }
>
> Definitely on the "nice to have" list.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

[Jazzer Dane]

I think Leigh brings up some important flaws to in the current RFC. What
Leigh is asking for does not appear to be possible, and in my opinion, it
should be.

I also agree with Rasmus, to a certain extent.
By putting only a getter/setter, the developer essentially sets the
property as read or write only. At first glance, there is no need for the
read-only or write-only keyword. Except... subclassing may or may not be an
issue.

By setting a property to read-only, it ensures that 'set' can never be set
by a subclass. Unless I redefine the entire property... or is that not even
possible? *The RFC isn't very clear but it appears that there is no way to
redefine the entire property, as if you define it in the subclass with only
get, then it will take set, isset, and unset from the parent class, correct?
* Though, that can be outright stopped by making the property final. But
then there is no point in having read/write-only.

>From what I can tell, read-only becomes useful if I extend the class and
want to partially modify the property.
Example:

> class A {
>   public $seconds = 3600;
>
>   public $hours {
> get() { return $this->seconds / 3600 };
>   }
> }
>
> class B extends A {
>   public $hours { // Maintains 'get' from class A
> set($value) { $this->seconds = $value; }
>   }
> }
>

^There's no way to stop the developer from doing that without read-only.

Also, if the property is public, what if an outside class tries to do this:

> class A {
>   public $seconds = 3600;
>
>   public $hours {
> get() { return $this->seconds / 3600 };
>   }
> }
>
> $object = new A();
> $object->hours = 100;
>
What happens then?

And similarly, how do we set a public property as a property accessor, hmm?

class A {
>   public $hours = 1;
> }
>
> $seconds = 20;
>
> $object = new A();
> $object->hours = { // Does this work?
>   get() { return $seconds; }
> };
>


There's definitely still some questions to answer before this RFC is ready.

On Tue, Oct 9, 2012 at 10:19 AM, Leigh  wrote:

> > RFC Document:
> https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
>
> public $property {
> set { $this->property = ($this->property*2)+$value }
> get;
> }
>
> How do I reference the property being set from within the function? The way
> I have done it in the example will cause recursion? How can I assign to
> "self"?
>
> How do I set the default value of $property when the object is created?
> Surely I don't have to reverse the set accessors logic and set the inverse
> in __construct?
>

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

[Jazzer Dane]

Christian, I think a majority of your concerns are all for none.
>From top to bottom:

- Extra indention: This is definitely a bias and is only moderately
relevant while documenting this feature.

- You *can* declare a public getter and private setter, or vice versa, or
whatever you want. This is in the RFC. See "Asymmetric Accessor
Accessibility."

- "If we ever get return type hinting/checks then we needn't consider how
the syntax has to look" From what I know, this isn't planned for PHP 5.5
and any proposals for it have been largely ignored. Return type hinting
won't help when setting either, although it would help with getting. All
that being said, type hinting aside, the syntax I proposed is, in my
opinion, the most consistent out of any other proposal thus far (arguably
aside from yours, I'll go over that momentarily).

- "We must deal with two different syntaxes for the same thing" I don't
quite understand what you mean here, unless you're talking about braces
inside braces. It seems your code examples make your intended point here a
bit clearer, though.

- "IDE's, documentation tools, static analyses tools or similar tools have
a huge effort to implement this syntax. With the method syntax it's only a
small effort" While we want to strive to keep a clean and consistent
syntax, I don't think molding to whatever is easiest for IDE's is a good
idea.

- "We have to create new rules about how the documentation for this syntax
should look like" From my point of view, this isn't so much a concern as a
to-do item later on.


On to your proposal:

I'm not a fan of this:

> public function get hours() {}
>
This is adding another keyword after function, which is arguably more
inconsistent than some previous proposals.

I'm sort of okay with this:

> public get hours() {}
>
Replacing function with get/set/isset/unset... but it still seems a bit too
inconsistent and insensible. Replacing the function keyword with the name
of a preexisting function? I also do not like how the accessors are
separated from one another, which is not the case with the previous
proposals.

All in all, I still prefer my previous proposal to this.

On Tue, Oct 9, 2012 at 12:46 AM, Christian Kaps
wrote:

> Hi,
>
> typehinting should definitely be available for this feature. But I have
> another question. Why not go more consistent with the rest of the language?
> I have mentioned this previously as the first proposal comes up on the
> list. In my opinion the AS3 getter and setter syntax(
> http://help.adobe.com/**en_US/ActionScript/3.0_**ProgrammingAS3/**
> WS5b3ccc516d4fbf351e63e3d118a9**b90204-7f30.html#**
> WS5b3ccc516d4fbf351e63e3d118a9**b90204-7fcb<http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f30.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7fcb>)
> fits more into the language as the proposed one.
>
> Here are my concerns:
> - I do not like the extra indentation level and it's ugly to document (OK,
> this is a personal preference)
> - It isn't possible to declare a private setter and a public getter, as it
> is possible with methods
> - If we ever get return type hinting/checks then we needn't consider how
> the syntax has to look
> - We must deal with two different syntaxes for the same thing, because
> both are methods
> - IDE's, documentation tools, static analyses tools or similar tools have
> a huge effort to implement this syntax. With the method syntax it's only a
> small effort
> - We have to create new rules about how the documentation for this syntax
> should look like
>
> For me the following syntax seems more consistent with the rest of PHP:
>
> public get hours() {}
> public set hours(DateTime $dateTime) {}
> public isset hours() {}
> public unset hours() {}
>
> Or:
>
> public function get hours() {}
> public function set hours(DateTime $dateTime) {}
> public function isset hours() {}
> public function unset hours() {}
>
> Or:
>
> public function get $hours() {}
> public function set $hours(DateTime $dateTime) {}
> public function isset $hours() {}
> public function unset $hours() {}
>
> Cheers,
> Christian
>
> Am 09.10.2012 05:08, schrieb Jazzer Dane:
>
>> While I understand your concern with set being the only keyword using (),
>> and even agree it's a bit problematic, I see a big problem with using
>> $value.
>>
>> Even if $value internally makes sense due to something along the lines of
>> *
>> __setHours($value)* {} being equal to *set {}*, I think using $value
>>
>> without it ever being defined in the developer's code is not at all a good
>> idea.
>> If I see $value in t

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

[Jazzer Dane]

While I understand your concern with set being the only keyword using (),
and even agree it's a bit problematic, I see a big problem with using
$value.

Even if $value internally makes sense due to something along the lines of *
__setHours($value)* {} being equal to *set {}*, I think using $value
without it ever being defined in the developer's code is not at all a good
idea.
If I see $value in the code, I'll logically look for where it was defined,
and when I don't see it anywhere else in the code, things are going to very
quickly get confusing.
Our best option to combat this confusion is, in my eyes, putting a note in
the documentation. That's not enough.

A similar alternative to using $value that I'd argue would be much more
sensible would be to, as Denis mentioned, use either a magic constant or a
superglobal.

As I mentioned previously, I would rather go with the set($value) {} syntax.

Now, back to the part where I agree with you - the inconsistency wherein
set has () that denote it is a method but get, isset, and unset do not. I
see this inconsistency as something problematic enough to warrant a
solution.

We could go with the following:
public $Hours {
  get() { ... }
  set($value) { ... }
  isset() { ... }
  unset() { ... }
}

Yes, we now have a little bit more meat on the syntax, but in this case, I
don't think that it's all that bad. Here's two reasons why:
1) Adding parenthesis denotes that they are all functions - which they are!
If anything, adding parenthesis to all of them makes the implementation *
more* sensible.
2) It's *only* two more characters per function. On top of that, in my
opinion, this syntax is not "ugly". In fact, as I just mentioned - this
implementation is arguably *more* consistent with the rest of PHP.

On Mon, Oct 8, 2012 at 6:10 PM, Clint Priest  wrote:

> Seems a fair amount of people would like it with a definable parameter
> name, though the original RFC I based mine off of is more than 4 years old
> (mine is over a year old already).
>
> The $value is precisely chosen because it is exactly the way C# operates
> and the original author thought to keep it the same as another well-known
> language (why re-invent new syntax for no reason).
>
> That being said, javascript does indeed allow it, my concern then would be
> would we have the parameterized syntax only for set() and not get, isset or
> unset?
>
> If we do have them for all of them, it's a lot of extra characters with no
> real need.
>
> I definitely favor set($value) over a magic $Hours for the $Hours
> property, but I personally see no problem with the $value, it's not magic
> it's a locally defined variable.
>
> Internally, this:
>public $Hours {
>   get { ... }
>   set { ... }
>}
>
> Is implemented as standard functions, while they are hidden through
> reflection, these functions exist (as a result of the above example):
>
> public __getHours() { ... }
> public __setHours($value) { ... }
>
> Lastly, with regards to JavaScript style getters/setters, I don't think
> I've ever cared what the variable name was, I typically just do something
> like:
>
> set blah(x) { ... } <-- x is fairly irrelevant and similarly the use of
> $value is fairly irrelevant.   Thoughts?
>
> > -Original Message-
> > From: Jazzer Dane [mailto:tbprogram...@gmail.com]
> > Sent: Monday, October 08, 2012 5:32 PM
> > To: Benjamin Eberlei
> > Cc: Aaron Holmes; internals@lists.php.net
> > Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
> >
> > I agree.
> > It's more consistent than the $Hours solution and we don't have to add
> another superglobal or magic constant, which is quite nice. The
> > typehinting is a big plus as well.
> >
> > On Mon, Oct 8, 2012 at 3:26 PM, Benjamin Eberlei  >wrote:
> >
> > > The set() one is really nice with the typehints.
> > >
> > > On Tue, Oct 9, 2012 at 12:19 AM, Aaron Holmes 
> > > wrote:
> > >
> > > > On 10/8/12 1:07 PM, Denis Portnov wrote:
> > > >
> > > >> 08.10.2012 15:52, Clint Priest пишет:
> > > >>
> > > >>>  public $Hours {
> > > >>>  get { return $this->Seconds / 3600; }
> > > >>>  set { $this->Seconds = $value; }
> > > >>>  isset<http://www.php.net/isset**>  { return isset<
> > > >>> http://www.php.net/isset**>($this->Seconds); }
> > > >>>  unset<http://www.php.net/unset**>  { unset<
> > > >>> http://www.php.net/unset**>($this->Seconds); }
> > > >>> 

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

[Jazzer Dane]

I agree.
It's more consistent than the $Hours solution and we don't have to add
another superglobal or magic constant, which is quite nice. The typehinting
is a big plus as well.

On Mon, Oct 8, 2012 at 3:26 PM, Benjamin Eberlei wrote:

> The set() one is really nice with the typehints.
>
> On Tue, Oct 9, 2012 at 12:19 AM, Aaron Holmes 
> wrote:
>
> > On 10/8/12 1: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<
> >>> http://www.php.net/isset**>($this->Seconds); }
> >>>  unset  { unset<
> >>> http://www.php.net/unset**>($this->Seconds); }
> >>>  }
> >>>
> >>
> >>
> >> Hi Clint,
> >>
> >> I've noticed some magic variable '$value' is introduced. And except for
> >> superglobals I guess there is no such thing in PHP, so it looks bit
> >> puzzling to me. I'd suggest on of the following:
> >>
> >>
> >> - setter resambles setter method, wich also allows typehinting
> >> public $Hours {
> >> set ($value) { $this->Seconds = $value * 3600; }
> >> }
> >>
> >> public $Hours {
> >> set (DateTime $dateTime) { $this->Seconds =
> >> $dateTime->getTimestamp(); }
> >> }
> >>
> >>  This seems like the cleanest method, in my opinion. Javascript does
> this
> > for object prototypes:
> > http://ejohn.org/blog/**javascript-getters-and-**setters/<
> http://ejohn.org/blog/javascript-getters-and-setters/>
> >
> >
> >>
> >> What do you think?
> >>
> >> Thanks
> >> Denis
> >>
> >>
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>