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 <lei...@gmail.com> wrote:
> On 10 October 2012 08:46, Bernhard Schussek <bschus...@gmail.com> 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
>
>
