# private, protected, readonly, public

- Thread: https://externals.io/message/23291
- Original archive: https://news-web.php.net/php.internals/23291
- Started by Jason Garber on 2006-05-11T23:35:36+00:00
- Messages: 89
- Page 1 of 4: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/23291.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #23291 — Jason Garber — 2006-05-11T23:35:36+00:00

URL: https://externals.io/message/23291#23291

Hello internals,

  __get() and __set() are great, but 90% of the time, I find myself
  using them to create public readonly properties.

  The only problem with this is it is horridly inefficient, consuming
  at least 1 function call and one switch statement (or equiv) per
  property read.

  Would it be possible to create a new object property attribute:
    readonly

  class xx
  {
     readonly $bar;
  }

  $o = new xx();

  $o->bar = 10;
> > […]
  

  This way, PHP would allow reading (as if it were public), but only
  allow writing from within the class.

  I think it could really boost performance of complicated application
  logic that wishes to enforce good visibility.

  Comments?

  PS. What brought this up was some serious performance issues in a
  piece of code that I am working with - most of which can be tied
  back to __get() performance.
  
-- 
Best regards,
 Jason Garber                      mailto:jason@ionzoft.com
 IonZoft, Inc.

---

## #23302 — Ron Korving — 2006-05-12T12:34:18+00:00

URL: https://externals.io/message/23291#23302 · In reply to: #23291

In C++ you'd use private for this. All object members are readable, but 
modifyability depends on the relation between the caller and the object. I 
don't quite understand why PHP is doing it differently.

- Ron


"Jason Garber" <jason@ionzoft.com> schreef in bericht 
news:785810036.20060511193536@ionzoft.com...
> Hello internals,
>
>  __get() and __set() are great, but 90% of the time, I find myself
>  using them to create public readonly properties.
>
>  The only problem with this is it is horridly inefficient, consuming
>  at least 1 function call and one switch statement (or equiv) per
>  property read.
>
>  Would it be possible to create a new object property attribute:
>    readonly
>
>  class xx
>  {
>     readonly $bar;
>  }
>
>  $o = new xx();
>
>  $o->bar = 10;
> > […]
>
>
>  This way, PHP would allow reading (as if it were public), but only
>  allow writing from within the class.
>
>  I think it could really boost performance of complicated application
>  logic that wishes to enforce good visibility.
>
>  Comments?
>
>  PS. What brought this up was some serious performance issues in a
>  piece of code that I am working with - most of which can be tied
>  back to __get() performance.
>
> -- 
> Best regards,
> Jason Garber                      mailto:jason@ionzoft.com
> IonZoft, Inc.

---

## #23308 — Andi Gutmans — 2006-05-12T15:34:07+00:00

URL: https://externals.io/message/23291#23308 · In reply to: #23291

I can see where it could come in handy but I honestly think it'd be bloat.
We have to relax with the OO features because the increased code size 
has already made it harder to maintain and it has the potential to 
make PHP far more complicated than what it should be.

At 04:35 PM 5/11/2006, Jason Garber wrote:
>Hello internals,
>
>   __get() and __set() are great, but 90% of the time, I find myself
>   using them to create public readonly properties.
>
>   The only problem with this is it is horridly inefficient, consuming
>   at least 1 function call and one switch statement (or equiv) per
>   property read.
>
>   Would it be possible to create a new object property attribute:
>     readonly
>
>   class xx
>   {
>      readonly $bar;
>   }
>
>   $o = new xx();
>
>   $o->bar = 10;
> > […]
>
>
>   This way, PHP would allow reading (as if it were public), but only
>   allow writing from within the class.
>
>   I think it could really boost performance of complicated application
>   logic that wishes to enforce good visibility.
>
>   Comments?
>
>   PS. What brought this up was some serious performance issues in a
>   piece of code that I am working with - most of which can be tied
>   back to __get() performance.
>
>--
>Best regards,
>  Jason Garber                      mailto:jason@ionzoft.com
>  IonZoft, Inc.

---

## #23309 — Bastian Grupe — 2006-05-12T15:40:20+00:00

URL: https://externals.io/message/23291#23309 · In reply to: #23291

Jason Garber wrote:
> 
>   Would it be possible to create a new object property attribute:
>     readonly
> 
>   class xx
>   {
>      readonly $bar;
>   }
> 
>   $o = new xx();
> 
>   $o->bar = 10;
> > […]
>   
> 
>   This way, PHP would allow reading (as if it were public), but only
>   allow writing from within the class.

Uhh... how about using private and only using a "regular"
getter (the Java-style) and no setter?

    class xx
    {
       private $bar;

       public getBar() { return $bar; }
    }

    $o = new xx();

    $o->bar = 10; // already emits FATAL ERROR

---

## #23311 — Sara Golemon — 2006-05-12T16:14:20+00:00

URL: https://externals.io/message/23291#23311 · In reply to: #23308

> > […]
>I can see where it could come in handy but I honestly think it'd be bloat.
> We have to relax with the OO features because the increased code size has 
> already made it harder to maintain and it has the potential to make PHP 
> far more complicated than what it should be.
>
An extension could accomplish this by exporting an interface which overrides 
the object's read_property() method.  One could "flag" which properties are 
allowed to be accessed r/o by giving them a distinct name e.g.:

class foo implements ReadOnlyProperties {
    private $__ro__bar;
    function __construct($val) {
        $this->__ro__bar = $val;
    }
}

$f = new foo(123);
var_dump($f->bar);

The special getter sees that bar isn't in the properties table and looks for 
__ro__bar instead (overriding visibility restrictions in the process). 
Since there's no write_property override, the prop remains unwritable from 
outside of the object.

-Sara

---

## #23312 — Hartmut Holzgraefe — 2006-05-12T17:23:54+00:00

URL: https://externals.io/message/23291#23312

Etienne Kneuss wrote:
> 2) It only requires a bit of discipline, not to edit the properties you
> want to be readonly.

well, then we don't need private/protected/public at all,
as it only requires a bit of discipline not to access the
properties you want to be visible to the class or its
children only?

-- 
Hartmut Holzgraefe, Senior Support Engineer                            .
MySQL AB, www.mysql.com

Are you certified? http://www.mysql.com/training/certification

---

## #23313 — Hartmut Holzgraefe — 2006-05-12T17:32:57+00:00

URL: https://externals.io/message/23291#23313 · In reply to: #23309

Bastian Grupe wrote:
> Uhh... how about using private and only using a "regular"
> getter (the Java-style) and no setter?
> 
>    class xx
>    {
>       private $bar;
> 
>       public getBar() { return $bar; }
>    }

i think you're missing the point, the idea is to *not*
have to write that extra getter line ... less typing
*and* less error prone ... and easier to read, too IMHO

You didn't want to return $bar in your example, you wanted
to return $this->bar so you already ran into one of the
issues here ;)

-- 
Hartmut Holzgraefe, Senior Support Engineer                            .
MySQL AB, www.mysql.com

Are you certified? http://www.mysql.com/training/certification

---

## #23314 — Bastian Grupe — 2006-05-12T17:41:02+00:00

URL: https://externals.io/message/23291#23314 · In reply to: #23313

Hartmut Holzgraefe wrote:
> Bastian Grupe wrote:
> 
> You didn't want to return $bar in your example, you wanted
> to return $this->bar so you already ran into one of the
> issues here ;)
> 

Blame my recent use of Java here ;-)

Well, I think the whole point of ppp is to having to use setters and 
getters consistently.

I personally wouldn't like to be able to access some members which are 
private, and not others. It just *feels* wrong.

And I don't know whether or not less typing is really a good argument in 
this situation (think unreadable code in shortcut-ish programming 
languages).

-- Bastian

---

## #23315 — Hartmut Holzgraefe — 2006-05-12T18:09:24+00:00

URL: https://externals.io/message/23291#23315 · In reply to: #23314

Bastian Grupe wrote:
> Blame my recent use of Java here ;-)
> 
> Well, I think the whole point of ppp is to having to use setters and 
> getters consistently.

i'm going to blame your use of Java for this one, ppp is way older
than the setter/getter fashion and as far as i remember the main
reason to introduce the setter/getter pattern into java was to
have a standard way for Java IDEs to provide access to Java Bean
properties in property dialogs in their GUI design tools

> I personally wouldn't like to be able to access some members which are 
> private, and not others. It just *feels* wrong.

Think of it as a more fine grained permission system, like unix
file attributes. Reading and writing a property value are two
different operations and it makes sense to distinguish access
rights not only by ownership but also by type of operation.

> And I don't know whether or not less typing is really a good argument in 
> this situation (think unreadable code in shortcut-ish programming 
> languages).

Less typing is not an argument by itself, else we'd all do APL

But less typing is less error prone (and no, plese *don't* mention
auto-completion here ;), it can be less readable, too, and in this
special case it spreads information that should be in one place.
Maintainability can become an issue, too.

Take a look at typical PHP class implementations: they have
all properties on top followed by the member functions. So to find
out whether a private property is really provite or whether it has
a getter or even a setter, too, i would have to browse the full
class code.

   class example {
     private $foo;
     private $bar;
     [... more properties ...]

     function __construct() {...}
     function __destruct() {...}

     function getFoo() {...}

     [... more code ...]
   }

So $foo is readonly here and $bar is really private. Or wait,
maybe we have just overlooked getBar()?

With

   readonly $foo;

on the other hand you have all the information in one place.

If you want to go the getter/setter path all the way then we
wouldn't need all the ppp stuff anymore alltogether, we would
just make everything private and have the getter and setter
decide (using instanceof on $this etc.) the access rights.


-- 
Hartmut Holzgraefe, Senior Support Engineer                            .
MySQL AB, www.mysql.com

Are you certified? http://www.mysql.com/training/certification

---

## #23316 — itrebal@gmail.com — 2006-05-12T19:16:27+00:00

URL: https://externals.io/message/23291#23316 · In reply to: #23315

It seems to me this would be a great option to add. How difficult would it
be? Would it take significant editing of the source code? I don't see the
issue in adding it - seems like it would have plenty of places to be used.
Though, if it is added, the name 'readonly' seems a little misleading. It
gives off the idea of being able to set it, and not edit again, and not only
being able to edit it inside the class.


>
> Bastian Grupe wrote:
> > […]
>
> i'm going to blame your use of Java for this one, ppp is way older
> than the setter/getter fashion and as far as i remember the main
> reason to introduce the setter/getter pattern into java was to
> have a standard way for Java IDEs to provide access to Java Bean
> properties in property dialogs in their GUI design tools
>
> > […]
>
> Think of it as a more fine grained permission system, like unix
> file attributes. Reading and writing a property value are two
> different operations and it makes sense to distinguish access
> rights not only by ownership but also by type of operation.
>
> > […]
>
> Less typing is not an argument by itself, else we'd all do APL
>
> But less typing is less error prone (and no, plese *don't* mention
> auto-completion here ;), it can be less readable, too, and in this
> special case it spreads information that should be in one place.
> Maintainability can become an issue, too.
>
> Take a look at typical PHP class implementations: they have
> all properties on top followed by the member functions. So to find
> out whether a private property is really provite or whether it has
> a getter or even a setter, too, i would have to browse the full
> class code.
>
>    class example {
>      private $foo;
>      private $bar;
>      [... more properties ...]
>
>      function __construct() {...}
>      function __destruct() {...}
>
>      function getFoo() {...}
>
>      [... more code ...]
>    }
>
> So $foo is readonly here and $bar is really private. Or wait,
> maybe we have just overlooked getBar()?
>
> With
>
>    readonly $foo;
>
> on the other hand you have all the information in one place.
>
> If you want to go the getter/setter path all the way then we
> wouldn't need all the ppp stuff anymore alltogether, we would
> just make everything private and have the getter and setter
> decide (using instanceof on $this etc.) the access rights.
>
>
> --
> Hartmut Holzgraefe, Senior Support Engineer                            .
> MySQL AB, www.mysql.com
>
> Are you certified? http://www.mysql.com/training/certification
>
> --
> 
> 
>
>


-- 
------------------------------------
Graham Christensen
www.itrebal.com
www.iamgraham.net

---

## #23317 — Jason Garber — 2006-05-12T20:44:35+00:00

URL: https://externals.io/message/23291#23317 · In reply to: #23316

Hello,

  PHP implements many features, and skips many features.  I think the
  rule of thumb needs to be that if a feature is implemented, finish
  it.

  For example, if you provide __get() and __set(), provide an
  efficient way of handling the normal use case.

  If you start triggering an `E_NOTICE` when an undefined variable is
  accessed, then provide an easy way to access variables that may or
  may not be set.

  If you provide a __tostring() method, then finish it so that is gets
  called when an object is cast to a string, concatenated with a
  string, as well as being output with echo, print.

  There are a lot of casual users of PHP.  There are also the people
  out there who are buying the Zend products, buying the MySQL support
  contracts, using PHP at Yahoo! -- the people who have chosen to use
  PHP OVER Java/.NET/Perl, because it is a great language -- the
  people who need the completed features because they are running
  multi-million-dollar businesses on this platform.


  Take a step back and truly evaluate why someone in a demanding
  situation might want every bit of performance and readability that
  they can squeeze out of *existing* language features.

  I'm not talking about adding hundreds of new features, or turning
  PHP into the next java.  It's about real business cases.

  It's not about what YOU WOULD NOT use, it's about what a lot of
  people need.

-- 
Best regards,
 Jason Garber                           mailto:jason@ionzoft.com
 IonZoft, Inc.
 
Friday, May 12, 2006, 3:16:27 PM, you wrote:

igc> It seems to me this would be a great option to add. How difficult would it
igc> be? Would it take significant editing of the source code? I don't see the
igc> issue in adding it - seems like it would have plenty of places to be used.
igc> Though, if it is added, the name 'readonly' seems a little misleading. It
igc> gives off the idea of being able to set it, and not edit again, and not only
igc> being able to edit it inside the class.

igc> On 5/12/06, Hartmut Holzgraefe <hartmut@php.net> wrote:
> > […]

---

## #23318 — Andi Gutmans — 2006-05-12T21:06:56+00:00

URL: https://externals.io/message/23291#23318 · In reply to: #23317

I can take any feature in PHP and add features :)

At 01:44 PM 5/12/2006, Jason Garber wrote:
>Hello,
>
>   PHP implements many features, and skips many features.  I think the
>   rule of thumb needs to be that if a feature is implemented, finish
>   it.
>
>   For example, if you provide __get() and __set(), provide an
>   efficient way of handling the normal use case.
>
>   If you start triggering an `E_NOTICE` when an undefined variable is
>   accessed, then provide an easy way to access variables that may or
>   may not be set.
>
>   If you provide a __tostring() method, then finish it so that is gets
>   called when an object is cast to a string, concatenated with a
>   string, as well as being output with echo, print.
>
>   There are a lot of casual users of PHP.  There are also the people
>   out there who are buying the Zend products, buying the MySQL support
>   contracts, using PHP at Yahoo! -- the people who have chosen to use
>   PHP OVER Java/.NET/Perl, because it is a great language -- the
>   people who need the completed features because they are running
>   multi-million-dollar businesses on this platform.
>
>
>   Take a step back and truly evaluate why someone in a demanding
>   situation might want every bit of performance and readability that
>   they can squeeze out of *existing* language features.
>
>   I'm not talking about adding hundreds of new features, or turning
>   PHP into the next java.  It's about real business cases.
>
>   It's not about what YOU WOULD NOT use, it's about what a lot of
>   people need.
>
>--
>Best regards,
>  Jason Garber                           mailto:jason@ionzoft.com
>  IonZoft, Inc.
>
>Friday, May 12, 2006, 3:16:27 PM, you wrote:
>
>igc> It seems to me this would be a great option to add. How 
>difficult would it
>igc> be? Would it take significant editing of the source code? I don't see the
>igc> issue in adding it - seems like it would have plenty of places 
>to be used.
>igc> Though, if it is added, the name 'readonly' seems a little misleading. It
>igc> gives off the idea of being able to set it, and not edit again, 
>and not only
>igc> being able to edit it inside the class.
>
>igc> On 5/12/06, Hartmut Holzgraefe <hartmut@php.net> wrote:
> > […]

---

## #23319 — Etienne Kneuss — 2006-05-12T21:07:33+00:00

URL: https://externals.io/message/23291#23319 · In reply to: #23312

Yes, I also consider the visibility as a candy functionality.

> Etienne Kneuss wrote:
> > […]
> 
> well, then we don't need private/protected/public at all,
> as it only requires a bit of discipline not to access the
> properties you want to be visible to the class or its
> children only? 


-- 
Etienne Kneuss

http://www.colder.ch/
colder@php.net

---

## #23320 — Gareth Ardron — 2006-05-12T21:14:40+00:00

URL: https://externals.io/message/23291#23320 · In reply to: #23319

Etienne Kneuss wrote:
> Yes, I also consider the visibility as a candy functionality.
>
>   
> > […]

It's only candy functionality when you're not in a position of possibly 
having to hand the application you've written over to a bunch of 
developers you don't know, who probably won't read the docs and will do 
things the wrong way.

Having visibility in this case really, really helps - and more than 
anything, it covers my back when they screw up. Yeah, if all you're 
writing is small apps, you're not going to have an issue - or if you're 
only using a handful of developers, it won't be an issue, but it's a 
very good thing when the future development cycle of a product isn't clear.

---

## #23321 — D. Dante Lorenso — 2006-05-12T21:33:05+00:00

URL: https://externals.io/message/23291#23321 · In reply to: #23318

Andi Gutmans wrote:
> I can take any feature in PHP and add features :)

Is that an offer ;-)?  I've got a couple you can add, lol.

Dante
>
> At 01:44 PM 5/12/2006, Jason Garber wrote:
> > […]

---

## #23324 — Rasmus Lerdorf — 2006-05-12T21:57:48+00:00

URL: https://externals.io/message/23291#23324 · In reply to: #23317

Jason Garber wrote:
>   There are a lot of casual users of PHP.  There are also the people
>   out there who are buying the Zend products, buying the MySQL support
>   contracts, using PHP at Yahoo! -- the people who have chosen to use
>   PHP OVER Java/.NET/Perl, because it is a great language -- the
>   people who need the completed features because they are running
>   multi-million-dollar businesses on this platform.

Multi-billion in the case of Yahoo! and we can speak for ourselves.  The 
things you listed are irrelevant to us.  We have much bigger fish to fry 
and we are doing so.

-Rasmus

---

## #23326 — Brandon Fosdick — 2006-05-12T23:43:38+00:00

URL: https://externals.io/message/23291#23326 · In reply to: #23291

Jason Garber wrote:
>   Would it be possible to create a new object property attribute:
>     readonly

Why not make it a little more generic? Say, make readonly an attribute that applies to the ppp tags as opposed to making it a new access class. 

Eg. if a member is 'public readonly' then it's read/write for private and protected, but read-only in a public context. Similarly, 'protected readonly' is read/write in a private context, read-only in protected and not visible in public. That would make 'private readonly' read-only for private methods, and not visible to anything else, which is probably only useful for properties generated by extensions.

Or is this what you're proposing and I'm just being dense?

---

## #23328 — Marcus Boerger — 2006-05-13T09:27:34+00:00

URL: https://externals.io/message/23291#23328

Hello Etienne,

Friday, May 12, 2006, 2:11:38 PM, you wrote:

> Hi,

> my 2c:

> 1) it shouldn't replace the visibility definition: we could also have
> protected readonly properties.

same here visibility and read/write control are two seperate things.

> 3) how would you check if the property if readonly ? Trying it could
> result to a Fatal error as you wanted. You would then need a
> isReadonly() method/function: the function call wouldn't be spared.

We could add this to reflection api easily.

Best regards,
 Marcus

---

## #23329 — Marcus Boerger — 2006-05-13T09:34:35+00:00

URL: https://externals.io/message/23291#23329 · In reply to: #23311

Hello Sara,

  while all what you wrote is doable i'd suggest a slightly different
approach. If the name of the variable is prefixed with "r_" and written
from outside the class an error will be issued.

There's only one thing to be considered. The proposal cannot work for
overloaded internal objects like those in ext/dom for example.

Friday, May 12, 2006, 6:14:20 PM, you wrote:

> > […]
> An extension could accomplish this by exporting an interface which overrides
> the object's read_property() method.  One could "flag" which properties are 
> allowed to be accessed r/o by giving them a distinct name e.g.:

> class foo implements ReadOnlyProperties {
>     private $__ro__bar;
>     function __construct($val) {
>         $this->__ro__bar = $val;
>     }
> }

> $f = new foo(123);
> var_dump($f->bar);

> The special getter sees that bar isn't in the properties table and looks for
> __ro__bar instead (overriding visibility restrictions in the process). 
> Since there's no write_property override, the prop remains unwritable from 
> outside of the object.

> -Sara 




Best regards,
 Marcus

---

## #23333 — Hartmut Holzgraefe — 2006-05-13T15:31:57+00:00

URL: https://externals.io/message/23291#23333 · In reply to: #23302

Ron Korving wrote:
> In C++ you'd use private for this. All object members are readable, ...

Could you elaborate on this?

-- 
Hartmut Holzgraefe, Senior Support Engineer                            .
MySQL AB, www.mysql.com

Are you certified? http://www.mysql.com/training/certification

---

## #23335 — Ron Korving — 2006-05-13T18:52:39+00:00

URL: https://externals.io/message/23291#23335 · In reply to: #23333

My bad, you are absolutely right, I must be confused with another language,
but I wonder which one.... odd.

Ron


"Hartmut Holzgraefe" <hartmut@php.net> wrote in message
news:4465FBED.8070205@php.net...
> Ron Korving wrote:
> > […]
>
> Could you elaborate on this?
>
> -- 
> Hartmut Holzgraefe, Senior Support Engineer                            .
> MySQL AB, www.mysql.com
>
> Are you certified? http://www.mysql.com/training/certification

---

## #23336 — Marcus Boerger — 2006-05-13T23:18:13+00:00

URL: https://externals.io/message/23291#23336 · In reply to: #23335

Hello Ron,

  hehe, maybe confused with delphi or borlands c++ additons? Speaking of
which before we add 'readonly' we should go for full property support but
on the other hand that might be a little bit too much until php is used
with code generators and gui designers where code inspectors execute and
manipulate source/code while developing. Ups wrong tool....

regards
marcus

Saturday, May 13, 2006, 8:52:39 PM, you wrote:

> My bad, you are absolutely right, I must be confused with another language,
> but I wonder which one.... odd.

> Ron


> "Hartmut Holzgraefe" <hartmut@php.net> wrote in message
> news:4465FBED.8070205@php.net...
> > […]




Best regards,
 Marcus

---

## #23337 — Alan Knowles — 2006-05-14T01:59:20+00:00

URL: https://externals.io/message/23291#23337 · In reply to: #23313

Definatly would love to see readonly, It would remove 1000's of lines of 
useless code from 100's of projects - which might make a few more public 
PHP projects readable ;)
It replaces pointless giberish with something explicit clean and elegant..

Looks alot tidier than getters, or __get kludges.

Regards
Alan
Hartmut Holzgraefe wrote:

> Bastian Grupe wrote:
>
> > […]
>
>
> i think you're missing the point, the idea is to *not*
> have to write that extra getter line ... less typing
> *and* less error prone ... and easier to read, too IMHO
>
> You didn't want to return $bar in your example, you wanted
> to return $this->bar so you already ran into one of the
> issues here ;)

---

## #23339 — Jason Garber — 2006-05-14T02:34:03+00:00

URL: https://externals.io/message/23291#23339 · In reply to: #23328

Hello Marcus,

  class x
  {
     public readonly $xyz;
     protected readonly $abc;
  }

  Definitions:
  - public readonly    - outside class can only read, not write.
  - protected readonly - subclass can only read, not write.
  - private readonly   - does not make sense - do not support.

  How difficult would it be to build this into the PHP engine?

-- 
Best regards,
 Jason                            mailto:jason@ionzoft.com

Saturday, May 13, 2006, 5:27:34 AM, you wrote:

MB> Hello Etienne,

MB> Friday, May 12, 2006, 2:11:38 PM, you wrote:

> > […]

> > […]

> > […]

MB> same here visibility and read/write control are two seperate things.

> > […]

MB> We could add this to reflection api easily.

MB> Best regards,
MB>  Marcus

---

## #23340 — Jeff Moore — 2006-05-14T04:24:33+00:00

URL: https://externals.io/message/23291#23340 · In reply to: #23336

>   hehe, maybe confused with delphi or borlands c++ additons? Speaking 
> of
> which before we add 'readonly' we should go for full property support 
> but
> on the other hand that might be a little bit too much until php is used
> with code generators and gui designers where code inspectors execute 
> and
> manipulate source/code while developing.

Hi Marcus,

Full property support is high on my wishlist for 6.0. I was a Delphi 
programmer for 5 years and miss properties.  C#, Ruby, and Java all 
have built in property support with accessor methods, or at least a 
single standard implementation that all the tools can get behind.  
__get and __set leave you in complete limbo for both source code and 
reflection based tools.  I think the language support has to come 
before the tools.

I think this can be implemented by adding a getter and setter field to 
zend_property_info, then checking for it in zend_std_read_property, 
etc.  Although, I'm sure there's more to it than that.  Such an 
implementation would probably be 3 to 4 times faster than __get().  No 
switch, no $name parameter, perhaps no guard logic.  Checking for a 
getter or setter in zend_property_info would be a fast boolean test on 
a data structure thats already available, so I believe there would be 
little overhead.

Here are a few use cases and syntax suggestions...

A. Declaring a property with accessor methods:

public $foo read getFoo write setFoo;

B. Read only property with accessor method could be declared:

public $foo read getFoo;

C. A shortcut notation could automatically generate the accessor method 
based on another property:

public $foo read $_foo;
// internally generated method ala C# property implementation:
// public function __get_foo() { return $this->$_foo; }

D. Similar to read only, you could have split visibility, for example, 
a public getter and a protected setter:

public $foo read getFoo write protected setFoo;  // Handy use case, not 
crazy about this syntax
public function getFoo() { return $this->_foo; }
protected function setFoo($value) { $this->_foo = $value }

E. To avoid warnings, declare the internal storage, too:

public $foo read $_foo write setFoo, protected $_foo;
public $foo read $_foo, protected $_foo;	// readonly

F. Properties with accessor methods cannot be directly initialized.  
Their internal storage can, however:

public $foo read $_foo write setFoo, protected $_foo = 'bar';

G. calling unset() on a property with accessor methods could call the 
setter with NULL.

H. calling isset() on a property with accessor methods returns `FALSE` if 
the property does not exist, otherwise calls the getter and compares 
against `NULL` for compatibility purposes.  (?)

I. calling `property_exists()` on a property with accessor methods would 
always return TRUE.

J. The setter and getter could be inspected via ReflectionProperty.

K. Unlike __get, subclass property definitions could override the 
parent declarations:

class Foo { public $prop; }
class Bar extends Foo { public $prop read getProp write setProp;  ... }

L. An abstract class need not declare the actual accessor methods, they 
could be added as abstract by default:

abstract class Bar { public $foo read getFoo write setFoo; }

Just a few thoughts.  I am sure there are other possibilities for the 
same use cases.

Best Regards,

Jeff

---

Next page: https://externals.io/message/23291.md?page=2