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

[Patrick Schaaf]

Am 19.11.2012 16:41 schrieb "Nikita Popov" :
>
> On Wed, Nov 14, 2012 at 5:24 PM, Patrick Schaaf  wrote:
>
>> class ... {
>>   no methodname();
>>// or
>>   no $property;
>> }
>>
> Removing methods from an extending class is an LSP violation.

I see LSP as a best practise for class design, not as something a language
should enforce.

Also, the propsed "autmatic" use of that "no" mechanism to solve the
accessor vs. property precendence issue, wouldn't be an LSP violation by
itself.

Anyway, the use case I sometimes had for that feature wouldn't even violate
LSP. I occasionaly have a subclass which likes to use a ___call magic
method to pass method calls on to a delegate object, and that does not work
for methods declared on the superclass in any way, be it as "throw
subclassresponsibility()" methods or some kind of default implementation
that other sibling classes would profit from. The only way out now is to
leave out such methods in the superclass, put them into a trait,  and use
that trait in all subclasses that do not want to delegate.

best regards
  Patrick

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

[Nikita Popov]

On Wed, Nov 14, 2012 at 5:24 PM, Patrick Schaaf  wrote:

> I thought I'd made a proposal that would solve that problem, but maybe it
> was
> overlooked, or more likely too ugly to be recognized as such.
>
> Requires a single new feature / syntax, that at least I find missing right
> now:
>
> class ... {
>   no methodname();
>// or
>   no $property;
> }
>
> removing the specified thing from the class, with the possibility to then
> redefine it. Silently ignore this when the thing doesn't exist.
>

Removing methods from an extending class is an LSP violation. It shouldn't
be done and I don't know any languages with an object orientation system
similar to PHP that allow this.

I think that this "no" tagging approach wouldn't really solve anything,
just patch it up in some rather ugly way.

Nikita

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

[Stas Malyshev]

Hi!

> 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?

Either of these is fine. I'm not talking about that though. You said:
"stack traces, reflection, etc would hide the engines implementation
details". That means that every part of the engine that deals with stack
and reflection should be modified, for no reason other than to hide the
scary fact of existence of accessor methods. I think this should not be
done - stack traces should show stack as it is, and that's it.
Reflection should show the methods as they are, and that's it. No
additional complications and special exceptions in order not to hurt the
feelings of (imaginary) easily scared and confused users.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Clint Priest]

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 > 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

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

[Clint Priest]

*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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Patrick Schaaf]

On Wednesday 14 November 2012 16:35:31 Nikita Popov wrote:
> On Wed, Nov 14, 2012 at 2:27 PM, Clint Priest  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 thought I'd made a proposal that would solve that problem, but maybe it was 
overlooked, or more likely too ugly to be recognized as such.

Requires a single new feature / syntax, that at least I find missing right 
now:

class ... {
  no methodname();
   // or
  no $property;
}

removing the specified thing from the class, with the possibility to then 
redefine it. Silently ignore this when the thing doesn't exist.

The mechanism for that could then be used to solve your semantic puzzle, using 
these rules:

- any ordinary property declaration for $foo internally also does
no __prop_get_foo();
no __prop_set_foo();
no __prop_isset_foo();
no __prop_unset_foo();
- any declaration of these four new magic methods internally also does
   no $foo;

In other words:

whenever a class implements one of the accessor magic methods, an inherited 
property is ignored, as if it wasn't present in the base class(es) in the 
first place.

And whenever a class declares a property in the ordinary way, any inherited 
magic property accessor methods are ignored, as if they were not present in 
the base class(es) in the first place.

Maybe a "final" in the respective base class, would make this attempt an 
ERROR.

What do you think? Should I try to write up an RFC for the "no" feature?

best regards
  Patrick

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Stas Malyshev]

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.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Nikita Popov]

On Wed, Nov 14, 2012 at 2:27 PM, Clint Priest  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 :)

RE: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

[Christian Stoller]

@ internal accessor method visibility / callability

I would prefer "Type 1" because:
1. A programming language is made for those who use the language not for those 
who develop this language. What is the target group of PHP?
2. Why should I define a property "protected $property { }" and call it via 
->__getProperty() ? If I would like to do that, I can define "public function 
__getProperty() { }"
3. The feature provides *property accessors* and not magic method generators
4. Providing internal accessor method callability could make code less readable 
and more complex, without adding any plus
5. This magic behavior blows up documentation and will make the whole topic 
more complicated for "beginners"
6. What happens if I define "protected $property { get() {...} }" and 
"protected function __getProperty() { }" in one class? 

I hope that does not sound aggressive ;)

Best regards
Christian


-Original Message-
From: Clint Priest [mailto:cpri...@zerocue.com] 
Sent: Wednesday, November 14, 2012 2:28 PM
To: PHP Developers Mailing List
Subject: Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method 
Visibility / Callability

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?

On 10/26/2012 5:37 AM, Clint Priest wrote:
> I'm opening up several new threads to get discussion going on the 
> remaining "being debated" categories referenced in this 1.1 -> 1.2 
> change spec:
> https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests 
>
>
> 
> Some people are in favor of the internal functions being generated by 
> an accessor declaration should be invisible and non-callable directly. 
> Others are in favor of leaving them visible and callable.
>
> *Type 1 ( Userland Programmer )**
> *
> As a userland programmer, someone who cares nothing for "how" php 
> works, only how their own code works. If they define an accessor they 
> expect to see an accessor, reflection should reflect that there are 
> accessors and no other "methods" they did not explicitly define. If 
> they were to reflect on all of the methods of their class and see a 
> number of __getHours() they may be confused as to why or where this 
> function came from. From their perspective, they have defined an 
> accessor and "how" that accessor works on the inside is of no 
> importance to them and only seeks to complicate or confuse matters 
> when they are exposed to these "implementation details" of the php 
> language its-self. If you tried to set a value such as $obj?abc = 1 
> through an accessor which could not be set, you would probably want to 
> see an error like: Warning, cannot set Class?abc, no setter defined.
>
> *Type 2 ( Internals Programmer )**
> *
> As an internals programmer, you want nothing hidden from you. If an 
> accessor implements special __getHours() methods to work its magic, 
> then you want to see them, you want to call them directly if you so 
> choose. In effect you want nothing hidden from you. In this case you 
> probably don't even want Reflection to reflect accessors as anything 
> different than specially formatted and called methods on the class. 
> This can be understandable because you want all information available 
> to you. You would probably not be confused if you wrote $obj?abc = 1 
> and got back an error like "Fatal Error: Class->__setAbc() function 
> does not exist.
>
> *Unfortunately 80 to 95% of all people who use PHP are of the first 
> type.**
> *
> Revealing these internal matters to them would only leave them 
> confused, possibly frustrated and likely asking about it to the 
> internals mailing list to answer (repeatedly).
> 
>
> Thoughts?
>

-- 
-Clint

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Clint Priest]

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?

On 10/26/2012 5:37 AM, Clint Priest wrote:
I'm opening up several new threads to get discussion going on the 
remaining "being debated" categories referenced in this 1.1 -> 1.2 
change spec:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests 




Some people are in favor of the internal functions being generated by 
an accessor declaration should be invisible and non-callable directly. 
Others are in favor of leaving them visible and callable.


*Type 1 ( Userland Programmer )**
*
As a userland programmer, someone who cares nothing for "how" php 
works, only how their own code works. If they define an accessor they 
expect to see an accessor, reflection should reflect that there are 
accessors and no other "methods" they did not explicitly define. If 
they were to reflect on all of the methods of their class and see a 
number of __getHours() they may be confused as to why or where this 
function came from. From their perspective, they have defined an 
accessor and "how" that accessor works on the inside is of no 
importance to them and only seeks to complicate or confuse matters 
when they are exposed to these "implementation details" of the php 
language its-self. If you tried to set a value such as $obj?abc = 1 
through an accessor which could not be set, you would probably want to 
see an error like: Warning, cannot set Class?abc, no setter defined.


*Type 2 ( Internals Programmer )**
*
As an internals programmer, you want nothing hidden from you. If an 
accessor implements special __getHours() methods to work its magic, 
then you want to see them, you want to call them directly if you so 
choose. In effect you want nothing hidden from you. In this case you 
probably don't even want Reflection to reflect accessors as anything 
different than specially formatted and called methods on the class. 
This can be understandable because you want all information available 
to you. You would probably not be confused if you wrote $obj?abc = 1 
and got back an error like "Fatal Error: Class->__setAbc() function 
does not exist.


*Unfortunately 80 to 95% of all people who use PHP are of the first 
type.**

*
Revealing these internal matters to them would only leave them 
confused, possibly frustrated and likely asking about it to the 
internals mailing list to answer (repeatedly).



Thoughts?



--
-Clint

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Cal]

Le 26/10/2012 11:37, Clint Priest a écrit :
I'm opening up several new threads to get discussion going on the 
remaining "being debated" categories referenced in this 1.1 -> 1.2 
change spec:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests 



In the RFC, section "read-only / write-only keywords" :


class  TimePeriod{
 private  $Seconds;
   public  $Hours  {
 get()  {  return  $this->Hours;  }
 private  final set($value)  {  throw  new Exception("Setting 
of TimePeriod::$Hours  is not allowed.");  }

 isset() { return isset($this->Seconds); }
 unset() { unset($this->Seconds); }
 }
}


I just added the methods "isset" and "unset" of the first example.

So, is there a case where "set" and "unset" shouldn't have the same 
visibility ? And "get" and "isset"?


If not, the Amaury's proposition could be merged in your syntax:


class  TimePeriod{
 private  $Seconds;
   public:private  $Hours  {
 get()  {  return  $this->Hours;  }  // read => public
 set($value)  {  throw  new  Exception("Setting of 
TimePeriod::$Hours  is not allowed.");  }  // write => private

 isset() { return isset($this->Seconds); } // read => public
 unset() { unset($this->Seconds); } // write => private
 }
}

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

[Lars Strojny]

Hi Stas, hi Etienne,

let’s get practical and apply LSP to property accessors. Find below what I 
would read from the characteristics of LSP.

Am 31.10.2012 um 20:46 schrieb Stas Malyshev :
[...]
>> Instead, LSP simply states that, given B <: A, all objects of A can be
>> substituted by objects of B while preserving the validity of the
>> method calls on these objects, and the validity of their return
>> values. This is guaranteed here:



Characteristics 1: Contravariance of method arguments in subtypes

This applies to properties in so forth, that weaker requirements need to be 
allowed. This means:

  - Redeclaring a property without a specific type is OK (e.g. parent DateTime, 
children everything)
  - Redeclaring a property with a supertype is OK (e.g. parent MyDateTime, 
children DateTime)
  - Redeclaring a property that was read only as read-writable is OK in theory 
(it isn’t because of the history rule)
  - Redeclaring a property with as less visible is not OK (parent public, 
children protected)
  - Redeclaring a property with as more visible is OK (parent protected, 
children public)
  - Redeclaring a property as read-only is not OK (parent rw, children ro)

Characteristics 2: Covariance of method return values in subtypes

  - For properties, this basically mirrors the rules from rules from 
characteristics 1

Characteristics 3: Preconditions cannot be strengthened: This is something we 
cannot and should not prevent in the language itself but it’s up to the 
programmer to do this correctly
Characteristics 4: Postconditions cannot be weakened: See 3
Characterestics 5: History rule. See 3

cu,
Lars
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Stas Malyshev]

Hi!

> Well, LSP is typically not applied to program semantics, since this is
> not a generally decidable problem. The only post-conditions that LSP
> normally enforces is type based, i.e. the covariance of the return
> type.

Err, I'm not sure where you are taking this from, but LSP is certainly
not limited to return types. See:
https://en.wikipedia.org/wiki/Liskov_substitution_principle
If you look at classic Square/Rectangle example, it's all about
semantics and has nothing to do with types.

> Instead, LSP simply states that, given B <: A, all objects of A can be
> substituted by objects of B while preserving the validity of the
> method calls on these objects, and the validity of their return
> values. This is guaranteed here:

I would suggest at that point reading actual description of the LSP. You
rendition of it is wrong.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Patrick Schaaf]

Nikita, your examples convinced me that a strict "accessor methods as 
specialized __get/__set semantics" approach is undesirable.

To recapitulate your two examples:

Example 1:

class A {
  public $foo;
}
class B extends A {
  public $foo { get() { ...} }
}

Example 2:

class A {
  public $foo { get() { ...} }
}
class B extends A {
  public $foo;
}

One would expect that in both cases, instances of 'class B' would have a $foo 
acting as declared in class B, shadowing the declaration from class A.

I think that the issue might be solved by an additional, not-yet-discussed and 
very general extension, which is something I missed being able to do from time 
to time: the possibility to declare a method (or property) in some class to be 
explicitly NOT inherited. Syntactically, something like

class C {
  public $bar;
  public function twiddle();
}
class D extends C {
  no public $bar;
  no public function twiddle();
 # might be followed by a different twiddle(), or $bar, implementation
}

The use case I have in mind, coming from the method side, is a subclass that 
wants to use __call() for delegation AND needs to delegate to one or more 
methods that are ordinarily plainly implemented in the base class.

What this feature would bring to the current discussion, is this possible 
solution to your dilemma:

1) when a class declares a plain property "public $foo", automatically apply
"no function __getfoo(); no function setfoo();" (leaving out isset/unset for 
clarity)
2) conversely, when a class declares "public $foo { get() {...}}", or even 
just declares one of the magic methods directly like "public function 
__getfoo() {}" - automatically prepend / pretend a "no public $foo;" 
cancelling a superclass property.

best regards
  Patrick


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Etienne Kneuss]

Hi,

On Wed, Oct 31, 2012 at 12:16 AM, Stas Malyshev  wrote:
> Hi!
>
>>> I'm not sure why you are expecting this, and also this is probably an
>>> LSP violation, since such override would change semantics of the value
>>> that A clients expect. It may be possible to implement, technically, but
>>> I'm not sure it's the right thing to do.
>>
>> Why would it be not expected and/or a violation of LSP? Accessors
>> impose stricly more restrictions than properties. This code is fine.
>
> You assume accessors are restrictions, but they don't have to be. Consider:
>
> public $foo { get() { return $this->foo;} set($v) { $this->foo_copy =
> $this->foo = $v; } }
>
> You have a postcondition on set() that $this->foo_copy will be the same
> as $this->foo. Override with "public $foo" removes that postcondition.
> But proper inheritance should only strengthen the postconditions, not
> drop them.

Well, LSP is typically not applied to program semantics, since this is
not a generally decidable problem. The only post-conditions that LSP
normally enforces is type based, i.e. the covariance of the return
type.

Instead, LSP simply states that, given B <: A, all objects of A can be
substituted by objects of B while preserving the validity of the
method calls on these objects, and the validity of their return
values. This is guaranteed here:

a get accessor will return a value of type any when performing
$a->foo, so does a property. LSP checks.
a set accessor takes a argument, so does $a->foo = "..". LSP checks.

My point is: all valid usages of accessors will also be valid when the
subclass overrides them using a normal property.

>
>> Just like it is fine in theory to have interface A { public $foo {
>> get(); set($v); } } class B implements A { public $foo; }
>
> That's different. In this case, you say "I will have some property
> $foo", without promising anything about it. But specific code can
> actually make some promises about $foo, and you can violate these
> promises by overriding it with public $foo.

That's the same argument as before. Corresponding to LSP it only gives
very specific promises, that are simply type based and not the actual
strongest post-condition.

> Interface does not impose
> any conditions except that $foo exist and is gettable/settable. Specific
> getters/setters can impose much more involved conditions, which "public
> $foo" may not be able to satisfy.

Following your argument:

class A { public $v = 1; public foo() { $this->v = 2; } } class B
extends A {public foo() { $this->v = 4; }}

B should violate LSP, since the postcondition of B::foo() does not
imply postcondition of A::foo(). This is obviously not correct: this
code is fine.

Best,

>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227



-- 
Etienne Kneuss
http://www.colder.ch

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Stas Malyshev]

Hi!

>> I'm not sure why you are expecting this, and also this is probably an
>> LSP violation, since such override would change semantics of the value
>> that A clients expect. It may be possible to implement, technically, but
>> I'm not sure it's the right thing to do.
> 
> Why would it be not expected and/or a violation of LSP? Accessors
> impose stricly more restrictions than properties. This code is fine.

You assume accessors are restrictions, but they don't have to be. Consider:

public $foo { get() { return $this->foo;} set($v) { $this->foo_copy =
$this->foo = $v; } }

You have a postcondition on set() that $this->foo_copy will be the same
as $this->foo. Override with "public $foo" removes that postcondition.
But proper inheritance should only strengthen the postconditions, not
drop them.

> Just like it is fine in theory to have interface A { public $foo {
> get(); set($v); } } class B implements A { public $foo; }

That's different. In this case, you say "I will have some property
$foo", without promising anything about it. But specific code can
actually make some promises about $foo, and you can violate these
promises by overriding it with public $foo. Interface does not impose
any conditions except that $foo exist and is gettable/settable. Specific
getters/setters can impose much more involved conditions, which "public
$foo" may not be able to satisfy.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Etienne Kneuss]

On Tue, Oct 30, 2012 at 10:52 PM, Stas Malyshev  wrote:
> Hi!
>
>> Stas, you seem to have missed the point behind my mail. This wasn't
>> about what the exact details of the implementation will be, the
>> message was that the semantics of a dedicated accessors syntax and the
>> semantics of a magic implementation can not match.
>
> I see your point now, thanks, but I don't think I agree.
>
>>
>> E.g. assuming that magic accessors take priority over properties as
>> you want it this time I can just turn the examples around:
>>
>> class A {
>> public $foo { get() { ... } set($value) { ... } }
>> }
>>
>> class B extends A {
>> public $foo;
>> }
>>
>> => Here I would expect that public $foo from class B overrides public
>> $foo from class A.
>
> I'm not sure why you are expecting this, and also this is probably an
> LSP violation, since such override would change semantics of the value
> that A clients expect. It may be possible to implement, technically, but
> I'm not sure it's the right thing to do.

Why would it be not expected and/or a violation of LSP? Accessors
impose stricly more restrictions than properties. This code is fine.

Just like it is fine in theory to have interface A { public $foo {
get(); set($v); } } class B implements A { public $foo; }

>
>> Basically any kind of interaction between properties and accessor
>> properties will be broken and inherently so, simply because magic
>> methods are not real properties (quite obviously...).
>
> Magic methods are not properties, they are implementation of properties.
> But your properties aren't either - see discussion about interfaces,
> etc. They simulate regular properties but they aren't regular
> properties. E.g., what would happen if you serialize an object with
> simulated property?
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



-- 
Etienne Kneuss
http://www.colder.ch

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Stas Malyshev]

Hi!

> Stas, you seem to have missed the point behind my mail. This wasn't
> about what the exact details of the implementation will be, the
> message was that the semantics of a dedicated accessors syntax and the
> semantics of a magic implementation can not match.

I see your point now, thanks, but I don't think I agree.

> 
> E.g. assuming that magic accessors take priority over properties as
> you want it this time I can just turn the examples around:
> 
> class A {
> public $foo { get() { ... } set($value) { ... } }
> }
> 
> class B extends A {
> public $foo;
> }
> 
> => Here I would expect that public $foo from class B overrides public
> $foo from class A. 

I'm not sure why you are expecting this, and also this is probably an
LSP violation, since such override would change semantics of the value
that A clients expect. It may be possible to implement, technically, but
I'm not sure it's the right thing to do.

> Basically any kind of interaction between properties and accessor
> properties will be broken and inherently so, simply because magic
> methods are not real properties (quite obviously...).

Magic methods are not properties, they are implementation of properties.
But your properties aren't either - see discussion about interfaces,
etc. They simulate regular properties but they aren't regular
properties. E.g., what would happen if you serialize an object with
simulated property?

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Larry Garfield]

There are still use cases for __get(), when the list of internal 
properties is dynamic.  We're actually leveraging that for Drupal 8's 
entity system.  Removing it would be a big problem. :-)


But that still doesn't resolve the mental model question.

--Larry Garfield

On 10/30/12 3:05 AM, Ferenc Kovacs wrote:

I would say that the proposed accessors is what we should have added back
then instead of __get/__set . The problem is that now we will have two
similar (albeit one is an ugly subset of the other) feature which needs to
co-exists.
My gut tells me that we should ditch the magic method approach with the
introduction of accessors and provide easy/automated migration.
Ofc. that would mean that we need at least one major version.
My two cents from the sidelines.
2012.10.28. 3:39, "Larry Garfield"  ezt írta:


On 10/26/2012 05:37 AM, Clint Priest wrote:


I'm opening up several new threads to get discussion going on the
remaining "being debated" categories referenced in this 1.1 -> 1.2 change
spec:
https://wiki.php.net/rfc/**propertygetsetsyntax-as-**
implemented/change-requests

--**--**

Some people are in favor of the internal functions being generated by an
accessor declaration should be invisible and non-callable directly. Others
are in favor of leaving them visible and callable.

*Type 1 ( Userland Programmer )**
*
As a userland programmer, someone who cares nothing for "how" php works,
only how their own code works. If they define an accessor they expect to
see an accessor, reflection should reflect that there are accessors and no
other "methods" they did not explicitly define. If they were to reflect on
all of the methods of their class and see a number of __getHours() they may
be confused as to why or where this function came from. From their
perspective, they have defined an accessor and "how" that accessor works on
the inside is of no importance to them and only seeks to complicate or
confuse matters when they are exposed to these "implementation details" of
the php language its-self. If you tried to set a value such as $obj?abc = 1
through an accessor which could not be set, you would probably want to see
an error like: Warning, cannot set Class?abc, no setter defined.

*Type 2 ( Internals Programmer )**
*
As an internals programmer, you want nothing hidden from you. If an
accessor implements special __getHours() methods to work its magic, then
you want to see them, you want to call them directly if you so choose. In
effect you want nothing hidden from you. In this case you probably don't
even want Reflection to reflect accessors as anything different than
specially formatted and called methods on the class. This can be
understandable because you want all information available to you. You would
probably not be confused if you wrote $obj?abc = 1 and got back an error
like "Fatal Error: Class->__setAbc() function does not exist.

*Unfortunately 80 to 95% of all people who use PHP are of the first
type.**
*
Revealing these internal matters to them would only leave them confused,
possibly frustrated and likely asking about it to the internals mailing
list to answer (repeatedly).
--**--**


Thoughts?



Speaking as a user-land programmer that's been following this thread, but
hasn't been able to jump in yet due to the high volume of comments...

What's unclear to me is what my mental model should be for this new
syntax.  That's important for informing how it should be exposed to me.

1) Should I have a mental model of this being some syntax candy on top of
existing properties?  Vis, this is just a short-hand for bean-style
classes?  By Bean style, I mean Properties that would be public but aren't
because Public Is Bad(tm), so instead we have getX()/setX() for every
property, so that we can still use the object like a struct rather than an
object but still say we're using methods even though we've just
reimplemented public properties with more verbose syntax.  (Note: Yes, I
know that's a rather harsh and judgmental description.  I happen to firmly
dislike Bean-style objects.)

2) Should I have a mental model that these fancy-pants properties are some
different third thingie on objects, distinct from traditional data members
and methods?

Right now I'm not sure which mental model I'm supposed to use, and I get
the sense that there's no clear consensus on that question yet. That, I
think, is the key question, and will inform how things like Reflection
should expose data about this new syntax.

For instance, if model 2 is how I'm supposed to be thinking, then I'd
expect I'd need a third reflection object for getting things off of an
object/class, separate from traditional data members and methods.  Then
it's consistently a third thingie.  If, however, I'm supposed to think of
it as just a s

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

[Ferenc Kovacs]

I would say that the proposed accessors is what we should have added back
then instead of __get/__set . The problem is that now we will have two
similar (albeit one is an ugly subset of the other) feature which needs to
co-exists.
My gut tells me that we should ditch the magic method approach with the
introduction of accessors and provide easy/automated migration.
Ofc. that would mean that we need at least one major version.
My two cents from the sidelines.
2012.10.28. 3:39, "Larry Garfield"  ezt írta:

> On 10/26/2012 05:37 AM, Clint Priest wrote:
>
>> I'm opening up several new threads to get discussion going on the
>> remaining "being debated" categories referenced in this 1.1 -> 1.2 change
>> spec:
>> https://wiki.php.net/rfc/**propertygetsetsyntax-as-**
>> implemented/change-requests
>>
>> --**--**
>> 
>> Some people are in favor of the internal functions being generated by an
>> accessor declaration should be invisible and non-callable directly. Others
>> are in favor of leaving them visible and callable.
>>
>> *Type 1 ( Userland Programmer )**
>> *
>> As a userland programmer, someone who cares nothing for "how" php works,
>> only how their own code works. If they define an accessor they expect to
>> see an accessor, reflection should reflect that there are accessors and no
>> other "methods" they did not explicitly define. If they were to reflect on
>> all of the methods of their class and see a number of __getHours() they may
>> be confused as to why or where this function came from. From their
>> perspective, they have defined an accessor and "how" that accessor works on
>> the inside is of no importance to them and only seeks to complicate or
>> confuse matters when they are exposed to these "implementation details" of
>> the php language its-self. If you tried to set a value such as $obj?abc = 1
>> through an accessor which could not be set, you would probably want to see
>> an error like: Warning, cannot set Class?abc, no setter defined.
>>
>> *Type 2 ( Internals Programmer )**
>> *
>> As an internals programmer, you want nothing hidden from you. If an
>> accessor implements special __getHours() methods to work its magic, then
>> you want to see them, you want to call them directly if you so choose. In
>> effect you want nothing hidden from you. In this case you probably don't
>> even want Reflection to reflect accessors as anything different than
>> specially formatted and called methods on the class. This can be
>> understandable because you want all information available to you. You would
>> probably not be confused if you wrote $obj?abc = 1 and got back an error
>> like "Fatal Error: Class->__setAbc() function does not exist.
>>
>> *Unfortunately 80 to 95% of all people who use PHP are of the first
>> type.**
>> *
>> Revealing these internal matters to them would only leave them confused,
>> possibly frustrated and likely asking about it to the internals mailing
>> list to answer (repeatedly).
>> --**--**
>> 
>>
>> Thoughts?
>>
>>
> Speaking as a user-land programmer that's been following this thread, but
> hasn't been able to jump in yet due to the high volume of comments...
>
> What's unclear to me is what my mental model should be for this new
> syntax.  That's important for informing how it should be exposed to me.
>
> 1) Should I have a mental model of this being some syntax candy on top of
> existing properties?  Vis, this is just a short-hand for bean-style
> classes?  By Bean style, I mean Properties that would be public but aren't
> because Public Is Bad(tm), so instead we have getX()/setX() for every
> property, so that we can still use the object like a struct rather than an
> object but still say we're using methods even though we've just
> reimplemented public properties with more verbose syntax.  (Note: Yes, I
> know that's a rather harsh and judgmental description.  I happen to firmly
> dislike Bean-style objects.)
>
> 2) Should I have a mental model that these fancy-pants properties are some
> different third thingie on objects, distinct from traditional data members
> and methods?
>
> Right now I'm not sure which mental model I'm supposed to use, and I get
> the sense that there's no clear consensus on that question yet. That, I
> think, is the key question, and will inform how things like Reflection
> should expose data about this new syntax.
>
> For instance, if model 2 is how I'm supposed to be thinking, then I'd
> expect I'd need a third reflection object for getting things off of an
> object/class, separate from traditional data members and methods.  Then
> it's consistently a third thingie.  If, however, I'm supposed to think of
> it as just a short-hand syntax for writing a bean, then I'd expect it to be
> presented to me as if I'd hand-written all of the 

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

[Nikita Popov]

On Mon, Oct 29, 2012 at 10:56 PM, Stas Malyshev  wrote:
> Hi!
>
>> If I got it right now, what Stas wants is that we introduce __getFoo
>> and __setFoo methods that will be called whenever an undefined ->foo
>> property is accessed and that the "normal" property accessors syntax
>> is made nothing more than a fancy notation for this.
>
> Yes, pretty much, though "undefined" bit is not required I think. Not
> 100% convinced on this, but from user reqs it sounds like they want to
> drop the undefined bit.
>
>> A) Inheritance:
>> ==
>>
>> class A {
>> public $foo;
>> }
>>
>> class B extends A {
>> public $foo { get() { ... } set($value) { ... } }
>> }
>>
>> => With the accessors syntax there is an expectation that the accessor
>> declaration will override the previous plain property. At least that's
>> what I would expect and that's what the code looks like
>
> That's why I'm not liking the "undefined" bit.
>
>> => With the magic syntax there is the expectation that the $foo
>> property will not be overridden. Rather the magic functions are
>> expected to do nothing, because the property already exists.
>
> Err, I'm not sure why that would be the expectation. __get is for
> undefined properties, since, well, it doesn't have any property name
> attached, so it can't really be for defined properties :) However,
> __getFoo (with whatever variations the bikeshedding committee will end
> up with :) has property name attached to it, so requiring property be
> undefined is not, well, required. Here we need to think which way is
> better, and I currently tend to think accessor priority is better.

Stas, you seem to have missed the point behind my mail. This wasn't
about what the exact details of the implementation will be, the
message was that the semantics of a dedicated accessors syntax and the
semantics of a magic implementation can not match.

E.g. assuming that magic accessors take priority over properties as
you want it this time I can just turn the examples around:

class A {
public $foo { get() { ... } set($value) { ... } }
}

class B extends A {
public $foo;
}

=> Here I would expect that public $foo from class B overrides public
$foo from class A. With __ magic on the other hand:

class A {
public function __getFoo() { ... }
public function __setFoo($value) { ... }
}

class B extends A {
public $foo;
}

=> Here (according to your new overriding priority) the property in
class B would not override, rather the magic from A stays intact.

Basically any kind of interaction between properties and accessor
properties will be broken and inherently so, simply because magic
methods are not real properties (quite obviously...).

Nikita

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Stas Malyshev]

Hi!

> If I got it right now, what Stas wants is that we introduce __getFoo
> and __setFoo methods that will be called whenever an undefined ->foo
> property is accessed and that the "normal" property accessors syntax
> is made nothing more than a fancy notation for this.

Yes, pretty much, though "undefined" bit is not required I think. Not
100% convinced on this, but from user reqs it sounds like they want to
drop the undefined bit.

> A) Inheritance:
> ==
> 
> class A {
> public $foo;
> }
> 
> class B extends A {
> public $foo { get() { ... } set($value) { ... } }
> }
> 
> => With the accessors syntax there is an expectation that the accessor
> declaration will override the previous plain property. At least that's
> what I would expect and that's what the code looks like

That's why I'm not liking the "undefined" bit.

> => With the magic syntax there is the expectation that the $foo
> property will not be overridden. Rather the magic functions are
> expected to do nothing, because the property already exists.

Err, I'm not sure why that would be the expectation. __get is for
undefined properties, since, well, it doesn't have any property name
attached, so it can't really be for defined properties :) However,
__getFoo (with whatever variations the bikeshedding committee will end
up with :) has property name attached to it, so requiring property be
undefined is not, well, required. Here we need to think which way is
better, and I currently tend to think accessor priority is better.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Larry Garfield]

See, I'm not convinced that "everyone would agree that #1 [just some 
syntax candy] is definitely not right".  From the discussion here, it 
seems like some are still thinking of it that way.


If they are supposed to be a 3rd thingie, and the only relation to data 
members as we've known them is that they have the same external syntax, 
then IMO we should make them as distinct as possible, everywhere.  New 
keyword, separate reflection pipeline, the works.  That then means that 
the implementation detail of "public $baz { get() {return 'meep'; } 
causes the creation of public function __get_property_meep()" should not 
be exposed, anywhere, and that method should not show up in reflection, 
since it doesn't really exist, it's just an implementation detail.


It's the "depending on how you look at it, you may or may not get to see 
implementation details leak" problem that I think is the worst case 
scenario.


--Larry Garfield

On 10/27/2012 10:59 PM, Clint Priest wrote:

Hey Larry,

Glad you chimed in here on this.  I my opinion (author of thingy), 
they are separate and distinct from data members.  More specifically 
they are getter and setter code that is called when the property is 
accessed.


Using your example:

echo $obj->baz; // executes the code "return $this->baz;"

and

$obj->baz = 4;  // executes the code "$this->baz = $value;"

So from the perspective of the user of the class, they are just 
"properties" but internal to the class they are implemented with 
methods and code.


I think everyone would agree that your #1 is definitely not right, 
however I believe there is not consensus on whether or not these *are* 
different from properties.  To the consumer of the class, they are no 
different than properties, to the author of the class they are very 
different.


On Saturday, October 27, 2012 9:48:12 PM, Larry Garfield wrote:

On 10/27/2012 09:38 PM, Larry Garfield wrote:

On 10/26/2012 05:37 AM, Clint Priest wrote:

I'm opening up several new threads to get discussion going on the
remaining "being debated" categories referenced in this 1.1 -> 1.2
change spec:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests 




 



Some people are in favor of the internal functions being generated
by an accessor declaration should be invisible and non-callable
directly. Others are in favor of leaving them visible and callable.

*Type 1 ( Userland Programmer )**
*
As a userland programmer, someone who cares nothing for "how" php
works, only how their own code works. If they define an accessor
they expect to see an accessor, reflection should reflect that there
are accessors and no other "methods" they did not explicitly define.
If they were to reflect on all of the methods of their class and see
a number of __getHours() they may be confused as to why or where
this function came from. From their perspective, they have defined
an accessor and "how" that accessor works on the inside is of no
importance to them and only seeks to complicate or confuse matters
when they are exposed to these "implementation details" of the php
language its-self. If you tried to set a value such as $obj?abc = 1
through an accessor which could not be set, you would probably want
to see an error like: Warning, cannot set Class?abc, no setter 
defined.


*Type 2 ( Internals Programmer )**
*
As an internals programmer, you want nothing hidden from you. If an
accessor implements special __getHours() methods to work its magic,
then you want to see them, you want to call them directly if you so
choose. In effect you want nothing hidden from you. In this case you
probably don't even want Reflection to reflect accessors as anything
different than specially formatted and called methods on the class.
This can be understandable because you want all information
available to you. You would probably not be confused if you wrote
$obj?abc = 1 and got back an error like "Fatal Error:
Class->__setAbc() function does not exist.

*Unfortunately 80 to 95% of all people who use PHP are of the first
type.**
*
Revealing these internal matters to them would only leave them
confused, possibly frustrated and likely asking about it to the
internals mailing list to answer (repeatedly).
 




Thoughts?



Speaking as a user-land programmer that's been following this thread,
but hasn't been able to jump in yet due to the high volume of
comments...

What's unclear to me is what my mental model should be for this new
syntax.  That's important for informing how it should be exposed to me.

1) Should I have a mental model of this being some syntax candy on
top of existing properties?  Vis, this is just a short-hand for
bean-style classes?  By Bean style, I mean Properties that would be
public but aren't because Public Is Bad(tm), so instead we have
getX()/setX() for every property, so that we can 

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

[Nikita Popov]

On Sun, Oct 28, 2012 at 4:50 PM, Clint Priest  wrote:
> On 10/28/2012 2:04 AM, Stas Malyshev wrote:
>>
>> Hi!
>>
>>> Stas, you should probably do some research before posting such non-sense:
>>
>> Which part is "non-sense"? I've brought you examples of Python and Ruby
>> not doing exactly what you claim all languages are doing. By your
>> definition, they don't have accessors - as you define accessors as
>> hidden methods that are uncallable and unavailable and not defined as
>> regular methods. In both Ruby and Python they are callable and defined
>> as regular (or regular with some special attributes) method.
>>
>> I've brought you examples of popular languages that don't have this
>> feature at all - Java and standard C++ don't have it. I was wrong on
>> Javascript - though in Javascript, functions work differently from PHP
>> so there's no real relation to the current discussion.
>>
>>> By accessors I am simply referring to getters, setters (and in the case
>>> of php, issetter and unsetter).
>>
>> I wish it was so, but it was mentioned many times in this discussion
>> that "accessors should be accessors" and that only the situation where
>> accessors are special functions that are not defined as regular methods,
>> are not callable and are hidden from reflection, etc. is the situation
>> where "accessors are accessors". This is not the case in Python, Ruby,
>> MS C++, D and Delphi by your own link - in all these cases, the
>> properties are defined as regular methods (possibly with some special
>> salt added) and no special effort is taken to hide them from any of the
>> language facilities and make them not callable.
>> Of course, there are also examples of languages going the other way -
>> namely, C#, F# and VB - but by no means the claim that I would be hard
>> pressed to find example of the languages which do not implement your
>> notion of "accessors being accessors" is true. For most dynamic
>> languages, the concept of "accessors being accessors" - hidden,
>> non-callable pseudo-methods - is a foreign concept.
>>
> I see what you're talking about, I felt like you were saying these other
> languages did not support accessors (getters, setters, etc). Those other
> languages do not "hide" them, no.  This was Nikita's suggestion, I will let
> her fight for it.
If I got it right now, what Stas wants is that we introduce __getFoo
and __setFoo methods that will be called whenever an undefined ->foo
property is accessed and that the "normal" property accessors syntax
is made nothing more than a fancy notation for this.

I'm okay with one of those, but I highly advise against combining
both, i.e. either __getFoo and __setFoo OR a special accessor syntax.

The reason is that both carry different and non-combinable semantics.
A few examples:

A) Inheritance:
==

class A {
public $foo;
}

class B extends A {
public $foo { get() { ... } set($value) { ... } }
}

=> With the accessors syntax there is an expectation that the accessor
declaration will override the previous plain property. At least that's
what I would expect and that's what the code looks like

class A {
public $foo;
}

class B extends A {
public function __getFoo() { ... }
public function __setFoo($value) { ... }
}

=> With the magic syntax there is the expectation that the $foo
property will not be overridden. Rather the magic functions are
expected to do nothing, because the property already exists.

B) Interfaces:
=

interface A {
public $foo;
}

class B implements A {
public $foo { get() { ... } set($value) { ... } }
}

=> Here the accessor is expected to satisfy the interface

interface A {
public $foo;
}

class B implements A {
public function __getFoo() { ... }
public function __setFoo($value) { ... }
}

=> Here the magic methods don't satisfy the interface. Actually with
the magic methods approach the whole notion of properties or accessors
in interfaces becomes obsolete.

C) API semantics
=

The main advantage that accessors offer to me is that custom property
behavior can be a *proper part of the public API*. The magic __getFoo
/ __setFoo methods do not offer this. They are just another two magic
methods. On the other hand, proper accessors really define a
*property* with a certain behavior (the fact that they are bound to a
property is important here).

__getFoo and __setFoo are really not much of an improvement over
directly using __get and __set with a switch. It's just a small code
save. "Real" accessors on the other hand take properties to being a
first class API citizen.

D) Backing property
==

Additionally __getFoo / __setFoo would not allow us to access
$this->foo as the underlying "backing property". Whether or not this
approach has merits is a different discussion point, but the magic
method approach would make this impossible right from the 

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

[Clint Priest]

On 10/28/2012 2:04 AM, Stas Malyshev wrote:

Hi!


Stas, you should probably do some research before posting such non-sense:

Which part is "non-sense"? I've brought you examples of Python and Ruby
not doing exactly what you claim all languages are doing. By your
definition, they don't have accessors - as you define accessors as
hidden methods that are uncallable and unavailable and not defined as
regular methods. In both Ruby and Python they are callable and defined
as regular (or regular with some special attributes) method.

I've brought you examples of popular languages that don't have this
feature at all - Java and standard C++ don't have it. I was wrong on
Javascript - though in Javascript, functions work differently from PHP
so there's no real relation to the current discussion.


By accessors I am simply referring to getters, setters (and in the case
of php, issetter and unsetter).

I wish it was so, but it was mentioned many times in this discussion
that "accessors should be accessors" and that only the situation where
accessors are special functions that are not defined as regular methods,
are not callable and are hidden from reflection, etc. is the situation
where "accessors are accessors". This is not the case in Python, Ruby,
MS C++, D and Delphi by your own link - in all these cases, the
properties are defined as regular methods (possibly with some special
salt added) and no special effort is taken to hide them from any of the
language facilities and make them not callable.
Of course, there are also examples of languages going the other way -
namely, C#, F# and VB - but by no means the claim that I would be hard
pressed to find example of the languages which do not implement your
notion of "accessors being accessors" is true. For most dynamic
languages, the concept of "accessors being accessors" - hidden,
non-callable pseudo-methods - is a foreign concept.

I see what you're talking about, I felt like you were saying these other 
languages did not support accessors (getters, setters, etc). Those other 
languages do not "hide" them, no.  This was Nikita's suggestion, I will 
let her fight for it.

--
-Clint

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Lester Caine]

Stas Malyshev wrote:

By accessors I am simply referring to getters, setters (and in the case
>of php, issetter and unsetter).

I wish it was so, but it was mentioned many times in this discussion
that "accessors should be accessors" and that only the situation where
accessors are special functions that are not defined as regular methods,
are not callable and are hidden from reflection, etc. is the situation
where "accessors are accessors". This is not the case in Python, Ruby,
MS C++, D and Delphi by your own link - in all these cases, the
properties are defined as regular methods (possibly with some special
salt added) and no special effort is taken to hide them from any of the
language facilities and make them not callable.


While I will probably be shouted down again ... can we clarify WHAT people are 
trying to achieve here?


__get and __set simply provide a crude means of using '$data' array to store 
properties in an object without having to define and load them every time. It 
has very limited use and in my own opinion is simply wrong anyway. But people 
seem to like to use it rather than simply defining their own $data array and 
accessing it directly? The reason it does not work for me is that I populate the 
data array ( in my case $mInfo ) directly from the persistent data in a 
database, and __get and __set simply do not work with this so never get used.


I can SEE the logic behind a get and set arrangement being 'formalised', and 
mirroring __get and __set is obviously necessary, but part of the reason for 
this discussion was - I thought - a way of allowing get/set to manage access to 
internal data that may not be a simple mirror, but rather calculated from other 
internal data ( hours based on second count )? 'Internal Accessor Method 
Visibility' needs to provide the user with information on how a returned value 
was generated? Even if that is only via documentation? Debugging that the 
process is working is the thing that gets difficult if you can 'see' the process.


The discussion has been 'split up', but I see 'Extra shorthand declaration' as 
another hiding of visibility such that 'public DateTime $date;' completely 
bypasses setting up the DateTime object and that $date will have it's own 
'accessors' or rather methods for accessing and configuring the object and it's 
values!


PHP has something no other language has - 'very flexible arrays' - and we can 
manage and pass data very nicely using these properly. Pass by reference allows 
complex data to be passed and massaged in a way that 'accessors' simply can't 
provide, and it's this method of working that we should be promoting rather than 
trying to hide things 'because the user does not need to know about them'. 
Everything used to be nicely visible in PHP, but that is becoming less the case 
and getting back to a framework where the IDE can provide all of the 'eye-candy' 
that is not needed when simply running the scripts should be considered as well?


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Patrick Schaaf]

Am 28.10.2012 02:42 schrieb "Clint Priest" :
>
> Sounds like you're implying that the mere existence of a properly named
function such as __prop_get_hours() would cause it to be called instead of
returning the property.

Only when the property does not exist, just like it is with __get

> 1) Currently __get() is only checked/invoked if there is not a property
already defined; ie properties shadow __get() (no performance penalty)

Right. I would expect / hope for __prop_get_XXX to work exactly the same.

> 2) It would dramatically reduce performance because every property access
would have to create the function string, get it's hash value and .

But that only applies to an "accessor shadows property" doctrine, and that
is one of these complications / complexity issues which makes me  prefer
the "property exists means it's definite" doctrine as already deployed with
__get.

best regards
  Patrick

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

[Stas Malyshev]

Hi!

> Stas, you should probably do some research before posting such non-sense:

Which part is "non-sense"? I've brought you examples of Python and Ruby
not doing exactly what you claim all languages are doing. By your
definition, they don't have accessors - as you define accessors as
hidden methods that are uncallable and unavailable and not defined as
regular methods. In both Ruby and Python they are callable and defined
as regular (or regular with some special attributes) method.

I've brought you examples of popular languages that don't have this
feature at all - Java and standard C++ don't have it. I was wrong on
Javascript - though in Javascript, functions work differently from PHP
so there's no real relation to the current discussion.

> By accessors I am simply referring to getters, setters (and in the case 
> of php, issetter and unsetter).

I wish it was so, but it was mentioned many times in this discussion
that "accessors should be accessors" and that only the situation where
accessors are special functions that are not defined as regular methods,
are not callable and are hidden from reflection, etc. is the situation
where "accessors are accessors". This is not the case in Python, Ruby,
MS C++, D and Delphi by your own link - in all these cases, the
properties are defined as regular methods (possibly with some special
salt added) and no special effort is taken to hide them from any of the
language facilities and make them not callable.
Of course, there are also examples of languages going the other way -
namely, C#, F# and VB - but by no means the claim that I would be hard
pressed to find example of the languages which do not implement your
notion of "accessors being accessors" is true. For most dynamic
languages, the concept of "accessors being accessors" - hidden,
non-callable pseudo-methods - is a foreign concept.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Stas Malyshev]

Hi!

> 1) Currently __get() is only checked/invoked if there is not a property 
> already defined; ie properties shadow __get() (no performance penalty)

Yes, that's kind of the point of it - extending __get.

> 2) It would dramatically reduce performance because every property 
> access would have to create the function string, get it's hash value and 
> do a hash look up against the function table, just to see if there is a 

Not really, as we have property_info structure where we could record the
existence of such functions and we check property_info anyway AFAIR.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Clint Priest]

Hey Larry,

Glad you chimed in here on this.  I my opinion (author of thingy), they 
are separate and distinct from data members.  More specifically they 
are getter and setter code that is called when the property is accessed.


Using your example:

echo $obj->baz; // executes the code "return $this->baz;"

and

$obj->baz = 4;  // executes the code "$this->baz = $value;"

So from the perspective of the user of the class, they are just 
"properties" but internal to the class they are implemented with 
methods and code.


I think everyone would agree that your #1 is definitely not right, 
however I believe there is not consensus on whether or not these *are* 
different from properties.  To the consumer of the class, they are no 
different than properties, to the author of the class they are very 
different.


On Saturday, October 27, 2012 9:48:12 PM, Larry Garfield wrote:

On 10/27/2012 09:38 PM, Larry Garfield wrote:

On 10/26/2012 05:37 AM, Clint Priest wrote:

I'm opening up several new threads to get discussion going on the
remaining "being debated" categories referenced in this 1.1 -> 1.2
change spec:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests




Some people are in favor of the internal functions being generated
by an accessor declaration should be invisible and non-callable
directly. Others are in favor of leaving them visible and callable.

*Type 1 ( Userland Programmer )**
*
As a userland programmer, someone who cares nothing for "how" php
works, only how their own code works. If they define an accessor
they expect to see an accessor, reflection should reflect that there
are accessors and no other "methods" they did not explicitly define.
If they were to reflect on all of the methods of their class and see
a number of __getHours() they may be confused as to why or where
this function came from. From their perspective, they have defined
an accessor and "how" that accessor works on the inside is of no
importance to them and only seeks to complicate or confuse matters
when they are exposed to these "implementation details" of the php
language its-self. If you tried to set a value such as $obj?abc = 1
through an accessor which could not be set, you would probably want
to see an error like: Warning, cannot set Class?abc, no setter defined.

*Type 2 ( Internals Programmer )**
*
As an internals programmer, you want nothing hidden from you. If an
accessor implements special __getHours() methods to work its magic,
then you want to see them, you want to call them directly if you so
choose. In effect you want nothing hidden from you. In this case you
probably don't even want Reflection to reflect accessors as anything
different than specially formatted and called methods on the class.
This can be understandable because you want all information
available to you. You would probably not be confused if you wrote
$obj?abc = 1 and got back an error like "Fatal Error:
Class->__setAbc() function does not exist.

*Unfortunately 80 to 95% of all people who use PHP are of the first
type.**
*
Revealing these internal matters to them would only leave them
confused, possibly frustrated and likely asking about it to the
internals mailing list to answer (repeatedly).



Thoughts?



Speaking as a user-land programmer that's been following this thread,
but hasn't been able to jump in yet due to the high volume of
comments...

What's unclear to me is what my mental model should be for this new
syntax.  That's important for informing how it should be exposed to me.

1) Should I have a mental model of this being some syntax candy on
top of existing properties?  Vis, this is just a short-hand for
bean-style classes?  By Bean style, I mean Properties that would be
public but aren't because Public Is Bad(tm), so instead we have
getX()/setX() for every property, so that we can still use the object
like a struct rather than an object but still say we're using methods
even though we've just reimplemented public properties with more
verbose syntax. (Note: Yes, I know that's a rather harsh and
judgmental description. I happen to firmly dislike Bean-style objects.)

2) Should I have a mental model that these fancy-pants properties are
some different third thingie on objects, distinct from traditional
data members and methods?

Right now I'm not sure which mental model I'm supposed to use, and I
get the sense that there's no clear consensus on that question yet.
That, I think, is the key question, and will inform how things like
Reflection should expose data about this new syntax.

For instance, if model 2 is how I'm supposed to be thinking, then I'd
expect I'd need a third reflection object for getting things off of
an object/class, separate from traditional data members and methods.
Then it's consistently a third thingie.  If, however, I'm supposed to
think of 

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

[Larry Garfield]

On 10/27/2012 09:38 PM, Larry Garfield wrote:

On 10/26/2012 05:37 AM, Clint Priest wrote:
I'm opening up several new threads to get discussion going on the 
remaining "being debated" categories referenced in this 1.1 -> 1.2 
change spec:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests 




Some people are in favor of the internal functions being generated by 
an accessor declaration should be invisible and non-callable 
directly. Others are in favor of leaving them visible and callable.


*Type 1 ( Userland Programmer )**
*
As a userland programmer, someone who cares nothing for "how" php 
works, only how their own code works. If they define an accessor they 
expect to see an accessor, reflection should reflect that there are 
accessors and no other "methods" they did not explicitly define. If 
they were to reflect on all of the methods of their class and see a 
number of __getHours() they may be confused as to why or where this 
function came from. From their perspective, they have defined an 
accessor and "how" that accessor works on the inside is of no 
importance to them and only seeks to complicate or confuse matters 
when they are exposed to these "implementation details" of the php 
language its-self. If you tried to set a value such as $obj?abc = 1 
through an accessor which could not be set, you would probably want 
to see an error like: Warning, cannot set Class?abc, no setter defined.


*Type 2 ( Internals Programmer )**
*
As an internals programmer, you want nothing hidden from you. If an 
accessor implements special __getHours() methods to work its magic, 
then you want to see them, you want to call them directly if you so 
choose. In effect you want nothing hidden from you. In this case you 
probably don't even want Reflection to reflect accessors as anything 
different than specially formatted and called methods on the class. 
This can be understandable because you want all information available 
to you. You would probably not be confused if you wrote $obj?abc = 1 
and got back an error like "Fatal Error: Class->__setAbc() function 
does not exist.


*Unfortunately 80 to 95% of all people who use PHP are of the first 
type.**

*
Revealing these internal matters to them would only leave them 
confused, possibly frustrated and likely asking about it to the 
internals mailing list to answer (repeatedly).



Thoughts?



Speaking as a user-land programmer that's been following this thread, 
but hasn't been able to jump in yet due to the high volume of comments...


What's unclear to me is what my mental model should be for this new 
syntax.  That's important for informing how it should be exposed to me.


1) Should I have a mental model of this being some syntax candy on top 
of existing properties?  Vis, this is just a short-hand for bean-style 
classes?  By Bean style, I mean Properties that would be public but 
aren't because Public Is Bad(tm), so instead we have getX()/setX() for 
every property, so that we can still use the object like a struct 
rather than an object but still say we're using methods even though 
we've just reimplemented public properties with more verbose syntax.  
(Note: Yes, I know that's a rather harsh and judgmental description.  
I happen to firmly dislike Bean-style objects.)


2) Should I have a mental model that these fancy-pants properties are 
some different third thingie on objects, distinct from traditional 
data members and methods?


Right now I'm not sure which mental model I'm supposed to use, and I 
get the sense that there's no clear consensus on that question yet. 
That, I think, is the key question, and will inform how things like 
Reflection should expose data about this new syntax.


For instance, if model 2 is how I'm supposed to be thinking, then I'd 
expect I'd need a third reflection object for getting things off of an 
object/class, separate from traditional data members and methods.  
Then it's consistently a third thingie.  If, however, I'm supposed to 
think of it as just a short-hand syntax for writing a bean, then I'd 
expect it to be presented to me as if I'd hand-written all of the 
stuff that this syntax is emulating.  Vis, methods show up as methods, 
and anything I'd be able to read/write directly without going through 
an intermediary method should show up as a property just as it does now.


Note: I'm speaking here of the mental model of the user, which does 
not necessarily have any relationship to the implementation details.  
If I'm "supposed" to think of it as a third thingie, it doesn't matter 
that it may be implemented internally as syntactic sugar.  It should 
be presented to me as a third thingie, consistently, with the engine 
internal implementation details completely irrelevant.  (Which means 
they can be changed later if needs be.)


I don't know whi

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

[Larry Garfield]

On 10/26/2012 05:37 AM, Clint Priest wrote:
I'm opening up several new threads to get discussion going on the 
remaining "being debated" categories referenced in this 1.1 -> 1.2 
change spec:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests 




Some people are in favor of the internal functions being generated by 
an accessor declaration should be invisible and non-callable directly. 
Others are in favor of leaving them visible and callable.


*Type 1 ( Userland Programmer )**
*
As a userland programmer, someone who cares nothing for "how" php 
works, only how their own code works. If they define an accessor they 
expect to see an accessor, reflection should reflect that there are 
accessors and no other "methods" they did not explicitly define. If 
they were to reflect on all of the methods of their class and see a 
number of __getHours() they may be confused as to why or where this 
function came from. From their perspective, they have defined an 
accessor and "how" that accessor works on the inside is of no 
importance to them and only seeks to complicate or confuse matters 
when they are exposed to these "implementation details" of the php 
language its-self. If you tried to set a value such as $obj?abc = 1 
through an accessor which could not be set, you would probably want to 
see an error like: Warning, cannot set Class?abc, no setter defined.


*Type 2 ( Internals Programmer )**
*
As an internals programmer, you want nothing hidden from you. If an 
accessor implements special __getHours() methods to work its magic, 
then you want to see them, you want to call them directly if you so 
choose. In effect you want nothing hidden from you. In this case you 
probably don't even want Reflection to reflect accessors as anything 
different than specially formatted and called methods on the class. 
This can be understandable because you want all information available 
to you. You would probably not be confused if you wrote $obj?abc = 1 
and got back an error like "Fatal Error: Class->__setAbc() function 
does not exist.


*Unfortunately 80 to 95% of all people who use PHP are of the first 
type.**

*
Revealing these internal matters to them would only leave them 
confused, possibly frustrated and likely asking about it to the 
internals mailing list to answer (repeatedly).



Thoughts?



Speaking as a user-land programmer that's been following this thread, 
but hasn't been able to jump in yet due to the high volume of comments...


What's unclear to me is what my mental model should be for this new 
syntax.  That's important for informing how it should be exposed to me.


1) Should I have a mental model of this being some syntax candy on top 
of existing properties?  Vis, this is just a short-hand for bean-style 
classes?  By Bean style, I mean Properties that would be public but 
aren't because Public Is Bad(tm), so instead we have getX()/setX() for 
every property, so that we can still use the object like a struct rather 
than an object but still say we're using methods even though we've just 
reimplemented public properties with more verbose syntax.  (Note: Yes, I 
know that's a rather harsh and judgmental description.  I happen to 
firmly dislike Bean-style objects.)


2) Should I have a mental model that these fancy-pants properties are 
some different third thingie on objects, distinct from traditional data 
members and methods?


Right now I'm not sure which mental model I'm supposed to use, and I get 
the sense that there's no clear consensus on that question yet. That, I 
think, is the key question, and will inform how things like Reflection 
should expose data about this new syntax.


For instance, if model 2 is how I'm supposed to be thinking, then I'd 
expect I'd need a third reflection object for getting things off of an 
object/class, separate from traditional data members and methods.  Then 
it's consistently a third thingie.  If, however, I'm supposed to think 
of it as just a short-hand syntax for writing a bean, then I'd expect it 
to be presented to me as if I'd hand-written all of the stuff that this 
syntax is emulating.  Vis, methods show up as methods, and anything I'd 
be able to read/write directly without going through an intermediary 
method should show up as a property just as it does now.


Note: I'm speaking here of the mental model of the user, which does not 
necessarily have any relationship to the implementation details.  If I'm 
"supposed" to think of it as a third thingie, it doesn't matter that it 
may be implemented internally as syntactic sugar.  It should be 
presented to me as a third thingie, consistently, with the engine 
internal implementation details completely irrelevant.  (Which means 
they can be changed later if needs be.)


I don't know which mental model is intended, nor which one woul

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

[Clint Priest]

Stas, you should probably do some research before posting such non-sense:

http://en.wikipedia.org/wiki/Property_%28programming%29

Every language you mentioned has them.  Perhaps the confusion is that I 
am calling them accessors since other languages refer to accessors as 
"properties" while PHP refers to "properties" the way that other 
languages refer to them as "fields" or "data members."


By accessors I am simply referring to getters, setters (and in the case 
of php, issetter and unsetter).


On 10/27/2012 3:28 PM, Stas Malyshev wrote:

Hi!


What is "reflection hiding patches" referring to?  Reflection is changed
to reflect what the user has defined, that's what reflection is supposed
to be.. no?

No. Reflection is supposed to show which methods exist on a class, which
can be called from certain context, etc. This has nothing to do with
where they were defined.


Lastly, this idea that accessors is such a foreign concept is a bit
ridiculous.  You'd be hard pressed to find a modern/popular language
these days that doesn't have them, so if someone is confused about what

PHP doesn't have them. Also, by your definition, Python doesn't have
them - in Python, __ methods are regular methods. Also, by your
definition, Ruby doesn't have them either - in Ruby, you define them as
regular methods, and you very well can call them too:
http://stackoverflow.com/questions/621176/how-to-dynamically-call-accessor-methods-in-ruby#621193.
Javascript doesn't have them either. Java doesn't have them either. So
I'm not that hard pressed to find languages that don't follow your
model, as you can see.


--
-Clint

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Clint Priest]

Sounds like you're implying that the mere existence of a properly named 
function such as __prop_get_hours() would cause it to be called instead 
of returning the property.


There are several problems with this approach:

1) Currently __get() is only checked/invoked if there is not a property 
already defined; ie properties shadow __get() (no performance penalty)


2) It would dramatically reduce performance because every property 
access would have to create the function string, get it's hash value and 
do a hash look up against the function table, just to see if there is a 
properly named accessor function.  Failing that it would then check for 
the existence of a property and failing that move on to looking up __get


-Clint

On 10/27/2012 2:14 PM, Patrick Schaaf wrote:

On Saturday 27 October 2012 13:05:27 Clint Priest wrote:

That's why I think they shouldn't even be visible to users, they aren't
relevant to them and in fact it could mis-lead them into thinking that
they could simply define __getHours() and expect $foo->Hours to call
it, which it wouldn't.

I would expect / want it to do so.

I see it this way:

Defining semantics for magic methods named __prop_get_XXX, __prop_set_XXX etc
as a specialization of __get/__set used whenever they exist for a given $XXX,
is in my eyes a complete, proper accessor enhancement, saving me from doing a
switch dance in __get/__set. The implementation should be absolutely
straightforward, in the place where a missing property now tests for existence
of __get/__set, a first, additional test for the specifically named
__prop_get_XXX method would be added.

Your proposed accessor _syntax_ is purely syntactic sugar, implementable on
top of the functionality of the previous paragraph and implemented in terms of
automatic code generation for it. This syntactic sugar could be separately
implemented, discussed in a separate RFC,etc.

The added complexity that I see, and I think Stas has meant to mention a lot
of times, is everything - all code and documentation and explanation - that
stems from NOT making it that two-step process. And in my opinion that would
be completely superfluous, as it brings neither functionality nor syntax, just
random additional issues.

best regards
   Patrick



--
-Clint

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Stas Malyshev]

Hi!

> What is "reflection hiding patches" referring to?  Reflection is changed 
> to reflect what the user has defined, that's what reflection is supposed 
> to be.. no?

No. Reflection is supposed to show which methods exist on a class, which
can be called from certain context, etc. This has nothing to do with
where they were defined.

> Lastly, this idea that accessors is such a foreign concept is a bit 
> ridiculous.  You'd be hard pressed to find a modern/popular language 
> these days that doesn't have them, so if someone is confused about what 

PHP doesn't have them. Also, by your definition, Python doesn't have
them - in Python, __ methods are regular methods. Also, by your
definition, Ruby doesn't have them either - in Ruby, you define them as
regular methods, and you very well can call them too:
http://stackoverflow.com/questions/621176/how-to-dynamically-call-accessor-methods-in-ruby#621193.
Javascript doesn't have them either. Java doesn't have them either. So
I'm not that hard pressed to find languages that don't follow your
model, as you can see.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Stas Malyshev]

Hi!

> That's why I think they shouldn't even be visible to users, they aren't 
> relevant to them and in fact it could mis-lead them into thinking that 
> they could simply define __getHours() and expect $foo->Hours to call 
> it, which it wouldn't.

I think it should. That's how __get works.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Patrick Schaaf]

On Saturday 27 October 2012 13:05:27 Clint Priest wrote:
> That's why I think they shouldn't even be visible to users, they aren't
> relevant to them and in fact it could mis-lead them into thinking that
> they could simply define __getHours() and expect $foo->Hours to call
> it, which it wouldn't.

I would expect / want it to do so.

I see it this way:

Defining semantics for magic methods named __prop_get_XXX, __prop_set_XXX etc 
as a specialization of __get/__set used whenever they exist for a given $XXX, 
is in my eyes a complete, proper accessor enhancement, saving me from doing a 
switch dance in __get/__set. The implementation should be absolutely 
straightforward, in the place where a missing property now tests for existence 
of __get/__set, a first, additional test for the specifically named 
__prop_get_XXX method would be added.

Your proposed accessor _syntax_ is purely syntactic sugar, implementable on 
top of the functionality of the previous paragraph and implemented in terms of 
automatic code generation for it. This syntactic sugar could be separately 
implemented, discussed in a separate RFC,etc.

The added complexity that I see, and I think Stas has meant to mention a lot 
of times, is everything - all code and documentation and explanation - that 
stems from NOT making it that two-step process. And in my opinion that would 
be completely superfluous, as it brings neither functionality nor syntax, just 
random additional issues.

best regards
  Patrick


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Clint Priest]

On 10/26/2012 6:37 PM, Stas Malyshev wrote:

Hi!


Stas, if you define an accessor, how do you define it? Do you say

Either way, doesn't matter.


According to the current proposal at least you can write the first
code *and the first code only*. If you write the second code then you

That's where I think it is wrong. It would be much simpler and
consistent with existing PHP if it were a natural extension of __get
instead of a completely new and foreign concept.


special behavior for properties. You probably won't start off with
telling them that this declaration is automatically converted to a set
of __getFoo methods which are registered as handlers for the accessor.
I really don't see how going into details like __getFoo makes anything
easier.

Depending on your purpose and background. If you know how __get works,
extrapolating to __getFoo is trivial. Getting special syntax that
produces __getFoo from this is also trivial.

Getting the concept of methods that are not quite methods and get called
only through special intercept mechanism and have special backtrace
rewriting engine and reflection hiding patches so you can be inside the
method that officially does not exist - not so trivial.
The only thing that does back patching is for static accessors and 
you've already pointed out that what I was doing to make that happen is 
just going to break and fail in so many ways.


What is "reflection hiding patches" referring to?  Reflection is changed 
to reflect what the user has defined, that's what reflection is supposed 
to be.. no?


Lastly, this idea that accessors is such a foreign concept is a bit 
ridiculous.  You'd be hard pressed to find a modern/popular language 
these days that doesn't have them, so if someone is confused about what 
an accessor is then they probably have their head in the sand, god 
forbid they'd have to read the manual.


--
-Clint

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Clint Priest]

That's why I think they shouldn't even be visible to users, they aren't 
relevant to them and in fact it could mis-lead them into thinking that 
they could simply define __getHours() and expect $foo->Hours to call 
it, which it wouldn't.


To me, the bottom line is, the fact that there are methods defined by 
accessors is an engine detail and not something that should be exposed 
to the user.


As for the __set_state() issue, I can see the need to change the 
pattern of method naming, I'd be amenable to anything.


Everyone okay with __get_prop_hours() naming convention then?

On Saturday, October 27, 2012 3:01:39 AM, Patrick Schaaf wrote:

- i.e. name them __prop_get_xxx, __prop_set_xxx, and so on.


I think it'd more natural to make it __set__PROPNAME. Though __set_state
is a static method, so maybe we can live with it - except that you won't
be able to declare property named $_state.


Needing an "except" is inelegant, if it can be avoided up front.

Also, having __prop_get_XXX etc. is a bit more descriptive to somebody
later "wondering" what these methods are - prop alludes to properties,
which is what the methods are about. I can already see the stack overflow
subject, "what are these __prop methods in new PHP" :)

best regards
   Patrick



--
-Clint


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Patrick Schaaf]

> > - i.e. name them __prop_get_xxx, __prop_set_xxx, and so on.
>
> I think it'd more natural to make it __set__PROPNAME. Though __set_state
> is a static method, so maybe we can live with it - except that you won't
> be able to declare property named $_state.

Needing an "except" is inelegant, if it can be avoided up front.

Also, having __prop_get_XXX etc. is a bit more descriptive to somebody
later "wondering" what these methods are - prop alludes to properties,
which is what the methods are about. I can already see the stack overflow
subject, "what are these __prop methods in new PHP" :)

best regards
  Patrick

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

[Stas Malyshev]

Hi!

> Stas, if you define an accessor, how do you define it? Do you say

Either way, doesn't matter.

> According to the current proposal at least you can write the first
> code *and the first code only*. If you write the second code then you

That's where I think it is wrong. It would be much simpler and
consistent with existing PHP if it were a natural extension of __get
instead of a completely new and foreign concept.

> special behavior for properties. You probably won't start off with
> telling them that this declaration is automatically converted to a set
> of __getFoo methods which are registered as handlers for the accessor.
> I really don't see how going into details like __getFoo makes anything
> easier.

Depending on your purpose and background. If you know how __get works,
extrapolating to __getFoo is trivial. Getting special syntax that
produces __getFoo from this is also trivial.

Getting the concept of methods that are not quite methods and get called
only through special intercept mechanism and have special backtrace
rewriting engine and reflection hiding patches so you can be inside the
method that officially does not exist - not so trivial.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Nikita Popov]

On Fri, Oct 26, 2012 at 10:34 PM, Stas Malyshev  wrote:
> Hi!
>
>> users control. Actually, both approaches are exactly the same, the
>> only difference is whether we additionally put the accessor function
>> into the method table or whether we do not.
>
> They may be almost the same technically, but very different
> conceptually. Your approach means we introduce new complex concept of
> not-quite-method, which can be called only in some special
> circumstances, has special handling by compiler, backtraces, reflection,
> tools, etc. and requires people to learn this new concept and be always
> aware of it to be able to correctly operate it. My approach is that you
> just have another magic method, which we already have plenty in PHP, and
> does not require any new concepts introduced, and works very similar to
> existing access magics.
>
>> I still fail to see where you see complexity come into the picture.
>
> Described above. You want to introduce new entity into PHP called
> "accessor", which looks like PHP method, but lives outside of the PHP
> method table, is not callable by regular means (though might be callable
> by special means, but you have no way to use methods' reflection to know
> if such call would succeed or not) and requires special considerations.
> This is more complex than using already existing concepts, by definition
> - more concepts is more complex than less concepts.
>
>> You have mentioned inheritance checking, but from what I see the
>> functions doing the inheritance check take generic zend_function*s, so
>> they wouldn't have a problem dealing with code not in the method
>> table. The same applies to pretty much everything else too. After all,
>> there *is* a reason why we have abstractions in the engine ;)
>
> They won't have a problem. They won't deal with these not-quite-methods.
> That's exactly the problem - we already have mechanism of dealing with
> inheritance, and you propose to introduce another one to deal with
> additional complexity of methods not in method table.
>
>> To me the situation is as simple as this: I declared a get accessor
>> for $foo. I did not declare the method __getfoo(). So why is that
>> method there?
>
> This in not simple. You know what "accessor" is. The other 100% of PHP
> users have no idea what "accessor" is. They know what methods are, they
> know what magics are. So if I tell them "we have extensions of __get
> that allow you to do __getFoo" - they instantly know what's going on. If
> I tell them "we have accessors" - they'd have to go and read the manual
> to understand what is going on and which additional restriction you
> placed on them in order to force them into your preconception of
> "accessor".
>
>> It seems really pointless, counter-intuitive and hacky to me to
>> automatically create methods that do not actually exist (not under
>> that name at least).
>
> What you mean by "do not actually exist"? Of course they exist, that's
> the whole point. You will be running them, how they don't exist? You
> just want hide their existence by introducing a bunch of complex checks
> all over the engine under the premise that showing the user the real
> methods in function table would "confuse" them. It won't. The only thing
> it would do is contradict your idea that there's some definition of
> "accessors" that requires them to not be methods. I see no reason for
> such definition. It is an option, but having them as methods is an
> option too, and in my opinion a much better one.

Stas, if you define an accessor, how do you define it? Do you say

 public $foo {
  get() { ... }
  set($value) { ... }
 }

or do you say

 public function __getFoo() { ... }
 public function __setFoo($value) { ... }

?

According to the current proposal at least you can write the first
code *and the first code only*. If you write the second code then you
define two methods __getFoo and __setFoo and nothing more. Those
methods will not be called when you write $bar->foo. If just defining
the methods would cause $bar->foo to be intercepted, *then* __getFoo
etc would indeed be just magic methods with "dynamic" names. But as
already said, this is not the case, so you would have
magic-methods-which-aren't-really-magic-methods (extra for you, as you
like the term not-quite-method so much ^^).

You keep saying that the term "accessors" would be somehow a lot
harder to understand for users and that telling them something about
__getFoo and __setFoo will be easier to grasp. I don't know about you,
but I think that if you want to explain this new shiny feature to a
user you would start off with a code like public $foo { get() { ... }
... } and explain that that those are accessors and are used to define
special behavior for properties. You probably won't start off with
telling them that this declaration is automatically converted to a set
of __getFoo methods which are registered as handlers for the accessor.
I really don't see how going in

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

[Stas Malyshev]

Hi!

> an accessor setter method for a property $_state IF that method would
> follow the __set$PROPNAME pattern. As a solution for that, I'd propose
> naming the new magic methods with a so-far-not-taken common prefix: __prop
> - i.e. name them __prop_get_xxx, __prop_set_xxx, and so on.

I think it'd more natural to make it __set__PROPNAME. Though __set_state
is a static method, so maybe we can live with it - except that you won't
be able to declare property named $_state.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Stas Malyshev]

Hi!

> users control. Actually, both approaches are exactly the same, the
> only difference is whether we additionally put the accessor function
> into the method table or whether we do not.

They may be almost the same technically, but very different
conceptually. Your approach means we introduce new complex concept of
not-quite-method, which can be called only in some special
circumstances, has special handling by compiler, backtraces, reflection,
tools, etc. and requires people to learn this new concept and be always
aware of it to be able to correctly operate it. My approach is that you
just have another magic method, which we already have plenty in PHP, and
does not require any new concepts introduced, and works very similar to
existing access magics.

> I still fail to see where you see complexity come into the picture.

Described above. You want to introduce new entity into PHP called
"accessor", which looks like PHP method, but lives outside of the PHP
method table, is not callable by regular means (though might be callable
by special means, but you have no way to use methods' reflection to know
if such call would succeed or not) and requires special considerations.
This is more complex than using already existing concepts, by definition
- more concepts is more complex than less concepts.

> You have mentioned inheritance checking, but from what I see the
> functions doing the inheritance check take generic zend_function*s, so
> they wouldn't have a problem dealing with code not in the method
> table. The same applies to pretty much everything else too. After all,
> there *is* a reason why we have abstractions in the engine ;)

They won't have a problem. They won't deal with these not-quite-methods.
That's exactly the problem - we already have mechanism of dealing with
inheritance, and you propose to introduce another one to deal with
additional complexity of methods not in method table.

> To me the situation is as simple as this: I declared a get accessor
> for $foo. I did not declare the method __getfoo(). So why is that
> method there?

This in not simple. You know what "accessor" is. The other 100% of PHP
users have no idea what "accessor" is. They know what methods are, they
know what magics are. So if I tell them "we have extensions of __get
that allow you to do __getFoo" - they instantly know what's going on. If
I tell them "we have accessors" - they'd have to go and read the manual
to understand what is going on and which additional restriction you
placed on them in order to force them into your preconception of
"accessor".

> It seems really pointless, counter-intuitive and hacky to me to
> automatically create methods that do not actually exist (not under
> that name at least).

What you mean by "do not actually exist"? Of course they exist, that's
the whole point. You will be running them, how they don't exist? You
just want hide their existence by introducing a bunch of complex checks
all over the engine under the premise that showing the user the real
methods in function table would "confuse" them. It won't. The only thing
it would do is contradict your idea that there's some definition of
"accessors" that requires them to not be methods. I see no reason for
such definition. It is an option, but having them as methods is an
option too, and in my opinion a much better one.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Nikita Popov]

On Fri, Oct 26, 2012 at 4:14 PM, Stas Malyshev  wrote:
> Hi!
>
>> Some people are in favor of the internal functions being generated by an
>> accessor declaration should be invisible and non-callable directly.
>> Others are in favor of leaving them visible and callable.
>
> I think these types are not right. It has nothing to do with
> internals/userland, it has to do with wanting more magic that work is a
> complex way while allowing user no knowledge and control over what's
> going on, or reduced number of simple concepts that interact in a
> variety of ways.
I think you are presenting the situation inaccurately. This has
nothing to do with complex magic and also does not intend to limit the
users control. Actually, both approaches are exactly the same, the
only difference is whether we additionally put the accessor function
into the method table or whether we do not.

I still fail to see where you see complexity come into the picture.
You have mentioned inheritance checking, but from what I see the
functions doing the inheritance check take generic zend_function*s, so
they wouldn't have a problem dealing with code not in the method
table. The same applies to pretty much everything else too. After all,
there *is* a reason why we have abstractions in the engine ;)

To me the situation is as simple as this: I declared a get accessor
for $foo. I did not declare the method __getfoo(). So why is that
method there?

It seems really pointless, counter-intuitive and hacky to me to
automatically create methods that do not actually exist (not under
that name at least).

Nikita

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Patrick Schaaf]

I'm all for having the "internal" methods being totally normal magic
methods, for the reduced complexity reasons already mentioned.

I would also expect to be able to simply define such a magic method myself,
and have it behave in just the same way as when defining it using the
accessor declaration syntactic sugar.

To formulate it a different way: first expand on the current __get/__set
magic methods by clearly documenting a new set of per-property-name magic
methods, and the rules when they are called. Then on top of that, introduce
and document the accessor declaration syntactic sugar.

One point that came up some time ago, I'd like to mention again: there is
already a magic method named __set_state which would collide head on with
an accessor setter method for a property $_state IF that method would
follow the __set$PROPNAME pattern. As a solution for that, I'd propose
naming the new magic methods with a so-far-not-taken common prefix: __prop
- i.e. name them __prop_get_xxx, __prop_set_xxx, and so on.

best regards
  Patrick

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

[Stas Malyshev]

Hi!

> Some people are in favor of the internal functions being generated by an 
> accessor declaration should be invisible and non-callable directly. 
> Others are in favor of leaving them visible and callable.

I think these types are not right. It has nothing to do with
internals/userland, it has to do with wanting more magic that work is a
complex way while allowing user no knowledge and control over what's
going on, or reduced number of simple concepts that interact in a
variety of ways. You can say it's Windows model vs. Unix model, if you
need monikers.

> *Type 1 ( Userland Programmer )**
> *
> As a userland programmer, someone who cares nothing for "how" php works, 
> only how their own code works. If they define an accessor they expect to 
> see an accessor, reflection should reflect that there are accessors and 

Again, this insists on the notion that there's such accepted thing as
"accessor" in PHP field, which already has a known behavior and set of
expectations, and these match exactly the proposal of "invisible". But
this is not true at all - only successors existing so far in PHP are
regular perfectly visible methods. So if you expect to see an accessor,
you expect to see __get. If you appeal to natural expectations of PHP
user, you can not argue it is "for accessors to be accessors", because
PHP has never had anything like you proposed, and there's no any
accepted definition of "accessor" that implies what you are implying.

> no other "methods" they did not explicitly define. If they were to 
> reflect on all of the methods of their class and see a number of 
> __getHours() they may be confused as to why or where this function came 

Please do not insult the intelligence of PHP users. They are not some
mindless creatures that given property Hours, previous existence of
__get and __getHours can not figure out what's going on, even after
being told of the new accessors feature (since they're using it in the
code). They won't be confused. Nobody knowing how to program a
hello-world would. This mythical easily-confusable users do not exist,
but if they did, they'd just not use reflection because it'd be too
confusing for them anyway.

> than specially formatted and called methods on the class. This can be 
> understandable because you want all information available to you. You 

This has very little to do with information available. This has
everything to do with

> would probably not be confused if you wrote $obj?abc = 1 and got back an 
> error like "Fatal Error: Class->__setAbc() function does not exist.

You can very easily handle the error in the same handler that you look
for setter, this is not an issue at all. In general, error messages have
very little to do with the whole thing. If the error messages is the
thing you're worried about - it should be trivially easy to fix, since
all access will go through object handlers anyway, and the object
handler would decide to throw the error - so you'd be able very easily
to issue any error message you like.

> *Unfortunately 80 to 95% of all people who use PHP are of the first type.**

Not really. There are a lot of programmers that aren't Windows type, and
prefer simple interfaces to ones with a lot of complicated magic. --
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Steve Clay]

On 10/26/12 6:37 AM, Clint Priest wrote:

https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests

Some people are in favor of the internal functions being generated by an 
accessor
declaration should be invisible and non-callable directly. Others are in favor 
of leaving
them visible and callable.


If we leave them callable,

* What would be the effects of users defining the "internal" methods (in both cases of 
if/if not the accessor is also defined)? Considering current magic methods are 
*purposefully designed* to be implemented by the user, I expect users to try this and, if 
it works, release code with it.


* I assume one could use them as regular methods?
   * call_user_func([$foo, '__getpropName']);
   * $foo->{"__get$propName"}

I apologize if these were already covered.

Steve Clay
--
http://www.mrclay.org/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

[Clint Priest]

I'm opening up several new threads to get discussion going on the 
remaining "being debated" categories referenced in this 1.1 -> 1.2 
change spec:

https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests


Some people are in favor of the internal functions being generated by an 
accessor declaration should be invisible and non-callable directly. 
Others are in favor of leaving them visible and callable.


*Type 1 ( Userland Programmer )**
*
As a userland programmer, someone who cares nothing for "how" php works, 
only how their own code works. If they define an accessor they expect to 
see an accessor, reflection should reflect that there are accessors and 
no other "methods" they did not explicitly define. If they were to 
reflect on all of the methods of their class and see a number of 
__getHours() they may be confused as to why or where this function came 
from. From their perspective, they have defined an accessor and "how" 
that accessor works on the inside is of no importance to them and only 
seeks to complicate or confuse matters when they are exposed to these 
"implementation details" of the php language its-self. If you tried to 
set a value such as $obj?abc = 1 through an accessor which could not be 
set, you would probably want to see an error like: Warning, cannot set 
Class?abc, no setter defined.


*Type 2 ( Internals Programmer )**
*
As an internals programmer, you want nothing hidden from you. If an 
accessor implements special __getHours() methods to work its magic, then 
you want to see them, you want to call them directly if you so choose. 
In effect you want nothing hidden from you. In this case you probably 
don't even want Reflection to reflect accessors as anything different 
than specially formatted and called methods on the class. This can be 
understandable because you want all information available to you. You 
would probably not be confused if you wrote $obj?abc = 1 and got back an 
error like "Fatal Error: Class->__setAbc() function does not exist.


*Unfortunately 80 to 95% of all people who use PHP are of the first type.**
*
Revealing these internal matters to them would only leave them confused, 
possibly frustrated and likely asking about it to the internals mailing 
list to answer (repeatedly).



Thoughts?

--
-Clint