Re: [PHP-DEV] PR 186: external protocols and locale independent string conversion

[Alec Smecher]

On 26/09/12 04:02 PM, Alec Smecher wrote:

On 20/09/12 12:02 PM, Alec Smecher wrote:
It looks to me like a textbook use case of pg_query_params will 
currently fail depending on what locale is being used. What Claude at 
 and Lars here are 
trying to do is make it a general fix, which is good -- but the 
problem is best exemplified IMO by the above snippet. The work-around 
suggested by j...@php.net 
(https://bugs.php.net/bug.php?id=46408#1227272959) illustrates further:


$oldLocale = setlocale(LC_NUMERIC, 'C');
pg_query_params($conn, 'INSERT INTO myTable (myColumn) values ($1)', 
array(3.5));

setlocale(LC_NUMERIC, $oldLocale);

That's an example of a work-around for a broken API in my opinion.


Ping. Any feedback on this?
Excuse my persistence. There must be a fix for this at the PHP level 
that's palatable to you folks...


Thanks,
Alec

--
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, 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 : Extra shorthand declaration

[Stas Malyshev]

Hi!

> I just have one question: can we drop `public`? Default visibility in

We already had var, it didn't prove a good idea. PHP is explicit for a
reason, to be clear.
-- 
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]

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 : Extra shorthand declaration

[Levi Morrison]

> 
> *Extra shorthand declaration*
>
> Allow extra short declaration of an accessor:
>
> class TimePeriod {
> public DateTime $date;
> }
>
> /* Would be equivalent to this */
>
> class TimePeriod {
> public $date {
> get() { return $this->date; }
> set(DateTime $value) { $this->date = $value;}
> }
> }

This is lovely. Full support from me.

I just have one question: can we drop `public`? Default visibility in
methods is public, so maybe we can drop it when using type-hinted
properties? Just an idea; no worries if it needs to stay.

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

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset "failable"

[Stas Malyshev]

Hi!

>  1.  If all cases can be tested for during compilation, prefer
> compile failures.

Not likely. isset($foo->$bar) is completely opaque since we don't know
what $foo or $bar is.

>  2.  Let the compilation occur and at runtime when a disallowed
> action is attempted, emit a warning and move on.
>  3.  As is currently, either at compilation or at runtime we issue a
> fatal error and stop execution (probably least preferable if at runtime)

Actually, I think the right way is:

4. On isset(), if the value can be retrieved, return true. Otherwise,
return false (including the case when the value can not be retrieved
because of missing getter). Same holds for empty() but in reverse - if
isset() would return false, it'd return true and vice versa.
On unset($foo->bar), act exactly as if the code were $foo->bar = NULL;

Of course, this applies only for automatic definition of isset/unset.
-- 
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] Propety Accessors v1.1

[Cal]

Le 08/10/2012 14:27, Amaury Bouchard a écrit :

My idea was to write attribute's visibility like
"read_visiblity:write_visibility $attr;"
   public:protected $foo; // public reading, protected writing
   public:private $bar; // public reading, private writing
   protected:private $aaa; // protected reading, private writing
   protected:const $bbb; // protected reading, no writing


I read all the messages on the property accessors. And I really agree 
with the solution of Amaury. It is a nice solution: not verbose, not 
slower, just covers most of developper's needs.


Cal

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

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Extra shorthand declaration

[Stas Malyshev]

Hi!

> /* Would be equivalent to this */
> 
> class TimePeriod {
>  public $date {
>  get() { return $this->date; }
>  set(DateTime $value) { $this->date = $value;}
>  }
> }

I don't think this has a use case and this encourages mixing variables
with properties (which I'm not sure is a very good idea) and writing
slower and more complicated code which doesn't actually do any
additional work. I'd rather not encourage it. If you want it - fine,
implement it, but I don't think supporting it is good.

Also, "get() { return $this->date; }" implies there is a thing called
"$this->date" which is not the property itself. So what is it? Should
there be additional "public $date;" declaration in your code? Is it
implied that property definition also creates a variable inside class
automatically - I was under expression this does not happen, and nothing
in the RFC implies it. Should it be $this->__date maybe like in
"automatic accessors" part of the RFC?
-- 
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 1.2 : Shadowing

[Stas Malyshev]

Hi!

> v1.2 Proposes that this be inverted such that if there is an accessor 
> defined for a given property name, the accessor will always be used. The 
> accessor would be able to get/set/isset/unset the property with the same 
> name as the accessor. No direct access to the property would be allowed 
> except from within the accessor.

One of the deficiencies frequently mentioned for __get was "what if I
want to override access for existing variable?" Given that, I think
accessor priority is a good thing.
Now, with direct access from within the accessor it may get a bit
tricky, especially considering loops, etc. What would happen in the
scenario of __getHours calling foo() which does "return $this->Hours"?
Is __getHours called again? Is it a fatal error? Does it return
"undefined" like __get does?

> v1.2 proposal seems to make the most sense however it would incur a 
> slight (possibly *very* slight) performance penalty.

It may be an extra hash lookup, but if we could probably add the
existence of accessor (or maybe even pointer) into zend_property_info
then we wouldn't need the second hash lookup probably.
-- 
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!

> 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

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

[Maciek Sokolewicz]

On 26-10-2012 12:37, Clint Priest wrote:


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?



I personally don't think there's such a huge difference between the two 
'groups'. When people in group 1 use reflection to examine their 
accessors, they should have enough knowledge to understand how accessors 
are implemented. If we document it well, I don't really see that as a 
problem.


- Tul


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

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Extra shorthand declaration

[Jazzer Dane]

Is the only intended benefit behind this proposal the ability to seamlessly
extend a seemingly normal property as an accessor?

On Fri, Oct 26, 2012 at 3:43 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
>
> --**--**
> 
> *Extra shorthand declaration*
>
> Allow extra short declaration of an accessor:
>
> class TimePeriod {
> public DateTime $date;
> }
>
> /* Would be equivalent to this */
>
> class TimePeriod {
> public $date {
> get() { return $this->date; }
> set(DateTime $value) { $this->date = $value;}
> }
> }
>
> --**--**
> 
> Thoughts?
>
> --
> -Clint
>
>

[PHP-DEV] [RFC] Property Accessors v1.2 : Extra shorthand declaration

[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


*Extra shorthand declaration*

Allow extra short declaration of an accessor:

class TimePeriod {
public DateTime $date;
}

/* Would be equivalent to this */

class TimePeriod {
public $date {
get() { return $this->date; }
set(DateTime $value) { $this->date = $value;}
}
}


Thoughts?

--
-Clint

[PHP-DEV] [RFC] Property Accessors v1.2 : Interfaces

[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

v1.1 fully allows accessors to be defined in interfaces and requires 
that those accessors be defined in implementing classes. Some people 
have suggested that a property defined by the class should also satisfy 
the requirement.


*Arguments For*

 *  From the outside observer of an interface, a class which defines a
   property has satisfied the requirement, because an interface only
   defines what must be allowed, not what cannot be done.


*Arguments Against*

 * Additional overhead on interface checking, would only be allowed for
   a non-asymmetrical accessor
 * Would give userland developers the ability to write poor code as
   properties are non-observable (object would not know its property
   was changed)



Thoughts?

--
-Clint

[PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset "failable"

[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


*isset / unset / attempted writes when no setter / attempted reads when 
no getter**

*
Stas suggested that since there is presently no cases where these can 
fail that with accessors these should never "fail."


Three possible ways to go (maybe others):

1.  If all cases can be tested for during compilation, prefer
   compile failures.
2.  Let the compilation occur and at runtime when a disallowed
   action is attempted, emit a warning and move on.
3.  As is currently, either at compilation or at runtime we issue a
   fatal error and stop execution (probably least preferable if at runtime)

If "no failures" should be the way we want to go, then #2 or some 
derivative makes the most sense.



Thoughts?

--
-Clint

[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

[PHP-DEV] [RFC] Property Accessors 1.2 : Shadowing

[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

Shadowing

v1.1 has properties shadow accessors, the suggestion is that this be 
inverted. Specifically this means that in v1.1, if an accessor is 
defined and no property is defined, then the accessor will be used. But 
when a property is assigned/declared then the property will “shadow” the 
accessor and the accessor will no longer be used until the property is 
unset().


v1.2 Proposes that this be inverted such that if there is an accessor 
defined for a given property name, the accessor will always be used. The 
accessor would be able to get/set/isset/unset the property with the same 
name as the accessor. No direct access to the property would be allowed 
except from within the accessor.


v1.2 proposal seems to make the most sense however it would incur a 
slight (possibly *very* slight) performance penalty.


Thoughts?

--
-Clint


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