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 cpri...@zerocue.com wrote:
I'm opening up several new threads to get discussion going on the
remaining being debated
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
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
should probably
open up another discussion thread for this subject, though.
On Sat, Oct 20, 2012 at 2:52 AM, Nikita Popov nikita@gmail.com wrote:
On Sat, Oct 20, 2012 at 11:31 AM, Jazzer Dane tbprogram...@gmail.com
wrote:
The final keyword is used, especially in sizable OOP applications
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
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)
#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
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
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.
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 -
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,
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
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
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
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 cpri...@zerocue.com wrote:
Alright, here is the updated RFC as per discussions for the last few days:
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 {
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
() { ... }
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
() {}
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
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
/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
21 matches
Mail list logo
