Re: [PHP-DEV] [VOTE] CURLFile uploading API

[Stas Malyshev]

Hi!

> Thanks for running with this concept! Looks great to me...

Thanks. I think it needs one more addition, actually - it may be a good
idea to have special handling for serializing/unserializing - but I'll
look into it after the vote, it shouldn't change anything related to the
main 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] [VOTE] CURLFile uploading API

[Anthony Ferrara]

Stas,

Thanks for running with this concept! Looks great to me...

Anthony


On Sun, Jan 20, 2013 at 8:32 PM, Stas Malyshev wrote:

> Hi!
>
> I've started a vote on CURLFile RFC:
> https://wiki.php.net/rfc/curl-file-upload#vote
>
> Please vote.
> --
> 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
>
>

[PHP-DEV] [VOTE] CURLFile uploading API

[Stas Malyshev]

Hi!

I've started a vote on CURLFile RFC:
https://wiki.php.net/rfc/curl-file-upload#vote

Please vote.
-- 
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] [VOTE] Property Accessors for 5.5

[Crypto Compress]

Hello Clint, Nikita and Stas.

> To facilitate complete functionality with properties it is necessary to
> provide accessor functions to act on isset() and unset() calls.
> Note: isset & unset implementations are always provided with default
> implementations unless the author explicitly defines their own.

a) With magic methods we can make the accessed property inaccessible (as
properties may appear/disappear at runtime) and so we need some magic there
(__isset/__unset as of 5.1).
A property (accessors) is defined at design-time and may not become
inaccessible so the default implementation for isset/unset should be 
sufficient.


b) Result of (unset)$this->foo is always NULL.
If we provide a way to alter this "set(NULL)" behavior:
- it may fail before calling set(NULL)
- unset($this->foo); $this->foo !== (unset)$this->foo; // foo is not foo?

c) Logically isset/unset methods wrap up getter/setter at a higher level.
Maybe both methods are better suited for "operator 
overloading/overriding RFC"

where i would again expect some magic too.

I wonder what the functionality would be as someone have to override
isset/unset accessors. Do you have some examples?

cryptocompress

http://3v4l.org/NJWsW


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

Re: [PHP-DEV] [VOTE] Property Accessors for 5.5

[Gordon Oheim]

Am 17.01.2013 19:20, schrieb Clint Priest:

I'm happy to say that Property Accessors is ready for a vote for
inclusion in 5.5 release.

Nikita and I (as well as Stas a bit) have all been working hard to make
this happen for 5.5, voting and the specifications are here:

https://wiki.php.net/rfc/propertygetsetsyntax-v1.2#voting

Thanks,

-Clint


Thanks Clint and Niki for your work. Sorry to respond only now that the 
voting process has already started. I usually don't follow/participate 
on internals due to the noise and poisoned atmosphere (but that's a 
different story). Also thanks Niki for taking the time to answer all my 
questions I had about this beforehand.


IMO, the new getter/setter syntax adds very little benefit for the loads 
of syntax it introduces. I understand that people are looking forward to 
that new feature though, so I won't oppose it just because I have little 
use for it.


My main issue with the implementation at hand is the weird way in which 
we allow the visibility on the properties to be declared, e.g.


public $foo { get; protected set; }

The visibility keyword on the property is watering down the visibility 
semantics. Either the property is public (then it can be set) or it is 
not public. I would have much less of a problem with this, if declaring 
visibility on a property could only be loosened but not tightened. That 
would at least be consistent with how visibility works with inheritance. 
It would be much better though to remove the visibility keyword from the 
property altogether. It almost never tells the truth.


Removing the visibility keyword from the property altogether would also 
remove the purported default visibility that is applied to the 
accessors. I say "purported" because doing


public $foo { get; protected set; }

will also change the unset accessor to protected, which makes perfect 
sense when you think about it but is completely unobvious when the 
declaration claims the default visibility of all accessors to be public. 
The default visibility of isset is that of get and the default 
visibility of unset is that of set instead.


To add to the confusion, doing

public $foo { get; protected set; public unset; }

WILL work and change the visibility of unset back to what the property 
claims it is. This should not be necessary when visibility on the 
keyword defines the default visibility. I guess it's safe to say that 
having the visibility on the property does very little to express 
anything meaningful about the property or the default visibility of 
*all* the accessors.


I briefly discussed possible solutions to this problem with Niki. Simply 
removing the visibility looks odd


$foo { get; protected set; public unset; }

but might be the easiest approach. The above would follow the same rules 
visibility follows for any other methods, e.g. omitting the visibility 
on the accessor will make it public.


Both of us are not keen on introducing new keywords, though I find

property $foo { get; protected set; public unset; }

quite nice and it is also more obvious that this is not your regular 
property. Niki suggested


var $foo { get; protected set; public unset; }

but it's keyword recycling and one could argue that in PHP4 a var was 
always public. But then again, PHP4 didn't have the concept of 
visibility at all, so why not?


If this could be changed, I'd be more willing to vote pro the proposal.

TL;DR: The visibility keyword on the property is almost never giving an 
accurate information about the accessor visibility. Thus, it should be 
removed or replaced for clarity's sake.


Regards,
Gordon

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

[PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context

[Gustavo Lopes]

I've opened the vote for the "remove calls from incompatible context" RFC:

https://wiki.php.net/rfc/incompat_ctx#vote

--
Gustavo Lopes

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

Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors

[Nikita Popov]

On Sun, Jan 20, 2013 at 4:47 PM, Clint Priest  wrote:

>
> On 1/20/2013 9:26 AM, Nikita Popov wrote:
>
>> I now added a patch for this proposal: 
>> https://gist.github.com/**4579298(For
>> more detailed individual commits see here:
>> https://github.com/nikic/php-**src/commits/alternativeSyntax
>> )
>>
> One thing I hadn't noticed is that the proposal was to move the typehint,
> what happens in this case then:
>
> public DateTime $date {
> get;
> set(stdClass $value);
> }
>
> Would the above produce a compilation error on the stdClass part?
>

Yes, that's an error. And I'm not sure what that is supposed to mean in the
first place (it has two different typehints at two different places...)

This proposal will allow a typehint before the property name and only
there. Allowing one in both places doesn't make much sense to me.

Nikita

Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors

[Clint Priest]

On 1/20/2013 9:26 AM, Nikita Popov wrote:

I now added a patch for this proposal: https://gist.github.com/4579298 (For
more detailed individual commits see here:
https://github.com/nikic/php-src/commits/alternativeSyntax)
One thing I hadn't noticed is that the proposal was to move the 
typehint, what happens in this case then:


public DateTime $date {
get;
set(stdClass $value);
}

Would the above produce a compilation error on the stdClass part?

--
-Clint

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

Re: [PHP-DEV] [VOTE] Property Accessors for 5.5

[Sherif Ramadan]

On Sun, Jan 20, 2013 at 10:31 AM, Clint Priest  wrote:

>
> On 1/20/2013 7:35 AM, Sherif Ramadan wrote:
>
>   Now $surface shows us the following from var_dump
>
>  object(surface)#1 (3) {
>   ["area"]=>
>   NULL
>   ["width"]=>
>   int(4)
>   ["height"]=>
>   int(2)
> }
>
> Sounds like a reasonable approach to me... var_dump()
>
> 1) Should not invoke the getters..
>

I can agree this since the side effects could be unpredictable (as in the
case of an accessor implementing an actual method rather than dealing with
with any values -- the performance loss is unjustified)


> 2) Should indicate that they are property accessors (perhaps not even show
> the underlying guarded property?)
>

That is a sensible approach to me.


>
> Possibly:
>
>  object(surface)#1 (3) {
>   ["area":accessor]=>
>   NULL
>   ["width":accessor]=>
>   int(4)
>   ["height":accessor]=>
>   int(2)
> }
>
> This could easily be changed if nobody had any further disagreements with
> this?
>
> Only issue I could see would be existing code that may parse var_dump()
> might break if it wasn't written to accept something other that
> private/protected...
>

I think that one should rely on serialize or json_* serialization methods
or parsing data structures as opposed to var_dump output, since var_dump
doesn't always provide parseable output. Look at the output of DateTime
objects from var_dump or DateInterval objects, which have changed a bit
over 5.2 -> 5.3 and other objects like DOMDocument, which at one point did
not have any meaningful var_dump output at all.


>
>
> --
> -Clint
>

Re: [PHP-DEV] [VOTE] Property Accessors for 5.5

[Clint Priest]

On 1/20/2013 7:35 AM, Sherif Ramadan wrote:

Now $surface shows us the following from var_dump

object(surface)#1 (3) {
  ["area"]=>
  NULL
  ["width"]=>
  int(4)
  ["height"]=>
  int(2)
}

Sounds like a reasonable approach to me... var_dump()

1) Should not invoke the getters..
2) Should indicate that they are property accessors (perhaps not even 
show the underlying guarded property?)


Possibly:

object(surface)#1 (3) {
  ["area":accessor]=>
  NULL
  ["width":accessor]=>
  int(4)
  ["height":accessor]=>
  int(2)
}

This could easily be changed if nobody had any further disagreements 
with this?


Only issue I could see would be existing code that may parse var_dump() 
might break if it wasn't written to accept something other that 
private/protected...


--
-Clint

Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors

[Nikita Popov]

On Thu, Jan 10, 2013 at 11:11 PM, Stas Malyshev wrote:

> Hi!
>
> The proposal is pretty clear, but could you explain this part:
>
> The current accessors proposal will need special handling of the
> typehint in any case (it can't be handled as a normal method typehint).
>
> What special handling is required?
>

I now added a patch for this proposal: https://gist.github.com/4579298 (For
more detailed individual commits see here:
https://github.com/nikic/php-src/commits/alternativeSyntax)

If there are no more issues I'll start the vote on this.

Nikita

Re: [PHP-DEV] [VOTE] Property Accessors for 5.5

[Gustavo Lopes]

On Sun, 20 Jan 2013 14:52:36 +0100, Sherif Ramadan  
 wrote:



I think the current behavior is most appropriate one for var_dump() (and
array casts/get_object_vars()). It's the same behavior as if you had
manually defined getXXX() methods or used __get().


It's actually not the same behavior at all. __get can only work on
inaccessible properties. So I would not see NULL there in the object and
then get a value in the instance property.


OK, it's not 100% analogous. And I'm ready to concede that the differences  
that do exist may be (arguably) sufficient to draw a principled  
distinction, namely:


* getXXX() is clearly a method call and not a (direct) property read and  
the XXX property may not even exist.
* __get() only works on inaccessible properties, so there is no possible  
confusion.


I still think you put too much emphasis on the __get() argument -- even  
though there is no accessible property, there may be a protected/private  
property; it it isn't the case, there's still usually some backing  
storage, like a private array (shown in var_dump()) and the backing value  
may be different from what's returned.


In any case, assuming this feature is accepted, the current solution,  
whether in isolation it's appropriate or not, must be evaluated in the  
light of the alternatives. Here, I thought you were proposing calling the  
getters.



If you start marking function calls, you get new problems like handling
getters that throw exceptions or have side effects ("the code behaves
differently when add a var_dump()?!").



I'm not suggesting the getters should be invoked from afar. I'm just
suggesting some additional means of informing the user of the existence  
of that getter to distinguish it from the property in the output of  
var_dump.


So for example, in var_dump, you can get ["property":protected] => ...  
when the property has a visibility outside of the current context. It  
might be

helpful to provide some similar behavior for accessors with null
initialized values, but have getters available to the caller?


We could add some sort of marker to indicate the property is an accessor.  
It would not be trivial under the current implementation as  
get_properties() and get_debug_info() only return a HashTable*, so some  
abstraction breaking would be required.


Another possibility would be the ability to mark some properties as not  
backed by any storage, like the area in your example. But this would still  
be insufficient to eliminate confusion in cases like this:


class A {
private $scale;
public $value {
get { return $this->value * $this->scale; }
set;
}
function __construct($scale) { $this->scale = (double)$scale; }
}

--
Gustavo Lopes

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

Re: [PHP-DEV] [VOTE] Property Accessors for 5.5

[Sherif Ramadan]

On Sun, Jan 20, 2013 at 8:45 AM, Gustavo Lopes wrote:

> On Sun, 20 Jan 2013 14:35:14 +0100, Sherif Ramadan <
> theanomaly...@gmail.com> wrote:
>
>> What I'm saying is this kind of behavior needs far more serious reasoning
>> than the very naive assesment you're making above.
>>
>> I mean that with all due respect. Just wondering if there is another take
>> on this from anyone else?
>>
>>
> I think the current behavior is most appropriate one for var_dump() (and
> array casts/get_object_vars()). It's the same behavior as if you had
> manually defined getXXX() methods or used __get().
>

It's actually not the same behavior at all. __get can only work on
inaccessible properties. So I would not see NULL there in the object and
then get a value in the instance property.


>
> If you start marking function calls, you get new problems like handling
> getters that throw exceptions or have side effects ("the code behaves
> differently when add a var_dump()?!").


I'm not suggesting the getters should be invoked from afar. I'm just
suggesting some additional means of informing the user of the existence of
that getter to distinguish it from the property in the output of var_dump.

So for example, in var_dump, you can get ["property":protected] => ... when
the property has a visibility outside of the current context. It might be
helpful to provide some similar behavior for accessors with null
initialized values, but have getters available to the caller?

Just a thought.


>
>
> --
> Gustavo Lopes
>

Re: [PHP-DEV] [VOTE] Property Accessors for 5.5

[Gustavo Lopes]

On Sun, 20 Jan 2013 14:35:14 +0100, Sherif Ramadan  
 wrote:

What I'm saying is this kind of behavior needs far more serious reasoning
than the very naive assesment you're making above.

I mean that with all due respect. Just wondering if there is another take
on this from anyone else?



I think the current behavior is most appropriate one for var_dump() (and  
array casts/get_object_vars()). It's the same behavior as if you had  
manually defined getXXX() methods or used __get().


If you start marking function calls, you get new problems like handling  
getters that throw exceptions or have side effects ("the code behaves  
differently when add a var_dump()?!").


--
Gustavo Lopes

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

Re: [PHP-DEV] [VOTE] Property Accessors for 5.5

[Sherif Ramadan]

On Sun, Jan 20, 2013 at 8:08 AM, Nikita Popov  wrote:

> On Sun, Jan 20, 2013 at 5:46 AM, Sherif Ramadan 
> wrote:
>
>> I'm not sure if this has already come up in past discussion or not. So
>> I apologize in advance if this is repetitive. The discussion for property
>> accessors has been so lengthy I couldn't find the time to keep up with it
>> all.
>>
>> However, I found some time to play around with the patch today and I
>> noticed something that might use improving. When you use var_dump() on the
>> object properties that have defined get accessors don't produce any useful
>> output with var_dump. Is this fixable?
>>
>
> The var_dump will output the state of the object, i.e. the values that are
> internally stored. It will not go through the get accessors, rather it will
> directly give you the value of the underlying property. If the underlying
> property is not used, then it will just give you NULL.
>

While I agree with your initial assessment of the accessor not having set
any value, and therefore the logic of var_dump only providing what is
stored in the object's instance properties, I disagree with your
interpretation of what var_dump should do here.

Here is my reasoning for this:

1) var_dump is documented to provide you with information about a variable
(there is no mention of its implementation being limited to what the
variable stores).

2) Even if you interpret this to mean that var_dump will output the state
of the object then you are still wrong, since var_dump($foo->accessor) will
give me a value that the object does not store if the accessor returns a
computation rather than a stored value.

3) If this were a discussion of distinguishing between magic methods such
as __get/__set then we can simply say that only inaccessible properties can
invoke such methods and as such we have no confusion between what the
object stores and what var_dump returns when invoking those methods. With
accessors it is not the case at all.


Here's an example


class surface {
  public $area {
get { return $this->width * $this->height; }
private set;
  }
  public $width {
set($val) { $this->width = $val; }
private get;
  }
  public $height {
set ($val) { $this->height = $val; }
private get;
  }
}

$surface = new surface;
var_dump($surface);

this gives us the following output for $surface...

object(surface)#1 (3) {
  ["area"]=>
  NULL
  ["width"]=>
  NULL
  ["height"]=>
  NULL
}

This is to be completely expected since, technically, all we did here was
use class initialization that provided public properties initialized to
null.

However, let's say we set $surface->width and $surface->height...

$surface->width = 4;
$surface->height = 2;
var_dump($surface);

Now $surface shows us the following from var_dump

object(surface)#1 (3) {
  ["area"]=>
  NULL
  ["width"]=>
  int(4)
  ["height"]=>
  int(2)
}


This is not accurate since var_dump($surface->area) will give us the
following...

int(8)

It's not obvious what's happening here if I'm debugging this code in real
life, because on one hand I can see that my instance property returns a
value (which I expect). On the other hand I see my object has a null
property, which I don't expect. If this were magic the property would
simply not exist and i would know to look for __get / __set magic. Now, if
we argue that accessors are magic then why do they also not work like
magic? This is a bit of a hybrid approach, and I understand the reasoning
for most of what's going on here. I'm not here to argue about
implementation details.

What I'm saying is this kind of behavior needs far more serious reasoning
than the very naive assesment you're making above.

I mean that with all due respect. Just wondering if there is another take
on this from anyone else?

Sherif,
He who asks too many questions


>
> Nikita
>
>

Re: [PHP-DEV] [VOTE] Property Accessors for 5.5

[Nikita Popov]

On Sun, Jan 20, 2013 at 5:46 AM, Sherif Ramadan wrote:

> I'm not sure if this has already come up in past discussion or not. So
> I apologize in advance if this is repetitive. The discussion for property
> accessors has been so lengthy I couldn't find the time to keep up with it
> all.
>
> However, I found some time to play around with the patch today and I
> noticed something that might use improving. When you use var_dump() on the
> object properties that have defined get accessors don't produce any useful
> output with var_dump. Is this fixable?
>

The var_dump will output the state of the object, i.e. the values that are
internally stored. It will not go through the get accessors, rather it will
directly give you the value of the underlying property. If the underlying
property is not used, then it will just give you NULL.

Nikita