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 reference
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
t 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 appli
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 th
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 r
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
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, al
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
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
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 acc
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 cl
#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 no
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) Ther
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/
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 wrote:
> Alright, here is the updated RFC as per discussions for the last few days:
>
> https://wiki.php.net/rfc/propertyge
>
> ** **
>
> Is infinitely more readable and understandable than:
>
> ** **
>
> public $hours {
>
> get() { ... }
>
> private final set($value) { … }
>
> }
>
> ** **
>
> The latter
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
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 {
>
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
gt;
> 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
nctions 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 somethi
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,
23 matches
Mail list logo
