Re: [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

*sigh* Which error would make more sense to you Stas... Given this code: class a {

    public $b {
        get() { return 5; }
        private set($x) { /* do something */ }
    }

} $o = new a(); echo $o->b; $o->b = 42; There are two possibilities at this point. The code base, without all the work I have done to make the errors make sense will show: Fatal error: Call to private method a::__setb() from context ''... Or... Fatal error: Cannot set private property a::$b. Which makes more sense to the most people? On 11/14/2012 10:24 AM, Stas Malyshev wrote:

Hi!

Been AWOL for a while and getting back to this, doesn't seem like any resolution has occurred, just the conversation has died down. I would propose that: 1) Internal accessor methods that are defined are callable directly. 2) Said methods are not reflected or revealed by the engine (stack traces, reflection, etc would hide the engines implementation details) I think that with the above, #1 makes it easy as no further changes are required to make that happen, they're already directly callable and #2 jives with what *most userland programmers* would expect. Anyone disagree?

Yes. I strongly disagree with adding any magic to the engine that messes with reflection and backtraces and removes methods existing and being called from it. I think no "userland" programmer would have any problem understanding that these methods exist and how they work, just as nobody has problem understanding how __get works. I think adding this magic complicates both engine code (which will have to be supported for years to come) and the language, without absolutely any benefit to anybody except for imaginary people being scared to death by methods that they themselves defined showing up in the backtrace.

-- -Clint