Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.2
"Nikita Popov" wrote in message
news:caf+90c91spfohitjgpwtevzt_wyk+htx4-tantmsshhctqq...@mail.gmail.com...
On Sat, Nov 19, 2016 at 11:18 AM, Tony Marston
wrote:
"Nikita Popov" wrote in message news:CAF+90c8Wox0wadAVPsP83er=
g9jbw__26ybwofasjb09ryv...@mail.gmail.com...
Hi internals!
I've submitted this RFC for PHP 7.1 previously, but didn't follow
through
due to time constraints. Now I'd like to propose an extended version for
PHP 7.2 and vote on it sooner rather than later to avoid a repeat
performance.
https://wiki.php.net/rfc/deprecations_php_7_2
The RFC combines a number of deprecation and removal proposals. Each one
will get a separate 2/3 majority vote. The RFC overlaps with some
recently
discussed topics (each, binary strings) -- I'm fine with dropping these
if
someone has a more specific RFC.
I expect some of these are no-brainers, while others are more
controversial
-- please share your specific concerns.
Thanks,
Nikita
I am against the removal of the $errorcontext argument of error handler
as
this has been a valuable part of my error handler for over ten years.
Whenever trigger_error() is called with a fatal error I write all
available
details to a log file as well as sending an email. In order to obtain
additional data I use errorcontext to determine the following:
a) Was it called from a function or an object? For this I use code such
as
the following:
if (isset($errcontext['this']) AND is_object($errcontext['this'])) {
b) If it was called from an object, was it one of my database objects? If
yes, then obtain some extra information using code such as the following:
// retrieve error details from DML object
if (method_exists($errcontext['this'], 'getQuery')) {
$query = $errcontext['this']->getQuery();
} // if
if (method_exists($errcontext['this'], 'getErrorNo')) {
$errno = $errcontext['this']->getErrorNo();
} // if
if (method_exists($errcontext['this'], 'getErrorString')) {
$errstr = $errcontext['this']->getErrorString();
} // if
if (method_exists($errcontext['this'], 'getErrorString2')) {
$errstr2 = $errcontext['this']->getErrorString2();
} // if
I'm afraid you're out of luck here :/ This usage will no longer be possible
as of PHP 7.1 -- independently of the deprecation proposed in this RFC.
See: https://3v4l.org/sQBL9
Prior to PHP 7.1 $this was *sometimes* included in the symbol table (to be
more precise, whenever $this was used as a CV, rather than implicit UNUSED
operand). As of PHP 7.1 $this is never included in the symbol table. This
change is due to https://wiki.php.net/rfc/this_var.
But! This functionality is still available through debug_backtrace().
That's the correct way of fetching the $this of a parent frame, which
should always work (rather than *sometimes* on PHP < 7.1), and is
independent of the error handling mechanism.
The RFC does not specify this, it simply says "use a proper debugger". Will
I still be able to use debug_backtrace() to obtain the same information that
is available in $errorcontext?If so, this should be explicitly stated in the
RFC.
So, to clarify: Is $this the only thing from the error context you're
interested in? Or do you also use all the other variables?
I use all the other variables as well, but sometimes I need to use
$errorcontext to supply additional information
--
Tony Marston
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV][RFC][DISCUSSION] - Immutable classes and properties
Hi, Discussion is open for following rfc https://wiki.php.net/rfc/immutability Cheers
Re: [PHP-DEV][RFC][DISCUSSION] - Immutable classes and properties
On 12/11/2016 10:57 AM, Silvio Marijić wrote:
Hi,
Discussion is open for following rfc https://wiki.php.net/rfc/immutability
Cheers
Some grammar issues:
"After object is constructor" => should be "After the object's
constructor has run".
" If immutable property contains object, to preserve immutability,
object that is beeing assigned to immutable property must also
immutable." => "If an immutable property contains an object, then in
order to preserve immutability the object being assigned must be of an
immutable class."
The File class/resource example should note that the last line in it
will create a fatal error, as the earlier examples do. It's not clear
that the example is an invalid one.
In a few places, "If immutable property..." should be "If an immutable
property..." There's several places where articles (the, an, etc.) are
missing.
"Notice in above examples removing getters and setting properties to
public is optional. They simply doesn't need to be protected anymore in
fact that immutable class objects are deeply frozen with eceptions on
write." => "Notice in the above examples that removing getters and
setting properties to public are optional. They simply don't need to be
protected given the fact that immutable class objects are frozen on
write." (Several grammar fixes, plus it's a fatal error, not an exception.)
Content issues:
Currently the only "unlocked context" for an object is its constructor.
As discussed previously, that is insufficient. For any non-trivial
object (more than 1-3 internal properties) creating a new one via the
constructor only when incrementally building is prohibitively
difficult. The pattern of with*() methods that spawn new objects via
clone(), a la PSR-7, needs to be supported. That is:
immutable class Money {
// ...
public function add(Money $other) : Money {
$new = clone($this);
$new->amount += $other->amount;
return $new;
}
}
I'm not sure how easily we can denote that sort of case. It's outside
the __clone() function itself, which is what makes it difficult.
Without that, though, such immutable objects are of only limited use.
--Larry Garfield
Re: [PHP-DEV][RFC][DISCUSSION] - Immutable classes and properties
2016-12-11 12:57 GMT-04:00 Silvio Marijić : > Hi, > > Discussion is open for following rfc https://wiki.php.net/rfc/immutability > > Cheers > Hi, Can you make a pull request? I'd like to comment the patch but it's not possible to make inline reviews only with a diff uri on github.
Re: [PHP-DEV][RFC][DISCUSSION] - Immutable classes and properties
@Larry, first of all thanks for pointing out grammar issues, I will correct
them. Now, regarding cloning of the immutable object, I'm aware of that
issue and I'm not sure if we could even use clone operation for this
purpose, I do have one proposal for that matter, consider example:
immutable class User {
public $firstname;
public $lastname;
public $email;
public function __construct($firstname, $lastname, $email){
//
}
}
$user = new User('Foo', 'Bar', 'f...@bar.com');
$new = copy($user, ['firstname' => 'John', 'email' => 'j...@bar.com'])
Copy function would take as a first argument an immutable object and as a
second argument associative array where keys represent property names and
values specified will be assigned to those properties on a new object.
@Marcio I will submit PR, have you found bug or?
Cheers
2016-12-11 23:35 GMT+01:00 Marcio Almada :
>
> 2016-12-11 12:57 GMT-04:00 Silvio Marijić :
>
>> Hi,
>>
>> Discussion is open for following rfc https://wiki.php.net/rfc/immut
>> ability
>>
>> Cheers
>>
>
>
> Hi,
>
> Can you make a pull request? I'd like to comment the patch but it's not
> possible to make inline reviews only with a diff uri on github.
>
>
--
Silvio Marijić
Software Engineer
2e Systems
Re: [PHP-DEV][RFC][DISCUSSION] - Immutable classes and properties
Assuming this was intended for the list...
On 12/11/2016 05:55 PM, Mathieu Rochette wrote:
Currently the only "unlocked context" for an object is its
constructor. As discussed previously, that is insufficient. For any
non-trivial object (more than 1-3 internal properties) creating a new
one via the constructor only when incrementally building is
prohibitively difficult. The pattern of with*() methods that spawn
new objects via clone(), a la PSR-7, needs to be supported. That is:
immutable class Money {
// ...
public function add(Money $other) : Money {
$new = clone($this);
$new->amount += $other->amount;
return $new;
}
}
I'm not sure how easily we can denote that sort of case. It's outside
the __clone() function itself, which is what makes it difficult.
Without that, though, such immutable objects are of only limited use.
As you said, it has been already been discussed that a method to build
new altered object from an existing one could be improved. Different
options were proposed but maybe it's better to start small to get this
first part right and add this in another rfc ? having everything at the
same time might makes the rfc more difficult to be accepted
On the contrary, an RFC that doesn't fully solve the issue at hand and
leaves major gaps in place is a poor RFC, and I would expect to be
justifiably voted down.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][RFC][DISCUSSION] - Immutable classes and properties
This have occurred to me also, I wanted to separate that into two RFC's,
but then how we deal with RFC's that depend on each other?
2016-12-12 1:03 GMT+01:00 Larry Garfield :
> Assuming this was intended for the list...
>
> On 12/11/2016 05:55 PM, Mathieu Rochette wrote:
>
>> Currently the only "unlocked context" for an object is its
>> constructor. As discussed previously, that is insufficient. For any
>> non-trivial object (more than 1-3 internal properties) creating a new
>> one via the constructor only when incrementally building is
>> prohibitively difficult. The pattern of with*() methods that spawn
>> new objects via clone(), a la PSR-7, needs to be supported. That is:
>>
>> immutable class Money {
>>// ...
>>
>>public function add(Money $other) : Money {
>> $new = clone($this);
>> $new->amount += $other->amount;
>> return $new;
>>}
>> }
>>
>> I'm not sure how easily we can denote that sort of case. It's outside
>> the __clone() function itself, which is what makes it difficult.
>> Without that, though, such immutable objects are of only limited use.
>>
>
>
>
>> As you said, it has been already been discussed that a method to build
>> new altered object from an existing one could be improved. Different
>> options were proposed but maybe it's better to start small to get this
>> first part right and add this in another rfc ? having everything at the
>> same time might makes the rfc more difficult to be accepted
>>
>
> On the contrary, an RFC that doesn't fully solve the issue at hand and
> leaves major gaps in place is a poor RFC, and I would expect to be
> justifiably voted down.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Silvio Marijić
Software Engineer
2e Systems
Re: [PHP-DEV][RFC][DISCUSSION] - Immutable classes and properties
On 12/12/2016 01:16 AM, Silvio Marijić wrote:
> This have occurred to me also, I wanted to separate that into two RFC's,
> but then how we deal with RFC's that depend on each other?
well that's just my opinion but I don't think they depend on each other,
this rfc seems useful on its own. The "clone" one might depends on this
one but it does not *need* to either (otoh it certainly would be much
more useful with immutable classes than mutable classes)
plus, this part might already trigger enough discussion and adding
everything at once might get confusion. I can think of : clone, late
initialization, DateTimeImmutable and probably other subjects that could
make the discussion noisy
I'm not as familiar as you are with this mailing list so I might very
well be wrong too ^^
>
> 2016-12-12 1:03 GMT+01:00 Larry Garfield :
>
>> Assuming this was intended for the list...
it was, thank you
>>
>> On 12/11/2016 05:55 PM, Mathieu Rochette wrote:
>>
>>> Currently the only "unlocked context" for an object is its
>>> constructor. As discussed previously, that is insufficient. For any
>>> non-trivial object (more than 1-3 internal properties) creating a new
>>> one via the constructor only when incrementally building is
>>> prohibitively difficult. The pattern of with*() methods that spawn
>>> new objects via clone(), a la PSR-7, needs to be supported. That is:
>>>
>>> immutable class Money {
>>>// ...
>>>
>>>public function add(Money $other) : Money {
>>> $new = clone($this);
>>> $new->amount += $other->amount;
>>> return $new;
>>>}
>>> }
>>>
>>> I'm not sure how easily we can denote that sort of case. It's outside
>>> the __clone() function itself, which is what makes it difficult.
>>> Without that, though, such immutable objects are of only limited use.
>>>
>>
>>
>>> As you said, it has been already been discussed that a method to build
>>> new altered object from an existing one could be improved. Different
>>> options were proposed but maybe it's better to start small to get this
>>> first part right and add this in another rfc ? having everything at the
>>> same time might makes the rfc more difficult to be accepted
>>>
>> On the contrary, an RFC that doesn't fully solve the issue at hand and
>> leaves major gaps in place is a poor RFC, and I would expect to be
>> justifiably voted down.
>>
>> --Larry Garfield
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
--
Mathieu Rochette
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PECL-DEV] Intention to move mcrypt to PECL
On Wed, Oct 19, 2016 at 7:44 PM, Leigh wrote: > > On Wed, 5 Oct 2016 at 20:11 Derick Rethans wrote: > >> It should be migrated properly, and also to GIT. >> > > Hi Ferenc, > > Can you create a php.net hosted git repository for this (I guess under > the pecl/security namespace), and grant karma to le...@php.net for it. > > Sorry for picking on you personally. I don't know who else can do this :) > > Cheers, > > Leigh. > > > Hi, I've just created the http://git.php.net/?p=pecl/encryption/mcrypt.git repository (I think encryption was a better category as we already have scrypt, libsodium and mcrypt_filter there). Leigh already had karma for pecl/*, let me know if you need help with creating the package or importing the source to the repo ( https://help.github.com/articles/splitting-a-subfolder-out-into-a-new-repository/ if you want to keep the history). -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV][RFC][DISCUSSION] - Immutable classes and properties
On Sun, Dec 11, 2016 at 7:40 PM, Mathieu Rochette
wrote:
>
>
> On 12/12/2016 01:16 AM, Silvio Marijić wrote:
> > This have occurred to me also, I wanted to separate that into two RFC's,
> > but then how we deal with RFC's that depend on each other?
> well that's just my opinion but I don't think they depend on each other,
> this rfc seems useful on its own. The "clone" one might depends on this
> one but it does not *need* to either (otoh it certainly would be much
> more useful with immutable classes than mutable classes)
>
> plus, this part might already trigger enough discussion and adding
> everything at once might get confusion. I can think of : clone, late
> initialization, DateTimeImmutable and probably other subjects that could
> make the discussion noisy
>
> I'm not as familiar as you are with this mailing list so I might very
> well be wrong too ^^
> >
> > 2016-12-12 1:03 GMT+01:00 Larry Garfield :
> >
> >> Assuming this was intended for the list...
> it was, thank you
> >>
> >> On 12/11/2016 05:55 PM, Mathieu Rochette wrote:
> >>
> >>> Currently the only "unlocked context" for an object is its
> >>> constructor. As discussed previously, that is insufficient. For any
> >>> non-trivial object (more than 1-3 internal properties) creating a new
> >>> one via the constructor only when incrementally building is
> >>> prohibitively difficult. The pattern of with*() methods that spawn
> >>> new objects via clone(), a la PSR-7, needs to be supported. That is:
> >>>
> >>> immutable class Money {
> >>>// ...
> >>>
> >>>public function add(Money $other) : Money {
> >>> $new = clone($this);
> >>> $new->amount += $other->amount;
> >>> return $new;
> >>>}
> >>> }
> >>>
> >>> I'm not sure how easily we can denote that sort of case. It's outside
> >>> the __clone() function itself, which is what makes it difficult.
> >>> Without that, though, such immutable objects are of only limited use.
> >>>
> >>
> >>
> >>> As you said, it has been already been discussed that a method to build
> >>> new altered object from an existing one could be improved. Different
> >>> options were proposed but maybe it's better to start small to get this
> >>> first part right and add this in another rfc ? having everything at the
> >>> same time might makes the rfc more difficult to be accepted
> >>>
> >> On the contrary, an RFC that doesn't fully solve the issue at hand and
> >> leaves major gaps in place is a poor RFC, and I would expect to be
> >> justifiably voted down.
>
I wonder if we can essentially make all public methods act like they are
static (no access to $this) and then use something like:
immutable class Foo {
protected $bar;
public function getBar() with (Foo $instance): string // $instance is
a clone of $this
{
// context == $instance, so access to private/protected
return $instance->bar;
}
public function withBar($bar) with (Foo $instance): Foo
{
$instance->bar = $bar; // Allowed as we're in scope
return $instance;
}
}
Only operations in the scope of the class itself (and it's descendants,
adhering to standard visibility rules) can make changes on the cloned
variant. The `with ($instance)` is optional, $instance is just a variable
name. In reality you'll want to use it most of the time I imagine.
I suppose you can re-use the `use` keyword here too.
Also, this shouldn't allow for immutable properties.
Another option is to look at the way that HHVM does immutable types, though
that is _file_ based.
- Davey
