Re: [PHP-DEV] [RFC] [PROPOSAL] Immutable/final/readonly properties

[Rowan Tommins]

On 14/02/2020 13:42, Máté Kocsis wrote:

Maybe only if our long-term goal would be to deprecate/remove
non-typed properties and implicit initialization altogether in favour of
mixed type and implicit uninitialization...



Can I just leave an "ugh, please no" on this part. I remain of the 
opinion that the introduction of the "uninitialised" state was a huge 
mistake, and we should be actively working towards making it 
unnecessary, not building more features that rely on it.



Immutable properties, and eventually immutable objects, however, are 
something I'd be very interested to see.



Regards,

--
Rowan Tommins (né Collins)
[IMSoP]

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

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

[Paul M. Jones]

Hi all,

> On Feb 14, 2020, at 10:47, Benjamin Morel  wrote:
> 
>> 
>> What about $query and $body? That would be closer to the terminology
>> used in HTTP RFCs.
> 
> 
> The problem is that $body is typically used to get the raw message body as
> a string or stream.
> 
> I was thinking more something along the lines of $bodyParams, which is more
> verbose but leaves no ambiguity: *$queryParams* and *$bodyParams*.

I get the desire to disambiguate. But as an added consideration, there's a 
desire for consistency; when adding a -Params suffix to those names, it might 
then make sense to have $serverParams, $cookieParams, etc.

Looking at it that way, I don't think a -Params suffix is necessary. I would 
think $query would be enough.

As for the other name, the one for the $_POST equivalent, $body doesn't seem 
quite right to me; it seems a little close to $content.  I've also been 
thinking about $values, $params, $parsedContent, $contentValues, $bodyValues, 
$contentArray, and other variations with and without prefixes and suffixes, but 
$input is the one that feels like the least-terrible alternative to $post for 
me, esp. given the connection to php://input.


-- 
Paul M. Jones
pmjo...@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

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

Re: [PHP-DEV] [RFC] token_get_all() TOKEN_AS_OBJECT mode

[Rowan Tommins]

On Fri, 14 Feb 2020 at 16:33, Nikita Popov  wrote:

> This constructor will initialize the corresponding properties. Now, the
> behavior that would make most sense to me (if extension of the class is
> allowed) is that MyPhpToken::getAll() is going to create the new tokens
> based on "new MyPhpToken($id, $text, $line, $pos)". If we mark the
> constructor final, then we could hardcode the construction behavior of the
> base class without introducing any kind of weird rules, it would be just
> the usual language semantics.
>


It's worth noting that this is how ext/simplexml works: the $class
parameter of simplexml_load_string and simplexml_load_file must be the name
of a class that inherits from SimpleXMLElement, and an instance of that
class will be constructed for each element of the document. The constructor
of SimpleXMLElement is final, so the internal initialisation logic doesn't
have to actually call it, it can just initialise the private state directly.

Regards,
-- 
Rowan Tommins
[IMSoP]

[PHP-DEV] Re: [RFC] Allow calls to global functions in constant expressions

[tyson andre]

> - Solving the above two issues while continuing to throw for func_get_args(), 
> get_defined_vars(), etc.
>   get_defined_vars() would throw for dynamic calls

Then again, it's already possible to get function parameters through 
debug_backtrace(), so implicitly creating a closure and call with 0 bind vars 
wrapping the function calls might be an acceptable tradeoff.

- Possibly leave that closure out for calls known to not be dynamic internal 
calls
- It might make sense to blacklist known function names such as 
func_get_args(), get_defined_vars(), etc to prevent writing that type of buggy 
code, e.g. in parameter default expressions 

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

[PHP-DEV] Problems with mysqli code and documentation

[j adams]

I had considerable difficulty getting mysqli_connect to use SSL/TSL to
connect to a db and I think some things need to be improved. I apologize
for also describing documentation issues here, but I'll describe the coding
issues first. I may need some help to prompt the documentation team to
remedy some issues. It is my feeling that PHP's credibility as a viable
modern language depends in large part on reliable and well-documented
encryption functionality to satisfy security best practices for vital
database connectivity. PHP's documentation has been one of its great assets
over the years and I hope to see that great tradition continued robustly.

CONTEXT
An email from Amazon informed me they are upgrading the certificates for
their Relational Database Servers (RDS). This prompted me to try and
connect from PHP to an RDS MySQL server using SSL/TSL. The experience was
difficult and unhappy. It's tricky mostly because the documentation on
mysqli features relating to SSL/TLS is poor, but also because the
underlying PHP code doesn't make use of a variable (or more?) in the
underlying source code.

CODING/DEV ISSUES
1) As pointed out here
,
the constant MYSQLI_OPT_SSL_VERIFY_SERVER_CERT is defined in PHP

but apparently doesn't do anything at all. A decision needs to be made
about whether to remove this constant or to somehow reconcile its relation
to the constant MYSQLI_CLIENT_SSL_DONT_VERIFY_SERVER_CERT. The former
constant is supplied to the function mysqli_options and does absolutely
nothing, the latter is a flag to the function mysqli_real_connect and does
appear to prevent validation of the server's SSL/TLS certificate during
handshaking. There may be other orphaned variables that are not used, I
don't know.

2) If one specifies "localhost" as the host when trying to mysqli_connect
using SSL/TLS, then the connection will fail with these warnings:
PHP Warning:  mysqli_real_connect(): this stream does not support
SSL/crypto in /path/to/file.php on line XX
PHP Warning:  mysqli_real_connect(): Cannot connect to MySQL by using SSL
in /path/to/file.php on line XX
PHP Warning:  mysqli_real_connect(): [2002]  (trying to connect via (null))
in /path/to/file.php on line XX
PHP Warning:  mysqli_real_connect(): (HY000/2002):  in /path/to/file.php on
line XX

That's four warnings and a highly cryptic problem which is not easily
diagnosed because there is no documentation or user comments to clarify the
issue. Using 127.0.0.1 instead of localhost seems to remedy the problem for
some reason surely related to transport, but it would certainly be
preferable if the PHP code was smart enough to recognize the situation
enough to provide a single, more meaningful warning.

DOCUMENTATION (AND POSSIBLY CODING) ISSUES
A) mysqli_ssl_set  has no
usage examples and the parameter descriptions border on useless. For
example:

key
The path name to the key file.
cert
The path name to the certificate file.
ca
The path name to the certificate authority file.

No mention is made of format. No effort is made to describe whether these
are client keys/certs or server keys/certs. Is this a private key or public
key? I admit my knowledge of the relation between certificates and the
certificate authority file is a little fuzzy, but I'm hardly a novice
programmer and feel this documentation leaves a lot to be desired. Most of
the coding examples I find using this function set only the ca, leaving the
majority of the numerous other parameters empty. The documentation does not
describe what happens when these values are NULL or what happens of the
specified file paths don't exist. It doesn't describe what string values
are permissible -- which is especially disconcerting for the cipher
parameter, which surely admits only certain constants? For some reason this
function always returns a TRUE value, and does not throw any exceptions
(e.g., if the files don't exist). What doe these parameters do? What does
this function do?

B) documentation for mysqli_real_connect
 does not
sufficiently describe how it differs from mysqli_connect. E.g., it doesn't
mention that mysqli_real_connect is helpful in lieu of mysqli_connect if
you must set options like connect timeouts, etc. It does not provide any
examples that use the flags parameter. Why do we have these two distinct
functions? Is there some way to use mysqli_ssl_set with mysqli_connect? Or
must one always use mysqli_real_connect?

In digging further into the MySQLi documentation, I see that there is a lot
of helpful detail on the Quick Start articles, and would suggest that the
level of detail in Quick Start should be the bare minimum, with

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

[Benjamin Morel]

>
> What about $query and $body? That would be closer to the terminology
> used in HTTP RFCs.



The problem is that $body is typically used to get the raw message body as
a string or stream.
I was thinking more something along the lines of $bodyParams, which is more
verbose but leaves no ambiguity: *$queryParams* and *$bodyParams*.

— Benjamin

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

[Bruce Weirdan]

On Fri, Feb 14, 2020 at 5:47 PM Paul M. Jones  wrote:
>

> - rename $get to $query, populating it from `$globals['_GET']`, on the basis 
> stated above
> - rename $post to $input, populating it from `$globals['_POST']`, on the 
> basis that it typically relates to the parsed form of php://input

What about $query and $body? That would be closer to the terminology
used in HTTP RFCs.

-- 
  Best regards,
  Bruce Weirdan mailto:weir...@gmail.com

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

Re: [PHP-DEV] [RFC] token_get_all() TOKEN_AS_OBJECT mode

[Nikita Popov]

On Fri, Feb 14, 2020 at 2:38 PM Sara Golemon  wrote:

> On Thu, Feb 13, 2020 at 3:48 AM Nikita Popov  wrote:
>
>> This has been discussed a while ago already, now as a proper proposal:
>> https://wiki.php.net/rfc/token_as_object
>>
>> tl;dr is that it allows you to get token_get_all() output as an array of
>> PhpToken objects. This reduces memory usage, improves performance, makes
>> code more uniform and readable... What's not to like?
>>
>> An open question is whether (at least to start with) PhpToken should be
>> just a data container, or whether we want to add some helper methods to
>> it.
>> If this generates too much bikeshed, I'll drop methods from the proposal.
>>
>> Yep. I remember bringing this up in 2016 and there was generally good
> reception to it from you, Andrea, Stas, and Stig at the very least.  Why
> isn't it in? It got derailed by some bike shed colorizing and a little bit
> of workplace drama then dropped on the floor.
>
> Thanks for picking it up, and I agree with your response to Larry.  As
> nice as it would be to lazy iterate, the scanner is just in NO shape to
> tolerate reentering userspace and potentially reinvoking the scanner before
> the first run through is done.
>
> I also agree that being able to subclass the token would be great, but
> that PDO made some mistakes here and we can do that as a separate addition
> later on if there's not consensus now.
>
> I'm +1 for NOT overloading the token_get_all() function, but rather
> putting a static factory method on the PhpToken class (or whatever you call
> it).  When we add subclassability, we can always add additional statics if
> our initial signature doesn't work out.
>

As there seems to be a pretty clear consensus on this point at least, I've
updated the proposal to add the static factory method.

I'm not clear why you want to final the base constructor.  IMO we populate
> the fields on object creation, then invoke constructor (which is a no-op in
> the base class).  Later uses of subclassing can deal with the properties
> (or not) at that time, in their own constructor, delegating (or not) to the
> base.
>

Populating the fields on creation and then calling the constructor is the
whole problem with PDO, because that's not how PHP usually does
construction. Normally there is either no constructor and properties are
explicitly populated, or there is a constructor, in which case only the
constructor is called. Populating properties first and the calling a
constructor is something that essentially only PDO does.

To clarify a bit what I meant with the final constructor: As part of the
last update, I've added the following constructor:

class PhpToken {
public function __construct(int $id, string $text, int $line = -1, int
$pos = -1);
}

This constructor will initialize the corresponding properties. Now, the
behavior that would make most sense to me (if extension of the class is
allowed) is that MyPhpToken::getAll() is going to create the new tokens
based on "new MyPhpToken($id, $text, $line, $pos)". If we mark the
constructor final, then we could hardcode the construction behavior of the
base class without introducing any kind of weird rules, it would be just
the usual language semantics.

If we don't make the constructor final, then we would have to actually call
it (if it is overridden -- otherwise we can use more optimized
initialization code). We can do that (I believe calling user code here
should be perfectly safe -- the lexer is reentrant after all), it's just
extra complexity and I'm not sure it's actually useful. The final
constructor would still allow a) adding methods in the child class and b)
adding properties with default values in the child class, which seems like
it should cover most of the usefulness.

So I think the options here are:
a) Make PhpToken final and simplify don't support this.
b) Make PhpToken::__construct() final and (very easily) support basic
extension.
c) Make PhpToken::__construct() non-final and support full extension, with
some extra effort.

Regards,
Nikita

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

[Benjamin Morel]

>
> Having said that, we are willing to revisit that naming decision if
> there's support for doing so. Perhaps:
> - rename $get to $query, populating it from `$globals['_GET']`, on the
> basis stated above
> - rename $post to $input, populating it from `$globals['_POST']`, on the
> basis that it typically relates to the parsed form of php://input
> Your (and/or anyone else's) thoughts on that?



Symfony uses $request->query and $request->request for $_GET and $_POST,
respectively.
I like $request->query for query params, but always found $request->request
for body parameters confusing. I like $request->input a bit better,
although I'd be interested to hear more ideas on this one.

— Benjamin


On Fri, 14 Feb 2020 at 16:47, Paul M. Jones  wrote:

> Hi Côme & Niklas,
>
> > On Feb 13, 2020, at 04:52, Côme Chilliet <
> come.chill...@fusiondirectory.org> wrote:
> >
> > Le mercredi 12 février 2020, 19:20:56 CET Niklas Keller a écrit :
> >
> >> Naming
> >>
> >> I think we shouldn't take over the naming of the super globals, e.g.
> >> $_GET really contains the query parameters and has nothing to do with
> >> GET or POST, so $request->getQueryParameter(...) would be a better
> >> name.
> >
> > I think this remark is really on point.
> > GET and POST are HTTP methods and not ways of passing data. You can have
> query parameters on any request, and you can have POST data with a lot of
> other HTTP methods, as is commonly used in REST APIs.
>
> Your comments on naming are well-made.
>
> While working on the implementation, we tried out $query instead of $get,
> on exactly the premise that you state: i.e., that `$_GET` holds the query
> parameters, and has nothing to do with the GET method. But in the end, we
> settled on mapping more directly from `$_GET` => `$get`, and `$_POST =>
> $post`.
>
> Having said that, we are willing to revisit that naming decision if
> there's support for doing so. Perhaps:
>
> - rename $get to $query, populating it from `$globals['_GET']`, on the
> basis stated above
> - rename $post to $input, populating it from `$globals['_POST']`, on the
> basis that it typically relates to the parsed form of php://input
>
> Your (and/or anyone else's) thoughts on that?
>
>
> --
> Paul M. Jones
> pmjo...@pmjones.io
> http://paul-m-jones.com
>
> Modernizing Legacy Applications in PHP
> https://leanpub.com/mlaphp
>
> Solving the N+1 Problem in PHP
> https://leanpub.com/sn1php
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

[Paul M. Jones]

Hi Côme & Niklas,

> On Feb 13, 2020, at 04:52, Côme Chilliet  
> wrote:
> 
> Le mercredi 12 février 2020, 19:20:56 CET Niklas Keller a écrit :
> 
>> Naming
>> 
>> I think we shouldn't take over the naming of the super globals, e.g.
>> $_GET really contains the query parameters and has nothing to do with
>> GET or POST, so $request->getQueryParameter(...) would be a better
>> name.
> 
> I think this remark is really on point.
> GET and POST are HTTP methods and not ways of passing data. You can have 
> query parameters on any request, and you can have POST data with a lot of 
> other HTTP methods, as is commonly used in REST APIs.

Your comments on naming are well-made.

While working on the implementation, we tried out $query instead of $get, on 
exactly the premise that you state: i.e., that `$_GET` holds the query 
parameters, and has nothing to do with the GET method. But in the end, we 
settled on mapping more directly from `$_GET` => `$get`, and `$_POST => $post`.

Having said that, we are willing to revisit that naming decision if there's 
support for doing so. Perhaps:

- rename $get to $query, populating it from `$globals['_GET']`, on the basis 
stated above
- rename $post to $input, populating it from `$globals['_POST']`, on the basis 
that it typically relates to the parsed form of php://input

Your (and/or anyone else's) thoughts on that?


-- 
Paul M. Jones
pmjo...@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

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

[PHP-DEV] Re: [RFC] Allow calls to global functions in constant expressions

[tyson andre]

Hi internals,

https://wiki.php.net/rfc/calls_in_constant_expressions has hit some roadblocks 
in the implementation shortly after the last email.
I've been blocked on how to resolve them in the implementation in a way I'm 
certain would work.
I had assumed the calling scope wouldn't have the below issues when I started 
working on this RFC, but was mistaken.

 - The helper method the C code uses, `zend_call_function()`, will always act 
as though `strict_types=0`. I'd consider this a blocker for 
`declare(strict_types=1); const X = intdiv("123", 2);`. (Internally, 
zend_call_function adds a fake call frame without a function, similar to what 
__get, invocations of error handlers, etc do, and that call frame makes the 
parameter parsing helper macros of the invoked function treat it like 
strict_types=0)

It may also be desirable to specify calls in constants always work like 
strict_types=1, to avoid issues such as `strpos($float, '.')` being 
locale-dependent)
 - Getting the class scope *of the constant declaration* to work properly with 
`callable` (e.g. `public $x = array_map('self::helperMethod', VALUES);`).
This isn't an issue with only a whitelist.
 - Solving the above two issues while continuing to throw for func_get_args(), 
get_defined_vars(), etc.
   get_defined_vars() would throw for dynamic calls, but the above approaches 
would act like 

Currently, my best ideas to fix some of the 3 issues were:
 - Create a fake zend_function placeholder in C with a placeholder name and add 
it to the internal stack of calls (EG(current_execute_data)).
   Currently, though, it's only possible to set strict_types=1 for user-defined 
functions.
 - Create an actual closure when compiling the code, which would be evaluated 
the same way as `public $x = (static function() { return 
array_map('self::helperMethod', VALUES); })()`
(i.e. a closure without any `use` variables. The )

This would solve it, but the performance would be unexpectedly worse than 
expected, and that would interfere with optimizations.
 - Create an alternative to zend_call_function, but that would duplicate code 
and be error prone.
   I'm not familiar enough with XDebug, NewRelic, uopz, and other replacements 
of zend_vm_execute to know if those would be able to support that,
   or if there would be even more issues I haven't thought up yet that would 
prevent .

Second, I realize it doesn't make much sense to restrain the constant 
expressions for parameter defaults and class constants in the same way.
The RFC was coherent proposing allowing any function call in 5 places, but less 
coherent proposing a whitelist of functions, even where those restrictions 
weren't necessary.

- It may be desirable to support many extra expression types in parameter 
defaults and static property defaults
  (`function myFunc(object $x = new DefaultObject()) {}`)
  but still limit class constants to the proposed whitelist of functions.

Third, I was considering a straw poll for this,
but don't know what's required to set one up.
It also didn't make sense to me without a solution to the roadblocks.

1. Desired expressions in param defaults (No change/Whitelisted functions/Any 
function/Any method + new X()+others)
2. ... in static property defaults
3. ... in static variable defaults
4. ... in class constant values
5. ... in const X = ...

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

Re: [PHP-DEV] [RFC] token_get_all() TOKEN_AS_OBJECT mode

[Nikita Popov]

On Fri, Feb 14, 2020 at 2:44 PM Marco Pivetta  wrote:

> On Fri, Feb 14, 2020 at 2:38 PM Sara Golemon  wrote:
>
>> Thanks for picking it up, and I agree with your response to Larry.  As
>> nice
>> as it would be to lazy iterate, the scanner is just in NO shape to
>> tolerate
>> reentering userspace and potentially reinvoking the scanner before the
>> first run through is done.
>>
>
> If this is the current state, maybe it would suffice to declare the return
> type as `iterable`, and return a strict (fully populated) structure in a
> first implementation, later to be changed to an iterator, if applicable?
>
> Marco Pivetta
>

The fact that it returns an array is an important part of the contract. If
an iterator variant is added in the future, it should be added as a
separate method.

I don't want to be writing

$tokens = PhpToken::getAll($code);
if (!is_array($tokens)) {
$tokens = iterator_to_array($tokens);
}

to convert this to the right type. And I also don't want my usage to be
implicitly "upgraded" to an iterator in the future: The iterator will
always be less efficient, and I don't want to be forced to use it if I need
an array anyway.

Nikita

Re: [PHP-DEV] [RFC] token_get_all() TOKEN_AS_OBJECT mode

[Sara Golemon]

On Fri, Feb 14, 2020 at 7:44 AM Marco Pivetta  wrote:

> On Fri, Feb 14, 2020 at 2:38 PM Sara Golemon  wrote:
>
>> Thanks for picking it up, and I agree with your response to Larry.  As
>> nice
>> as it would be to lazy iterate, the scanner is just in NO shape to
>> tolerate
>> reentering userspace and potentially reinvoking the scanner before the
>> first run through is done.
>>
>
> If this is the current state, maybe it would suffice to declare the return
> type as `iterable`, and return a strict (fully populated) structure in a
> first implementation, later to be changed to an iterator, if applicable?
>
> I think that's an optimistic, but ultimately harmless approach.  Arrays
satisfy Iterables.  Worst case we never improve on that. Best case we get
iterable token generators.
+1

-Sara

Re: [PHP-DEV] Proposal for a new basic function: str_contains

[Philipp Tanlak]

Am Fr., 14. Feb. 2020 um 12:54 Uhr schrieb Nikita Popov <
nikita@gmail.com>:

> On Fri, Feb 14, 2020 at 10:18 AM Philipp Tanlak 
> wrote:
>
>> Hello PHP Devs,
>>
>> I would like to propose the new basic function: str_contains.
>>
>> The goal of this proposal is to standardize on a function, to check
>> weather
>> or not a string is contained in another string, which has a very common
>> use-case in almost every PHP project.
>> PHP Frameworks like Laravel create helper functions for this behavior
>> because it is so ubiquitous.
>>
>> There are currently a couple of approaches to create such a behavior, most
>> commonly:
>> > strpos($haystack, $needle) !== false;
>> strstr($haystack, $needle) !== false;
>> preg_match('/' . $needle . '/', $haystack) != 0;
>>
>> All of these functions serve the same purpose but are either not
>> intuitive,
>> easy to get wrong (especially with the !== comparison) or hard to remember
>> for new PHP developers.
>>
>> The proposed signature for this function follows the conventions of other
>> signatures of string functions and should look like this:
>>
>> str_contains(string $haystack, string $needle): bool
>>
>> This function is very easy to implement, has no side effects or backward
>> compatibility issues.
>> I've implemented this feature and created a pull request on GitHub ( Link:
>> https://github.com/php/php-src/pull/5179 ).
>>
>> To get this function into the PHP core, I will open up an RFC for this.
>> But first, I would like to get your opinions and consensus on this
>> proposal.
>>
>> What are your opinions on this proposal?
>>
>
> Sounds good to me. This operation is needed often enough that it deserves
> a dedicated function.
>
> I'd recommend leaving the proposal at only str_contains(), in particular:
>
>  * Do not propose a case-insensitive variant. I believe this is really the
> point on which the last str_starts_with/str_ends_with proposal failed.
>
>  * Do not propose mb_str_contains(). Especially as no offsets are
> involved, there is no reason to have this function. (For UTF-8, the
> behavior would be exactly equivalent to str_contains.)
>
> Regards,
> Nikita
>

I like to elaborate on Nikitas response: I don't think a mb_str_contains is
necessary, because the proposed function does not behave differently, if
the input strings are multibyte strings.
When searched for a multibyte string in another multibyte string, the
return value would consistently be true/false. The position/offset at which
the multibyte string was found is not relevant.
The reason for the existence of a strpos/mb_strpos is the fact, that the
returned position/offset varies depending on weather or not the string is a
multibyte string or not.

The only possible valid variants concerning multibyte and incasesensitivity
I see are:
* str_contains: works as expected with multibyte and non multibyte strings.
* mb_str_icontains: is the only valid option to do a incasesensitive search
for multibyte strings.

Unneeded variants I see are:
* mb_str_contains: does not behave differently when compared to
str_contains, as mentioned above.
* str_icontains: is a possible option but could be error prone for when
used with multibyte strings like UTF-8, as it is de facto the standard
nowadays.

I'm certain there would be confusion among php developers when the newly
proposed functions are only str_contains and mb_str_icontains.

Patrick ALLAERT:
Yes, it does have one: people having already defined a str_contains()
function in the global scope will have a PHP Fatal error:  Cannot redeclare
str_contains()

You are absolutely correct with this. Although functions added by
frameworks to the global scope are usually guarded by: if
(!function_exists('str_contains')) {}

Re: [PHP-DEV] [RFC] token_get_all() TOKEN_AS_OBJECT mode

[Marco Pivetta]

On Fri, Feb 14, 2020 at 2:38 PM Sara Golemon  wrote:

> Thanks for picking it up, and I agree with your response to Larry.  As nice
> as it would be to lazy iterate, the scanner is just in NO shape to tolerate
> reentering userspace and potentially reinvoking the scanner before the
> first run through is done.
>

If this is the current state, maybe it would suffice to declare the return
type as `iterable`, and return a strict (fully populated) structure in a
first implementation, later to be changed to an iterator, if applicable?

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] [RFC] [PROPOSAL] Immutable/final/readonly properties

[Máté Kocsis]

>
> If somebody really wants a `mixed` property to be immutable, they could
> write `private immutable null|bool|int|float|string|array|object
> $property;`.
>

Yeah, one of my ideas was to first add support for mixed (for which there
have been a proposal/PR since quite some time), so that all non-typed
properties
could be implicitly upgraded to the mixed type. But I don't think it's the
way to go... Maybe only if our long-term goal would be to deprecate/remove
non-typed properties and implicit initialization altogether in favour of
mixed type and implicit uninitialization...


> That would make implementation straightforward, since you'd expect
> `immutable` to be before a type declaration (can be done in the parser,
> right?).
>

Yeah, the implementation didn't seem very tricky yet (but people with more
experience with the internals of PHP should tell). However, Nikita also
warned me
not to support references. So this is another question to decide...

Re: [PHP-DEV] [RFC] token_get_all() TOKEN_AS_OBJECT mode

[Sara Golemon]

On Thu, Feb 13, 2020 at 3:48 AM Nikita Popov  wrote:

> This has been discussed a while ago already, now as a proper proposal:
> https://wiki.php.net/rfc/token_as_object
>
> tl;dr is that it allows you to get token_get_all() output as an array of
> PhpToken objects. This reduces memory usage, improves performance, makes
> code more uniform and readable... What's not to like?
>
> An open question is whether (at least to start with) PhpToken should be
> just a data container, or whether we want to add some helper methods to it.
> If this generates too much bikeshed, I'll drop methods from the proposal.
>
> Yep. I remember bringing this up in 2016 and there was generally good
reception to it from you, Andrea, Stas, and Stig at the very least.  Why
isn't it in? It got derailed by some bike shed colorizing and a little bit
of workplace drama then dropped on the floor.

Thanks for picking it up, and I agree with your response to Larry.  As nice
as it would be to lazy iterate, the scanner is just in NO shape to tolerate
reentering userspace and potentially reinvoking the scanner before the
first run through is done.

I also agree that being able to subclass the token would be great, but that
PDO made some mistakes here and we can do that as a separate addition later
on if there's not consensus now.

I'm +1 for NOT overloading the token_get_all() function, but rather putting
a static factory method on the PhpToken class (or whatever you call it).
When we add subclassability, we can always add additional statics if our
initial signature doesn't work out.

I'm not clear why you want to final the base constructor.  IMO we populate
the fields on object creation, then invoke constructor (which is a no-op in
the base class).  Later uses of subclassing can deal with the properties
(or not) at that time, in their own constructor, delegating (or not) to the
base.

TL;DR  +1, because I wanted this four years ago. :)
-Sara

Re: [PHP-DEV] [RFC] token_get_all() TOKEN_AS_OBJECT mode

[Thomas Hruska]

On 2/14/2020 1:48 AM, Nikita Popov wrote:

On Thu, Feb 13, 2020 at 6:06 PM Larry Garfield 
wrote:


On Thu, Feb 13, 2020, at 3:47 AM, Nikita Popov wrote:

Hi internals,

This has been discussed a while ago already, now as a proper proposal:
https://wiki.php.net/rfc/token_as_object

tl;dr is that it allows you to get token_get_all() output as an array of
PhpToken objects. This reduces memory usage, improves performance, makes
code more uniform and readable... What's not to like?

An open question is whether (at least to start with) PhpToken should be
just a data container, or whether we want to add some helper methods to

it.

If this generates too much bikeshed, I'll drop methods from the proposal.

Regards,
Nikita


I love everything about this.

1) I would agree with Nicolas that a static constructor would be better.
I don't know about polyfilling it, but it's definitely more
self-descriptive.

2) I'm skeptical about the methods.  I can see them being useful, but also
being bikeshed material.  For instance, if you're doing annotation parsing
then docblocks are not ignorable.  They're what you're actually looking for.

Two possible additions, feel free to ignore if they're too complicated:

1) Should it return an array of token objects, or a lazy iterable?  If I'm
only interested in certain types (eg, doc strings, classes, etc.) then a
lazy iterable would allow me to string some filter and map operations on to
it and use even less memory overall, since the whole tree is not in memory
at once.



I'm going to take you up on your offer and ignore this one :P Returning
tokens as an iterator is inefficient because it requires full lexer state
backups and restores for each token. Could be optimized, but I wouldn't
bother with it for this feature. I also personally have no use-case for a
lazy token stream. (It's technically sufficient for parsing, but if you
want to preserve formatting, you're going to be preserving all the tokens
anyway.)


Try passing a 10MB PHP file that's all code into token_get_all().  It's 
pretty easy to hit hard memory limits and/or start crashing PHP when 
token_get_all() tokenizes the whole thing into a giant array or set of 
objects.  Calling gc_mem_caches() when the previous RAM bits aren't 
needed anymore helps.  Stream-based token parsing would be better for 
RAM usage but I can see how that might be complex to implement and 
largely not worth it since such scenarios will be rare and require the 
ability to maintain lexer state externally as you mentioned and would 
only be used by this part of the software.


--
Thomas Hruska
CubicleSoft President

I've got great, time saving software that you will find useful.

http://cubiclesoft.com/

And once you find my software useful:

http://cubiclesoft.com/donate/

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

Re: [PHP-DEV] [RFC] [PROPOSAL] Immutable/final/readonly properties

[Marco Pivetta]

On Fri, Feb 14, 2020 at 2:23 PM Máté Kocsis  wrote:

>
> So far, my biggest question (apart from the name) have been how non-typed
> properties should behave: as they are implicitly initialized to null if
> they don't have an explicit default value (while typed properties remain
> uninitialized), further modifications would be impossible to do on them -
> which would make non-typed final properties almost useless. Nikita
> suggested to just avoid their initialization, but I'd be curious about
> other ideas as well.
>

Considering that PHP 8 will have union types, adding un-typed properties
support seems like a waste of time.

If somebody really wants a `mixed` property to be immutable, they could
write `private immutable null|bool|int|float|string|array|object
$property;`.

That would make implementation straightforward, since you'd expect
`immutable` to be before a type declaration (can be done in the parser,
right?).

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

[PHP-DEV] [RFC] [PROPOSAL] Immutable/final/readonly properties

[Máté Kocsis]

Hi Internals,

I'd like to propose the idea of adding support for immutable/final/readonly
properties in PHP 8.

My plan is to add a new immutable/final/readonly (the name is up for
debate) property modifier to the language so that these kind of properties
could only be initialized but not modified afterwards. Unlike how final
properties in Java work, I think it would be beneficial to allow lazy
initialization of these properties after object construction have taken
place. Currently, I'm in favour of using final or readonly, but not yet
very sure.

I'll write a proper RFC in the following days/week. My clear intent with
final properties is to pave the road for immutable objects for which I have
a POC pull request open (but I haven't pushed all my work yet).

So far, my biggest question (apart from the name) have been how non-typed
properties should behave: as they are implicitly initialized to null if
they don't have an explicit default value (while typed properties remain
uninitialized), further modifications would be impossible to do on them -
which would make non-typed final properties almost useless. Nikita
suggested to just avoid their initialization, but I'd be curious about
other ideas as well.

Thanks,
Máté Kocsis

Re: [PHP-DEV] [Pre-RFC] Support for decorator patterns

[Rowan Tommins]

On Fri, 14 Feb 2020 at 11:09, Rowan Tommins  wrote:

>
> That would also cover the fluent interface case:
>
> after delegate setFoo {
> $this->delegated = $return;
> return $this;
> }
>


I just realised that this could be easily extended to share an
implementation across multiple methods, making a really succinct decorator
definition:


class FluentThingDecorator implements FluentThing {
private int $setterCount=0;
private int $getterCount =0;

private delegate FluentThing $delegated;

public function __construct(FluentThing $delegate) {
 $this->delegated = $delegate;
}

public function getSetterCount() {
return $this->setterCount;
}
public function getGetterCount() {
return $this->getterCount;
}

after delegate getFoo, getBar, getBaz {
$this->getterCount++;
return $return;
}
after delegate setFoo, setBar, setBaz {
$this->setterCount++;
$this->delegated = $return;
return $this;
}
}


It might be useful to have access to the name of the function actually
called, e.g. for an audit log decorator; maybe the de-sugaring could happen
early enough that __METHOD__ took on the right value for each case.


Regards,
-- 
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] Proposal for a new basic function: str_contains

[Nikita Popov]

On Fri, Feb 14, 2020 at 10:18 AM Philipp Tanlak 
wrote:

> Hello PHP Devs,
>
> I would like to propose the new basic function: str_contains.
>
> The goal of this proposal is to standardize on a function, to check weather
> or not a string is contained in another string, which has a very common
> use-case in almost every PHP project.
> PHP Frameworks like Laravel create helper functions for this behavior
> because it is so ubiquitous.
>
> There are currently a couple of approaches to create such a behavior, most
> commonly:
>  strpos($haystack, $needle) !== false;
> strstr($haystack, $needle) !== false;
> preg_match('/' . $needle . '/', $haystack) != 0;
>
> All of these functions serve the same purpose but are either not intuitive,
> easy to get wrong (especially with the !== comparison) or hard to remember
> for new PHP developers.
>
> The proposed signature for this function follows the conventions of other
> signatures of string functions and should look like this:
>
> str_contains(string $haystack, string $needle): bool
>
> This function is very easy to implement, has no side effects or backward
> compatibility issues.
> I've implemented this feature and created a pull request on GitHub ( Link:
> https://github.com/php/php-src/pull/5179 ).
>
> To get this function into the PHP core, I will open up an RFC for this.
> But first, I would like to get your opinions and consensus on this
> proposal.
>
> What are your opinions on this proposal?
>

Sounds good to me. This operation is needed often enough that it deserves a
dedicated function.

I'd recommend leaving the proposal at only str_contains(), in particular:

 * Do not propose a case-insensitive variant. I believe this is really the
point on which the last str_starts_with/str_ends_with proposal failed.

 * Do not propose mb_str_contains(). Especially as no offsets are involved,
there is no reason to have this function. (For UTF-8, the behavior would be
exactly equivalent to str_contains.)

Regards,
Nikita

Re: [PHP-DEV] Proposal for a new basic function: str_contains

[Claude Pache]

> Le 14 févr. 2020 à 10:17, Philipp Tanlak  a écrit :
> 
> Hello PHP Devs,
> 
> I would like to propose the new basic function: str_contains.
> 
> The goal of this proposal is to standardize on a function, to check weather
> or not a string is contained in another string, which has a very common
> use-case in almost every PHP project.
> PHP Frameworks like Laravel create helper functions for this behavior
> because it is so ubiquitous.

Some time ago, an RFC proposing to add str_starts_with() and str_ends_with() 
was unfortunately declined:

https://wiki.php.net/rfc/add_str_begin_and_end_functions 


Therefore, unless several people have changed their mind in the right direction 
since few months ago, I am pessimistic about the acceptance of str_contains().

—Claude

Re: [PHP-DEV] [Pre-RFC] Support for decorator patterns

[Rowan Tommins]

On Tue, 11 Feb 2020 at 10:14, Nikita Popov  wrote:

> I'd like to get some feedback on the idea implemented in
> https://github.com/php/php-src/pull/5168. It provides an easy way to
> implement decorates, by taking care of forwarding any methods you do not
> want to override in a type-safe way. See the PR description for details.
>


Hi Nikita,

I almost missed this thread because all the discussion has been happening
off-list; for anyone else interested, please note that there's a whole
discussion of the concept, not just the implementation, on the PR.


I actually posted a similar idea a few months ago:
https://externals.io/message/103353

One of the criticisms of my example syntax was that it required you to list
the methods to delegate, which makes multiple delegates easier (you can't
have a  name conflict unless you write the name more than once), but large
or frequently-changing targets unwieldy. The idea of using the property's
interface type to generate the whitelist does feel a lot cleaner.

The other criticism though was that it only helps for the methods you're
completely delegating, not those you want to decorate in some way. It would
be nice if there could also be some sugar for those, perhaps a limited form
of AOP where you could intercept the return value of a delegated call?

interface Bar {
public function doSomething(int $a, string $b, Blob $c): string
}

class Foo implements Bar {
public delegate Bar $bar;

after delegate doSomething {
return $return . ' of doom';
}
}

would de-sugar to:

class Foo implements Bar {
public Bar $bar;

public function doSomething(int $a, string $b, Blob $c): string {
$return = $this->bar->doSomething($a, $b, $c);
return $return . ' of doom';
}
}


That would also cover the fluent interface case:

after delegate setFoo {
$this->delegated = $return;
return $this;
}


Decorating what happens *before* the call would be trickier, because you
need to assign names for the parameters, and by the time you've written out
the whole signature, you might as well implement the method in full.


Regards,
-- 
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] [RFC] token_get_all() TOKEN_AS_OBJECT mode

[Nikita Popov]

On Fri, Feb 14, 2020 at 9:48 AM Nikita Popov  wrote:

> On Thu, Feb 13, 2020 at 6:06 PM Larry Garfield 
> wrote:
>
>> On Thu, Feb 13, 2020, at 3:47 AM, Nikita Popov wrote:
>> > Hi internals,
>> >
>> > This has been discussed a while ago already, now as a proper proposal:
>> > https://wiki.php.net/rfc/token_as_object
>> >
>> > tl;dr is that it allows you to get token_get_all() output as an array of
>> > PhpToken objects. This reduces memory usage, improves performance, makes
>> > code more uniform and readable... What's not to like?
>> >
>> > An open question is whether (at least to start with) PhpToken should be
>> > just a data container, or whether we want to add some helper methods to
>> it.
>> > If this generates too much bikeshed, I'll drop methods from the
>> proposal.
>> >
>> > Regards,
>> > Nikita
>>
>> I love everything about this.
>>
>> 1) I would agree with Nicolas that a static constructor would be better.
>> I don't know about polyfilling it, but it's definitely more
>> self-descriptive.
>>
>> 2) I'm skeptical about the methods.  I can see them being useful, but
>> also being bikeshed material.  For instance, if you're doing annotation
>> parsing then docblocks are not ignorable.  They're what you're actually
>> looking for.
>>
>> Two possible additions, feel free to ignore if they're too complicated:
>>
>> 1) Should it return an array of token objects, or a lazy iterable?  If
>> I'm only interested in certain types (eg, doc strings, classes, etc.) then
>> a lazy iterable would allow me to string some filter and map operations on
>> to it and use even less memory overall, since the whole tree is not in
>> memory at once.
>>
>
> I'm going to take you up on your offer and ignore this one :P Returning
> tokens as an iterator is inefficient because it requires full lexer state
> backups and restores for each token. Could be optimized, but I wouldn't
> bother with it for this feature. I also personally have no use-case for a
> lazy token stream. (It's technically sufficient for parsing, but if you
> want to preserve formatting, you're going to be preserving all the tokens
> anyway.)
>
>
>> 2) Rather than provide bikesheddable methods, would it be feasible to
>> take a queue from PDO and let users specify a subclass of PhpToken to fetch
>> into?  That way the properties are always there, but a user can attach
>> whatever methods make sense for them.
>>
>
> It would be technically feasible. If we go with a static method for
> construction, then one might even say that there's reasonable expectation
> that PhpToken::getAll(...) is going to return PhpToken[] and
> MyPhpTokenExtension::getAll() is going to return MyPhpTokenExtension[].
>
> I'm a bit apprehensive about this though, specifically because you mention
> PDO... which, I think, isn't exactly a success story when it comes to this.
> If we do this, then the behavior would be that the object gets created, the
> properties populated, and *no constructor gets called*. The last part is
> important -- when you start calling constructors and magic methods, that's
> where the mess starts and you get PDO.
>

After thinking about this a bit more, there's a very nice solution to this:
Something that's missing from the current proposal is a constructor. Right
now, if code wants to insert new tokens, then those would have to be
constructed by creating the object and then manually assigning properties,
so we should definitely have a constructor.

Once we have one, we can mark it final, and thus make the construction
behavior well-defined, even if the class is extended.

Nikita

Re: [PHP-DEV] Proposal for a new basic function: str_contains

[G. P. B.]

On Fri, 14 Feb 2020 at 10:58, Aegir Leet  wrote:

> I generally like the idea, but it seems many (most?) real-world
> implementations actually use mb_strpos() !== false by default.
>
>
> https://github.com/danielstjules/Stringy/blob/df24ab62d2d8213bbbe88cc36fc35a4503b4bd7e/src/Stringy.php#L206-L215
>
> https://github.com/illuminate/support/blob/6eff6cff19f7ad5540b9a61a9fb3612ca8218c19/Str.php#L157-L166
>
> So there should definitely be an mb_str_contains in ext/mbstring in
> addition to the regular str_contains proposed here.
>

The biggest reason to have an mb_* variant if for when comparing with case
insensitivity.
The only other reason is if you need to check a string which is in a
different encoding,
which is, I'm assuming, is a quasi non-existent problem as everything
things is UTF-8
nowadays.

The reason why I personally voted no on the previous RFC was that I don't
see the
value of having functions checking if a string starts/ends with a sequence
but not a
general one. Moreover, checking for a substring to start/end a string seems
to be
fitting for the current strpos functions.

This function on it's own is way more reasonable and useful to add IMHO

Best regards

George P. Banyard

Re: [PHP-DEV] Proposal for a new basic function: str_contains

[Aegir Leet]

I generally like the idea, but it seems many (most?) real-world 
implementations actually use mb_strpos() !== false by default.

https://github.com/danielstjules/Stringy/blob/df24ab62d2d8213bbbe88cc36fc35a4503b4bd7e/src/Stringy.php#L206-L215
https://github.com/illuminate/support/blob/6eff6cff19f7ad5540b9a61a9fb3612ca8218c19/Str.php#L157-L166

So there should definitely be an mb_str_contains in ext/mbstring in 
addition to the regular str_contains proposed here.

Re: [PHP-DEV] Proposal for a new basic function: str_contains

[Peter Bowyer]

On Fri, 14 Feb 2020 at 09:18, Philipp Tanlak 
wrote:

> I would like to propose the new basic function: str_contains.
>
> The proposed signature for this function follows the conventions of other
> signatures of string functions and should look like this:
>
> str_contains(string $haystack, string $needle): bool
>
> What are your opinions on this proposal?
>

In principle, yes. There are a couple of considerations first, like how you
plan to handle case-insensitive matches; and previous discussions for this
and the wider context of related string functions:
https://externals.io/message/106162
https://externals.io/message/100142
https://externals.io/message/94787
https://wiki.php.net/rfc/add_str_begin_and_end_functions

Peter

[PHP-DEV] Proposal for a new basic function: str_contains

[Philipp Tanlak]

Hello PHP Devs,

I would like to propose the new basic function: str_contains.

The goal of this proposal is to standardize on a function, to check weather
or not a string is contained in another string, which has a very common
use-case in almost every PHP project.
PHP Frameworks like Laravel create helper functions for this behavior
because it is so ubiquitous.

There are currently a couple of approaches to create such a behavior, most
commonly:
https://github.com/php/php-src/pull/5179 ).

To get this function into the PHP core, I will open up an RFC for this.
But first, I would like to get your opinions and consensus on this proposal.

What are your opinions on this proposal?

Kind regards,
Philipp Tanlak

Re: [PHP-DEV] [RFC] token_get_all() TOKEN_AS_OBJECT mode

[Nikita Popov]

On Thu, Feb 13, 2020 at 6:06 PM Larry Garfield 
wrote:

> On Thu, Feb 13, 2020, at 3:47 AM, Nikita Popov wrote:
> > Hi internals,
> >
> > This has been discussed a while ago already, now as a proper proposal:
> > https://wiki.php.net/rfc/token_as_object
> >
> > tl;dr is that it allows you to get token_get_all() output as an array of
> > PhpToken objects. This reduces memory usage, improves performance, makes
> > code more uniform and readable... What's not to like?
> >
> > An open question is whether (at least to start with) PhpToken should be
> > just a data container, or whether we want to add some helper methods to
> it.
> > If this generates too much bikeshed, I'll drop methods from the proposal.
> >
> > Regards,
> > Nikita
>
> I love everything about this.
>
> 1) I would agree with Nicolas that a static constructor would be better.
> I don't know about polyfilling it, but it's definitely more
> self-descriptive.
>
> 2) I'm skeptical about the methods.  I can see them being useful, but also
> being bikeshed material.  For instance, if you're doing annotation parsing
> then docblocks are not ignorable.  They're what you're actually looking for.
>
> Two possible additions, feel free to ignore if they're too complicated:
>
> 1) Should it return an array of token objects, or a lazy iterable?  If I'm
> only interested in certain types (eg, doc strings, classes, etc.) then a
> lazy iterable would allow me to string some filter and map operations on to
> it and use even less memory overall, since the whole tree is not in memory
> at once.
>

I'm going to take you up on your offer and ignore this one :P Returning
tokens as an iterator is inefficient because it requires full lexer state
backups and restores for each token. Could be optimized, but I wouldn't
bother with it for this feature. I also personally have no use-case for a
lazy token stream. (It's technically sufficient for parsing, but if you
want to preserve formatting, you're going to be preserving all the tokens
anyway.)


> 2) Rather than provide bikesheddable methods, would it be feasible to take
> a queue from PDO and let users specify a subclass of PhpToken to fetch
> into?  That way the properties are always there, but a user can attach
> whatever methods make sense for them.
>

It would be technically feasible. If we go with a static method for
construction, then one might even say that there's reasonable expectation
that PhpToken::getAll(...) is going to return PhpToken[] and
MyPhpTokenExtension::getAll() is going to return MyPhpTokenExtension[].

I'm a bit apprehensive about this though, specifically because you mention
PDO... which, I think, isn't exactly a success story when it comes to this.
If we do this, then the behavior would be that the object gets created, the
properties populated, and *no constructor gets called*. The last part is
important -- when you start calling constructors and magic methods, that's
where the mess starts and you get PDO.

Regards,
Nikita

Re: [PHP-DEV] [RFC]

[Rowan Tommins]

On 14 February 2020 00:39:15 GMT+00:00, Mike Schinkel  
wrote:
>> On Feb 13, 2020, at 7:24 PM, Rowan Tommins 
>wrote:
>> 
>> An idea I had earlier which might solve some of them is if what was
>returned was not a normal Closure instance, but a new class like
>FunctionReference. It could then "remember" the name of the function
>wrapped, and implement __toString, Serializable, etc. It could inherit
>from Closure, so instanceof checks would work, and bindTo would return
>a normal Closure. I'm sure there's downsides I haven't thought of yet,
>but I thought I'd throw the idea into the mix.
>
>I thought about that too, and mentioned it yesterday in a reply[1] to
>you on this list.
>
>Here is the link to the Gist with the hypothetical code using such a
>concept: 
>
>- https://gist.github.com/mikeschinkel/78684d708358e1d101e319c7a2fdef9c


What I had in mind was a combination of that and the existing Closure class, so:

$ref = foo::fn;
$ref(); // run the function
$ref->name; // access extra metadata
$ref->bindTo($whatever); // get a new Closure with a bound context


That would also combine well with one of the proposed bracket style syntaxes 
that let you specify methods more naturally:

{foo}->name; // qualified name of local function
{Foo::bar}; // closure for a static method
{$this->baz}->bindTo($that); // closure for a method of current class rebound 
to a different object


Regards,

-- 
Rowan Tommins
[IMSoP]

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