Yeah, pretty much. I would not say they are "hidden" from the user,
they are simply not revealed purposely. (see example below for reason)
It's an irrelevant engine implementation detail. They would simply be
callable only because they are actually methods. They are not magic
methods because their simple existence does not make them accessors.
Fatal error: Call to private method a::__setb() from context ''...
Or...
Fatal error: Cannot set private property a::$b.
A user seeing the first error after having defined a property would be
like WTF? What is __setb() and why does the engine think I'm trying to
call it?
As the code is currently written, nearly all errors that would have
produced confusing errors such as the former, they produce errors such
as the latter, one that makes sense given that they are trying to set a
property.
Nikita, you and Stas are the two most diametrically opposed on this
issue, would you please hash it out and let me know? You all know my
position on what I think it should do and I'd just like this to get
resolved.
-Clint
On 11/14/2012 9:35 AM, Nikita Popov wrote:
On Wed, Nov 14, 2012 at 2:27 PM, Clint Priest <cpri...@zerocue.com
<mailto:cpri...@zerocue.com>> wrote:
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 got the feeling that in the last few mails we actually made some
progress and some people agreed with me that __magic accessor methods
and a dedicated syntax for them are not combinable semantically. Maybe
I got that wrong :/
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
The current implementation just uses the __ methods internally, but
they are not actually magic accessor methods. That's not what Stas
wants (as far as I understood). So you would still have to change the
implementation to make them true magic methods which can be used
independently from the special accessor syntax.
and #2 jives with what *most userland programmers* would expect.
So with your current plan we would end up with this:
a) A dedicated accessors syntax
b) which internally stores the accessors as methods with special names
c) but those methods are not magic methods, so you can't get the same
behavior by defining them directly
d) and the methods are hidden from the user
e) but he can still call them (even though they don't exist if he asks
for them in reflection).
All this sounds very odd to me.
Nikita :)
--
-Clint
