Re: [PHP-DEV] Re: Suggestion: Make all PCRE functions return *character* offsets,rather than *byte* offsets if the modifier `u` (PCRE_UTF8) is given

[Colin O'Dell]

The ability to receive the "character" offset would be extremely useful to
the league/commonmark project.  This project is a Markdown parser which
conforms to the CommonMark spec which defines all behavior with regards to
Unicode code points: <https://spec.commonmark.org/0.29/#character>

On Fri, Oct 2, 2020 at 8:25 AM Christoph M. Becker 
wrote:

> While it is trivial to get the next code point using index+1, this is
> not necessarily the next character, as perceived by a human.  Using
> mb_substr(), you may even break "characters", e.g. <https://3v4l.org/5geOr
> >.
>

In my particular use case, this is entirely acceptable per the spec linked
to above.

Because the CommonMark spec is "character"-centric, we do have a need to
keep track of character positions within strings when parsing forwards, and
while also allowing for regular expressions to be matched against UTF-8
strings.  As Thomas noted, using PREG_OFFSET_CAPTURE provides us with the
byte offset, not the "character" offset.  We therefore must do additional
work to calculate the latter from the former:

$offset = \mb_strlen(\substr($subject, 0, $matches[0][1]),
'UTF-8');

This code is frequently executed and therefore leads to worse performance
than if preg_match() could simply return the offsets we need.

Would I be correct in assuming that preg_match() already has some knowledge
or awareness about codepoints / "characters" when matching against UTF-8
strings and capturing offsets?  If so, I think it would be very beneficial
to provide that information to userland to avoid unnecessary
re-calculations.

I'd therefore like to propose a third alternative option: a new flag like
PREG_OFFSET_CODEPOINT.  When used in combination with PREG_OFFSET_CAPTURE,
it would return the offset position in terms of "characters", not bytes.
This could also be used to interpret any $offset argument as "characters"
instead of bytes.

The reason I prefer this option is that it doesn't break BC and is entirely
opt-in.  If a developer wants this behavior and understands the
implications they can use it.  Nobody else is affected otherwise.

On Fri, Oct 2, 2020 at 8:25 AM Christoph M. Becker 
wrote:

> If mbstring functions are used to find some offset, they always have to
> traverse the string from the beginning, even if you are just interested
> in the last code point of a long string.  If you have byte offsets, that
> code point can be accessed directly.  Of course, that may not suit any
> possible scenario, but I still don't think that the PCRE functions
> should deal with code point offset instead of byte offsets.
>

I'll admit that I don't have the best understanding of how PCRE works
under-the-hood, but I do believe that because it offers some functionality
for working with codepoints, having it also work with codepoint-based
offsets seems like a natural extension.  And while it may not be the most
optimal or common way of working with strings, I do believe there are some
valid use cases for it.  If placing this within PCRE violates some
principles of the library then I'd be okay placing similar functionality
elsewhere.


-- 
Colin O'Dell
colinod...@gmail.com

Re: [PHP-DEV] substr with null length

[Colin O'Dell]

On Mon, Oct 21, 2019 at 11:29 AM Nikita Popov  wrote:

> This is a fairly common deficiency in the implementation of internal
> functions. Part of the reason is that historically zend_parse_parameters
> did not support the ! modifier for integers, and partly these are just
> implementation oversights.
>
> Feel free to send a PR to fix this for PHP 8, no RFC needed. If you're
> interested in addressing this for more functions, do a grep for "= UNKNOWN"
> on the codebase, which gives you (with a few exceptions) a list of
> functions that currently handle null parameters incorrectly and should
> ideally be fixed for PHP 8.
>
>
Thank you so much for that guidance!  I wasn't sure about the RFC as it's
technically a behavioral change, but I agree with you (and Christoph) and
have therefore submitted a pull request with this change:
https://github.com/php/php-src/pull/4840  I'll also take a look at those
other functions and see if I can assist with adjusting those other
instances as well.

Cheers,

Colin O'Dell
colinod...@gmail.com

[PHP-DEV] substr with null length

[Colin O'Dell]

Hello Internals,

Is there any particular reason why the substr() function doesn't accept a
null $length like mb_substr() does?  It seems the behavior to read through
the end of the string can only be controlled by the presence or absence of
the $length parameter:  https://3v4l.org/YpuO1

I discovered this discrepancy between the two methods while attempting to
create a specialized string wrapper class with a method like this:

public function getSubstring(int $start, ?int $length = null): string
{
if ($this->isMultibyte) {
return mb_substr($this->line, $start, $length, $this->encoding);
} else {
return substr($this->line, $start, $length);
}
}

This method would not work as expected without additional boilerplate like:

public function getSubstring (int $start, ?int $length = null): string
{
if ($this->isMultibyte) {
return mb_substr($this->line, $start, $length, $this->encoding);
} elseif ($length === null) {
return substr($this->line, $start);
} else {
return substr($this->line, $start, $length);
}
}

Or:

public function getSubstring (int $start, ?int $length = null): string
{
if ($this->isMultibyte) {
return mb_substr($this->line, $start, $length, $this->encoding);
} else {
return substr($this->line, $start, $length ??
(strlen($this->line) - $start));
}
}

Are there any historical reasons preventing substr() from accepting a null
$length like mb_substr() does?  I'd be happy to write the RFC and take a
stab at the implementation if there's interest in such a change.

Regards,

Colin O'Dell
colinod...@gmail.com

[PHP-DEV] [RFC][Withdrawn] array_change_keys()

[Colin O'Dell]

Hello Internals,

I am withdrawing the array_change_keys() RFC:
https://wiki.php.net/rfc/array_change_keys

While I still believe that PHP is missing the ability to easily re-key an
array, I'm no longer convinced that this particular approach is the best
solution, nor do I currently have the time to address the remaining hurdles
and push this forward.

Perhaps this should indeed remain in userland, as some have suggested, or
perhaps a better solution would be a function to change a single element's
key (which can then be used in a loop by those who need it).  I think the
latter might be interesting.  I was hoping to delay this until I could
fully explore those alternative options but I unfortunately won't have the
bandwidth to do that anytime soon.

So because the RFC is not being actively discussed or worked on, and I have
no plans to push this forward soon, I am withdrawing the RFC.

I would like to thank Jeremy for his help creating the proposed
implementation and everyone who provided candid feedback on this.

Cheers,

Colin O'Dell
colinod...@gmail.com
-- 
Colin O'Dell
colinod...@gmail.com
https://www.colinodell.com

Re: [PHP-DEV] Wiki account gone missing?

[Colin O'Dell]

On Tue, Sep 11, 2018 at 11:55 AM Levi Morrison  wrote:

> Both master.php.net and wiki.php.net have had trouble connecting to
> the database. Try every once in a while and you'll (probably) get
> through eventually.
>

Alright, I appreciate the guidance!  I'll patiently try a few more times,
attempt the other password reset if needed, and reach out to the other list
if all else fails.

Thanks again!

Colin
-- 
Colin O'Dell
colinod...@gmail.com
https://www.colinodell.com

[PHP-DEV] Wiki account gone missing?

[Colin O'Dell]

Hello Internals,

I seem to be unable to access my wiki account (colinodell /
colinod...@php.net).  My credentials are not being accepted and the
password reset functionality does not recognize my username.  I am
therefore unable to manage my RFCs or draft a new one. (My credentials
aren't working on bugs.php.net either, but I haven't done anything there in
a while so I'm not too concerned about not having access to that.)

Any thoughts on how to resolve this?  If this list is not the correct place
to seek support then I'd appreciate if somebody could point me in the right
direction :)

Thanks!

Colin O'Dell
colinod...@gmail.com / colinod...@php.net

-- 
Colin O'Dell
colinod...@gmail.com
https://www.colinodell.com

Re: [PHP-DEV] Re:[PHP-DEV] [VOTE] array_key_first(), array_key_last(), array_value_first(),array_value_last()

[Colin O'Dell]

On Tue, Jul 10, 2018 at 8:42 PM Levi Morrison  wrote:

> This is not how RFC feedback should be handled. I hope more people
> vote no so we can reject this do it properly.
>

I agree with the spirit of this RFC but I also agree with Levi.  It feels
like this particular implementation is being rushed through without
properly addressing some of the outstanding issues and alternate
implementation ideas that have been raised.  The only revisions to the RFC
were the inclusion of the two value-related functions.  IMHO, any RFC going
to vote despite known "opposition" or requested changes should at least
contain a summary of those points and counter-points, but if feels like
those are being ignored here.

So while I do understand the value of such a feature, I'd much rather delay
its implementation than to rush it along with potential issues and no
strong consensus.

Respectfully,

Colin O'Dell
colinod...@gmail.com
https://www.colinodell.com

[PHP-DEV] [RFC] Enable strict_types checking for curl_setopt()

[Colin O'Dell]

Hello internals,

I'd like to propose an enhancement to curl_setopt()
<http://php.net/manual/en/function.curl-setopt.php> which is used to
configure a given curl session.  The second argument of this function
defines which option to set and the third argument provides the
corresponding value to use.

Because each option expects the value to be a specific type, it makes sense
to enforce these types in strict type checking mode.  I'd therefore like to
propose that we introduce strict type enforcement inside curl_setopt() when
"declare(strict_types=1);" is being used.

The full details of the proposal, including the proposed patch, can be
found here: https://wiki.php.net/rfc/curl_setopt_strict_types

Huge thanks to Sara Golemon for the idea and creating the patch!

Cheers,

Colin O'Dell
colinod...@gmail.com

Re: [PHP-DEV] [RFC][VOTE] array_change_keys

[Colin O'Dell]

Hearing no objections, voting is now halted and the RFC is back to "Under
Discussion".

Cheers,
Colin

On Mon, Jan 9, 2017 at 2:40 PM Colin O'Dell <colinod...@gmail.com> wrote:

> Due to concerns that have not been adequately addressed during the
> discussion period, and mailing list issues which might be impacting the
> ability to discuss the RFC and/or its vote, I'd like to halt voting and
> revert this RFC to "Under Discussion".  Are there any objections to this?
>
> On Mon, Jan 9, 2017 at 2:23 PM Levi Morrison <le...@php.net> wrote:
>
> I kindly request that this voting be delayed until the mailing list
> issues are completely fixed.
>
> The mailing list software still rejects some messages with URLs; this
> was seemingly fixed but I am unable to send any messages with URLs in
> them, including quoting the original message.
>
>

[PHP-DEV] [RFC][VOTE] array_change_keys

[Colin O'Dell]

Greetings all,

It's been a while since we introduced the array_change_keys RFC
<https://wiki.php.net/rfc/array_change_keys>.  During the discussion period
there was a healthy mix of interest and critique.  It seems all the major
discussion points were covered, so I'd like to put this RFC to a vote to
determine its fate.

Therefore, voting is now open on the array_change_keys RFC:
https://wiki.php.net/rfc/array_change_keys  Voting will close 2017-01-23 at
23:59:59 UTC.

Mailing list discussion thread:
https://marc.info/?l=php-internals=146452769326964=2

Reddit discussion thread:
https://www.reddit.com/r/PHP/comments/4ll1hg/rfc_array_change_keys/

The implementation is also on 3v4l.org should you wish to test it out.

Regards,

Colin O'Dell

Re: [PHP-DEV] [RFC Discussion] array_change_keys()

[Colin O'Dell]

array_change_keys() has been added to 3v4l.org if anyone would like to try
it online.  Simple example: https://3v4l.org/vehTo/rfc#tabs

Re: [PHP-DEV] [RFC Discussion] array_change_keys()

[Colin O'Dell]

>
> Ported to https://github.com/Ocramius/array_change_keys-benchmark, thanks!
>

I've updated the RFC's benchmarks based on your tool.  They confirm that
array_change_keys is faster than array_combine but slower than foreach (in
most cases).  Thanks for helping with this!


> No, but I really don't care about the other functions. If something
> doesn't support a `Traversable` in today's jungle of Generators and
> asynchronous processing.
>

While generators and async processing are nice, I don't think that means we
have to avoid work that doesn't fall under that umbrella.  Or Is there
perhaps something unique about this particular function that warrants
Traversable support whereas other functions don't?


> 3. Purpose of the array_*() function is immediately obvious.
>>
>
> Disagree, as mentioned in few edge cases in other responses (something
> about numerical keys, IIRC: can't find the actual reply)
>

I believe you're referring to the questions about returning null, invalid,
or duplicate keys.  As I mentioned in my responses to those questions,
array_change_keys() was expressly designed to behave *EXACTLY* like
existing functions (such as array_flip):

 - Returning null as a key is not allowed (array_flip disallows this).
 - If you return a duplicate key, only the last value to return it will be
kept (just like calling array_flip with duplicate values or running:
$arr['foo'] = 1; $arr['foo'] = 2;)

Somebody else asked whether they could "return null" to use an automatic
numeric key - I responded "no" because "$arr[null]" is not the same as
"$arr[]".

*Again, this RFC does NOT introduce any new edge cases or quirks.*  I'd
therefore respectfully ask that you re-consider this.


>  Function composition can be applied also with a userland implementation.
> My main issue with this is that it doesn't need to exist in *core*. Doesn't
> mean that it can't exist in userland ;-)
>

One could argue that array_change_key_case(), array_column(), random_int(),
password_hash(), and others don't strictly need to exist in core either.
However, they were all included because someone (or some group) felt that
they provided enough value to PHP developers and/or that their usefulness
outweighed the hassle of a userland implementation.  All I ask is that we
give this RFC the same consideration - and if you still feel the same I
fully accept that :)

I appreciate the feedback as always and have updated the RFC with several
of these discussion points.

Colin

Re: [PHP-DEV] [RFC Discussion] array_change_keys()

[Colin O'Dell]

>
> Yes there is:
> array_combine(
> array_map($someFunc, array_keys($arr), $arr),
> $arr
> )
> This way $someFunc gets key as first argument and value as second. (you
> might use array_values($arr) instead of $arr but I’m not sure it’s worth it)
>

Good call!  I have updated the RFC to include this example as it best
matches the behavior of the proposed function.

Regards,

Colin

Re: [PHP-DEV] [RFC Discussion] array_change_keys()

[Colin O'Dell]

Marco,


>  1. could you also provide the code for the benchmarks? I'd gladly measure
> them with an accurate tool
>

Yeah that would be great!  Here's the benchmark I was using:
https://gist.github.com/colinodell/872c1f0c92351af687347c0c8be4f253


>  2. do we really need another array function that is basically an
> `array_combine(array_map($someFunc, array_keys($arr)), $arr)`?
>

While array_combine() technically works, the callback does not have access
to both the key AND value.  Anyone needing access to both must currently
resort to using a foreach loop (unless there's some other clever
combination of functions that I'm missing).

We already have array_change_key_case().  IMO that function is way too
specific and not applicable in 99% of situations where you need to re-key
an array.  This is why I'm proposing a general purpose function custom
tailored to rekeying an array.

I'll touch on some other advantages further down this message.

 3. and... do we really want another function that accepts arrays and not
> generic Traversable (and therefore also generators)?
>

Do the other array functions support this?  If not then I'd argue that
adding Traversable support to array functions should be part of a broader
RFC which adds this support to all applicable functions at once.

In the mean time, you could certainly use iterator_to_array with this
proposed function:

$b = array_change_keys(iterator_to_array($a), $callback);

Doing this with array_combine() would require an intermediate variable to
prevent a "Fatal error: Uncaught Exception: Cannot traverse an already
closed generator":

$b = iterator_to_array($a);
$a = array_combine(array_map($callback, array_keys($b)), $b);

Even if all array functions did support generators you'd still need this
intermediate variable to prevent the double traversal - array_change_keys()
would not have this problem.


>  4. what is the real-world benefit over just
> `array_combine(array_map($someFunc, array_keys($arr)), $arr)`, except for
> the two additional function calls here?
>

There are several IMO:

1. Callback has access to both the original key AND the original value.
The array_combine() approach can only access one or the other.
2. Better performance (hoping you can confirm this).
3. Purpose of the array_*() function is immediately obvious.
4. No need for intermediate variable when working with iterators means
function composition is possible.

Thanks for the feedback!

Colin

Re: [PHP-DEV] [RFC Discussion] array_change_keys()

[Colin O'Dell]

>
> The RFC states "The new array returned by this function will contain the
> same values in the same order, but with potentially different keys."
>
> But further down it states, that on multiple times the same key the last
> one will "win". So in that special case it's **not** the same array
> anymore. Or did I miss something?
>

You're right, I didn't word that first part very well.  I've revised the
RFC to mention the two "exceptions to the rule" earlier.

Essentially this function is going to mirror the behavior of array_flip()
whenever an invalid or duplicate key is encountered.

Thanks for catching that!

Colin

Re: [PHP-DEV] [RFC Discussion] array_change_keys()

[Colin O'Dell]

>
> shouldn't it be possible to return null as new key? That way you say:
> Use the next free integer index.
>
> Not sure if returning null is wanted (as it could hide errors in the
> callback) or needed in some real world use cases. But it would be more
> in sync with $a[] = ...
>

That's an interesting idea, but it would go against how other array
functionality works.

For example, if you ran this:

var_dump( array_combine([null, null], ['foo', 'bar']) );

You'd get the following output:

array(1) { [""]=> string(3) "bar" }

The null you intended to be a key becomes an empty string instead, and the
latter value of "bar" overrides the former one.

You'll see this same behavior if you did the following:

$a = [];
$a[null] = 'foo';
$a[null] = 'bar';

So that's one way nulls are handled.  The other way is to raise a warning
and skip that element, which is what array_flip (and this proposal) does:

var_dump( array_flip(['foo' => 'null']) );

Output:

Warning: array_flip(): Can only flip STRING and INTEGER values! in
/in/7bBvO on line 3 array(0) { }

Implementing the feature you mentioned would introduce a third approach,
which is something I'd like to avoid.  Perhaps a future RFC could implement
this feature, either for just this one function or others as well?

Colin

Re: [PHP-DEV] [RFC Discussion] array_change_keys()

[Colin O'Dell]

>
> Does this RFC really require a 2/3 majority? I mean, it does not change
> the syntax or alters anything. It is just about a single new function?
>
> https://wiki.php.net/rfc/voting#required_majority
>

Good catch!  You're right, this RFC only adds a single new function and
does not modify the syntax or anything else.  I've updated the RFC's voting
section accordingly.

Colin

[PHP-DEV] [RFC Discussion] array_change_keys()

[Colin O'Dell]

Hello everyone,

I'd like to introduce a new RFC for your consideration and discussion:
https://wiki.php.net/rfc/array_change_keys  This would add a new function
named array_change_keys() which simplifies the process of re-keying an
array.

PHP currently has an array_change_key_case() method, but this only allows
keys to be changed to upper- or lower-case; no method exists to change the
keys to some custom user-defined value.  Although it's absolutely possible
to accomplish this without a special function, the alternate approaches
have several drawbacks:

 - Slower execution time compared to the proposed implementation.
 - Multiple lines and/or function calls are required.
 - Harder to understand the code's purpose with a quick glance.
 - The result of a "foreach" approach cannot be passed into another
function without using an intermediate variable.

A working implementation has been included with the RFC (huge thanks to
Jeremy Mikola for the heavy lifting here!)  I've also requested this patch
be added to 3v4l.org; I'll notify everyone if/when that happens.

I'd greatly appreciate if you could review this RFC and let me know your
thoughts.  I'd be happy to answer any questions you might have.

Regards,

Colin O'Dell

Re: [PHP-DEV] [RFC] PHP Attributes

[Colin O'Dell]

>
> $r = new ReflectionClass('ORM\Entity');
> var_dump($r->getAttributes());
>

Oops, that should've been:

$r = new ReflectionClass('Foo');
var_dump($r->getAttributes());

Colin

Re: [PHP-DEV] [RFC] PHP Attributes

[Colin O'Dell]

> A more robust alternative would be something along the same lines that
> Doctrine uses: Make annotations actual classes.

Just spitballing here - what if both approaches were supported, but
class-based annotations were prefixed with a special character (perhaps
"@") to differentiate them?  For example:

<>
<<@ORM\Entity(table => "foo")>>
class Foo {
// ...
}

namespace ORM;
class Entity implements \Attribute {
// ...
}

$r = new ReflectionClass('ORM\Entity');
var_dump($r->getAttributes());

-

array(2) {
["ArbitraryAnnotation"]=>
string(11) "Hello world"
["ORM\Entity"] =>
object(ORM\Entity)#1 (0) { ... }
}

-

Again, I'm not necessarily advocating this - just throwing the idea out
there for discussion.

Regards,

Colin

Re: [PHP-DEV] UUID

[Colin O'Dell]

>
> I would prefer not to refer to random to avoid any confusion with the
> recent added random function. As uuid is not crypto safe and is not aimed
> to. Users will then hopefully not think about using instead of the random
> api.
>
> Also uuid alone may be a problem (bc?) It sounds like a logical choice.
> Alternatively uuid_create ().
>
Ah yes, good point.  I was thinking random_uuid() might be good for v4
UUIDs, and that a parameter might be needed, but I failed to make the
connection that not all UUID versions are random - my apologies for not
catching that before hitting send.

I like the idea of uuid() or uuid($version = 4)

Re: [PHP-DEV] UUID

[Colin O'Dell]

On Tue, Apr 12, 2016 at 2:09 AM Sebastian Bergmann 
wrote:

> In PHP 7.0 we introduced random_bytes() which wraps Linux's getrandom(2)
> as well as Windows's CryptGenRandom() and uses /dev/urandom as a fallback.
>
> I think it would be great if we added a function that wraps
> /proc/sys/kernel/random/uuid [2] and, if that exists, its equivalent on
> Windows to make the generation of UUIDs easy.
>
> Thoughts?
>

I'd love to see UUID generation in core using a similar platform-based
approach, as long as the implementation matches RFC 4122.  Part of this
will be determining which versions/variants should be supported:
https://en.wikipedia.org/wiki/Universally_unique_identifier#RFC_4122_Variant

Version 4 (random) UUIDs is an obvious choice, but should any others be
supported initially?

Perhaps the implementation could be a simple function named random_uuid()
which either takes no parameters or a single parameter "$version" which
defaults to 4?

Regards,

Colin

Re: [PHP-DEV] [VOTE] var deprecation

[Colin O'Dell]

The voting period for the "var deprecation" RFC has ended.  The final vote
was 31 in favor and 23 against.  The 2/3 majority requirement was not met
and therefore this RFC has been DECLINED.

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

I'd like to thank everyone who participated in the discussions, and a
special thanks to Thomas Punt for helping to create the proposed patch.

Regards,

Colin O'Dell

On Fri, Mar 25, 2016 at 7:14 AM Christoph Becker <cmbecke...@gmx.de> wrote:

> On 25.03.2016 at 08:12, Dmitry Stogov wrote:
>
> > Java is going to add "var" (http://openjdk.java.net/jeps/286), we are
> going to remove...
>
> If this JEP is going to pass, "var" will be allowed to replace (local)
> *type declarations*.  In PHP "var" is an alternative *visibility
> specification*.  That's something quite different.
>
> --
> Christoph M. Becker
>
>

Re: [PHP-DEV] Add spaceship assignment operator

[Colin O'Dell]

You're right! Good call :)

On Thu, Mar 24, 2016 at 3:05 PM Sara Golemon <poll...@php.net> wrote:

> On Thu, Mar 24, 2016 at 11:50 AM, Colin O'Dell <colinod...@gmail.com>
> wrote:
> > Would your proposal also allow ! to work?
> >
> I think you means !===, which is "not-identical assignment" (!== =)
>
> ! is just *CRAZY TALK*
>
> -Sara
>

Re: [PHP-DEV] Add spaceship assignment operator

[Colin O'Dell]

Would your proposal also allow ! to work?

Colin

[PHP-DEV] Re: [VOTE] var deprecation

[Colin O'Dell]

There have been some last-minute concerns raised about var being reserved
"for future usage".  My intent was that var couldn't be used for
function/class names IN CASE it was re-used in the future, but not
encouraging it to be re-used.  I'd assume that reusing it would require a
separate RFC to pass by a 2/3rds margin.

Does anyone disagree with this interpretation or feel that it should be
explicitly stated?  Would anyone change their vote from NO to YES if "for
future usage" was removed (but "reserving it" was kept in)?  Would anyone
change their vote from NO to YES if the question of "reserving it" could be
voted on separately?

If so, and we can stop the vote to make these changes, I'd strongly prefer
to do so.  I'd hate for three words to sink the entire RFC.

(My apologies if this belongs in the discussion thread instead)

Regards,

Colin

On Thu, Mar 24, 2016 at 8:40 AM Colin O'Dell <colinod...@gmail.com> wrote:

> Hello everyone,
>
> It has been two weeks since discussion started on the RFC to deprecate and
> eventually remove the "var" keyword (and one month since the idea was
> originally proposed).
>
> This RFC has therefore been moved to the "In Voting" state.  Voting will
> begin immediately and will end in one week.
>
> You can find the full RFC (including the proposed patch and automatic
> upgrade tool) here: https://wiki.php.net/rfc/var_deprecation
>
> I encourage everyone to read the RFC and cast your vote towards whichever
> option you feel is the best for the language and the community.
>
> Regards,
>
> Colin O'Dell
>

Re: [PHP-DEV] [RFC][Discussion] Precise session data management

[Colin O'Dell]

I'm +1 for splitting it into smaller chunks.  I didn't fully comprehend the
impact of some aspects of the RFC and therefore didn't feel it was
appropriate for me to cast a vote either way.  However, if the different
pieces were broken out into smaller, more-focused RFCs I would likely vote
for most of them.

Regards,

Colin

[PHP-DEV] [VOTE] var deprecation

[Colin O'Dell]

Hello everyone,

It has been two weeks since discussion started on the RFC to deprecate and
eventually remove the "var" keyword (and one month since the idea was
originally proposed).

This RFC has therefore been moved to the "In Voting" state.  Voting will
begin immediately and will end in one week.

You can find the full RFC (including the proposed patch and automatic
upgrade tool) here: https://wiki.php.net/rfc/var_deprecation

I encourage everyone to read the RFC and cast your vote towards whichever
option you feel is the best for the language and the community.

Regards,

Colin O'Dell

Re: [PHP-DEV] RFC about automatic template escaping

[Colin O'Dell]

Daniel,

This is a really interesting idea!  However, I'm unsure whether it's wise
to bring this feature in without having the community test and validate it
first.  Would it be possible to release this as an extension first so we
can gauge its stability and desirability in "the real world"?

As far as the implementation goes, one thing I don't like is the complexity
involved to output unescaped HTML.  I'd strongly prefer to do something
like  than having to instantiate a special class
every time I need to output some raw HTML.

Also, I know some templating systems (like Twig) allow you to specify
different escaping strategies:
http://twig.sensiolabs.org/doc/filters/escape.html  Would this proposed
feature have any similar functionality?

Best regards,

Colin

On Tue, Mar 22, 2016 at 9:26 AM Jan Tvrdík  wrote:

> On Tue, 22 Mar 2016 14:01:09 +0100, Craig Duncan 
> wrote:
>
> >>
> >>
> >> Why do you assume that Latte parser is limited by regexp ability to
> >> parse
> >> HTML?
> >
> >
> > Because it is:
> >
> https://github.com/nette/latte/blob/19b759b550caaad75ca0dee5f0d85f9ffb59c845/src/Latte/Parser.php#L124
>
> No. That argument would only be valid, if the parser consisted only of a
> single regexp. When you combine PHP code with PCRE you loose nothing from
> PHP's turing completeness and it's ability to parse HTML.
>
> That being said I'm not claiming that Latte parser is 100 % correct HTML
> parser (neither is most existing HTML parsers in the world). I'm saying
> that it could be (to the extend of what's possible to statically analyze,
> i.e. if editor could highlight the code properly).
>
> Regards,
> Jan Tvrdik
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] php 7 bug in substr_replace function

[Colin O'Dell]

Hi Pascal,

The bug tracker can be found here: https://bugs.php.net/

You might also want to include this link in your bug report - it shows the
results of your test across multiple versions of PHP, thus confirming the
behavior: https://3v4l.org/bPOK3

Cheers,

Colin

Re: [PHP-DEV] [RFC Discussion] "var" Deprecation

[Colin O'Dell]

>
> Forcing people to specify a visibility for properties and not for methods
> would add yet another inconsistency in the language.
>

That's a really good point.  However, I think we currently have a different
inconsistency: declaring functions without explicit visibility is possible
without needing an extra (and redundant) keyword.

The inconsistency you mention could easily be solved by a future RFC.  We
could:

  1. Require visibility for class methods.
  2. Allow declaring properties without using any keywords.
  3. Use some other approach?

I don't think we necessarily need to choose an option at this time (or
perhaps ever).


> #1
> class Example {
> var $foo;
> }
>
> #2
> class Example {
> public $foo;
> }
>
> #3
> class Example {
> public function __construct() {
> $this->foo = null;
> }
> }
>
> If I understand this RFC, example #1 is handled by it, but not #3.
> Using #1 would emit a deprecation notice, but #3 wouldn't?
>

Correct.  This RFC only targets the deprecation and removal of T_VAR.


> As far as I am concerned, I think it is still better to declare the
> properties rather than not and this RFC would (somehow) favour not
> declaring them at all than doing so with "var".
>

I disagree - this RFC does not prevent anyone from declaring properties,
you just need to explicitly declare the visibility.


> I'm generally in favour of not having duplicated ways of doing the exact
> same thing.
> I'm generally in favour of not introducing (uneeded) BC issues.
> I'm not convinced that the number of people that will benefit the
> uniqueness of declaring a variable would be greater than the one suffering
> upgrade issues.
>

I disagree on the third point - I think the automated upgrade process is
literally the second-easiest upgrade possible (#1 would be no changes
required).  Nevertheless, I truly appreciate you considering and weighing
the different aspects of this proposal.  I'm hoping others will take a
similar approach in deciding whether they support this RFC.

Thanks for your feedback!

Colin

>

Re: [PHP-DEV] [RFC Discussion] "var" Deprecation

[Colin O'Dell]

>
> I'm still on the fence about this, but here's a patch for it:
> https://github.com/php/php-src/compare/master...tpunt:deprecate-var


Thank you so much Thomas!  I have added your patch to the RFC.  I really
appreciate you taking the time to implement this.

Regards,

Colin

[PHP-DEV] Re: [RFC Discussion] "var" Deprecation

[Colin O'Dell]

My apologies, I posted the wrong discussion link.  Here's the correct one:
http://markmail.org/message/wn3ykdwgplfctho7

Colin

On Thu, Mar 10, 2016 at 12:14 PM Colin O'Dell <colinod...@gmail.com> wrote:

> Hello all,
>
> I have completed my initial draft of the RFC to deprecate "var" in favor
> of "public": https://wiki.php.net/rfc/var_deprecation
>
> I would greatly appreciate any feedback on this RFC, especially with the
> following:
>
> - Ensuring that all major arguments for & against have been documented.
> - Any impact this may have on SAPIs, extensions, or the opcache.
> - Any assistance or guidance on creating the patch (I've never written C
> or worked with the core codebase before).
>
> If you'd like to read the pre-draft discussion it can be found here:
> https://wiki.php.net/rfc/mailing_list_discussion
>
> Regards,
>
> Colin O'Dell
>

[PHP-DEV] [RFC Discussion] "var" Deprecation

[Colin O'Dell]

Hello all,

I have completed my initial draft of the RFC to deprecate "var" in favor of
"public": https://wiki.php.net/rfc/var_deprecation

I would greatly appreciate any feedback on this RFC, especially with the
following:

- Ensuring that all major arguments for & against have been documented.
- Any impact this may have on SAPIs, extensions, or the opcache.
- Any assistance or guidance on creating the patch (I've never written C or
worked with the core codebase before).

If you'd like to read the pre-draft discussion it can be found here:
https://wiki.php.net/rfc/mailing_list_discussion

Regards,

Colin O'Dell

Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal

[Colin O'Dell]

Lester,

> The problem with 'var' is that while one should probably
> replace them all with public, there is a lot of simple legacy code still
> in active use that could take years to 'tidy'

'var' would not be removed until 8.x, so you'd have several years before
needing to make code changes.  Additionally, the RFC will include this
script which automatically upgrades legacy code in mere seconds:
https://gist.github.com/colinodell/5fb5e5d474674f294a38

If you're staying on PHP 5.x or 7.0, no changes would be needed.  If you're
upgrading to 7.1+, you would need to either hide deprecation notices or
take 30 seconds to run that script.

> Only a small percentage are 'actually' replaceable by public

My understanding is that 'var' is simply an alias for 'public' so they
should behave identically.  Could you please provide an example where 'var'
is not replaceable by 'public'?

Thanks for your feedback!

Colin O'Dell

Re: [PHP-DEV] Re: [RFC Proposal] var keyword deprecation/removal

[Colin O'Dell]

>
> By the time of 8.0 nothing would be different from today. 8.0 is not
> some magic number by which old code ceases to exist.
>

The usage of "var" may continue to decline as folks increasingly adopt the
newer visibility keywords.  Perhaps it's too early to make this decision
and this discussion needs to be postponed for some time?  I'm okay with
that.  But if/when the decision is made to remove it, doing so in a major
release with ample warning seems to be the right approach, and 8.0 seems
far enough way to be a potential candidate.

I truly appreciate your thoughts and feedback.  Thank you!

Colin

Re: [PHP-DEV] Re: [RFC Proposal] var keyword deprecation/removal

[Colin O'Dell]

>
> It would have to be done in 8.0, since removing it would constitute a BC
> break.
>

Thanks for clarifying that Tom! Makes sense to me.


> It's worth noting that there were better reasons for deprecating PHP
> 4-style constructors over the simple redundancy argument. Specifically,
> there was confusion as to when a PHP 4-style constructor would actually be
> considered a constructor (see the RFC [1] for examples). With the var
> keyword, there's no ambiguity like this.
>

That's a fair point.  I only included that example to highlight the trend
of using the PHP 5 style features over PHP 4.  You're right though, there's
no reason "var" might be misconstrued as something else.


> Whilst the language purist in me would like to remove redundant things
> like this, I feel that it's a rather unnecessary BC break to introduce. So
> I'm not entirely decided on this.
>

I'm not 100% convinced on this either.  I just thought the idea had enough
merit to warrant a discussion :)

Colin

Re: [PHP-DEV] Re: [RFC Proposal] var keyword deprecation/removal

[Colin O'Dell]

>
> I think it's a drop in the bucket compare to new features we're adding
> plenty of on every version.  These make the language a lot more complex
> than var being an alias to public (not even different syntax).
>

Very true. I'm not proposing this because it's a great new feature. But has
this legacy functionality outlived its original purpose?  If so, maybe it's
time to start phasing it out.  Sure, it's a small drop in the bucket of
improvements, but it's still a drop nonetheless.

To me, var falls squarely in the bucket of "no strong reason to remove".
>

I agree 100%.

But is there a strong reason to keep it forever, especially considering its
decline in usage?  Perhaps by targeting it for removal in 8.0 we can
mitigate the impact of such a BC break while taking one small step in
improving the language over time.

Colin

Re: [PHP-DEV] Re: [RFC Proposal] var keyword deprecation/removal

[Colin O'Dell]

> Though if we do get rid of the var syntax, I'd like it if we kept the
> reserved word, because it still might be useful in future for typed
> variables or different variable scoping.

Good idea Andrea!  Thanks for that suggestion.

I do have a general question about these types of changes: if the
deprecation were to land in 7.1, when would the actual removal take place -
7.2 or 8.0?  Or would that be a voting option?

I really appreciate all the feedback so far - keep it coming!

Colin

Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal

[Colin O'Dell]

> What are your reasons for this proposal?
>
> I can think of multiple reasons why this might not be a good idea, but the
> only reason that pops to mind for getting rid of it is to make PHP work
> like a different style of language.

I'm proposing this change because it will remove duplicate functionality
from the language.

In PHP 4, "var" was the only way to declare a class member variable.  PHP 5
introduced three new keywords for this purpose: public, protected, and
private.  "public" is functionally identical to "var".  According to the
docs:

> Class properties must be defined as public, private, or protected. If
> declared using var, the property will be defined as public.

This is great for backwards compatibility from PHP 4, but it ultimately
results in having two different keywords which do exactly the same thing.
Does PHP 7 really need two keywords for declaring public class members?

We're already removing PHP 4 style constructors in favor of the PHP 5 style
ones, so why not also remove the PHP 4 "var" keyword in favor of the PHP 5
style keywords which explicitly state the visibility?

For the small percentage of projects which still use "var", upgrading their
code would be dead simple: just replace "var" with "public" everywhere you
see it.  I'm sure somebody can easily whip up a tool to automate that
process.

Because current usage of "var" seems low and the upgrade path is so simple,
I don't think its a bad idea.

Colin

On Thu, Feb 18, 2016 at 3:25 PM Walter Parker <walt...@gmail.com> wrote:

> On Thu, Feb 18, 2016 at 11:30 AM, Sebastian Bergmann <sebast...@php.net>
> wrote:
>
> > On 02/18/2016 02:10 PM, Colin O'Dell wrote:
> >
> >> I'd like to propose an RFC to deprecate and eventually remove the "var"
> >> keyword.
> >>
> >
> >  +1
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> What are your reasons for this proposal?
>
> I can think of multiple reasons why this might not be a good idea, but the
> only reason that pops to mind for getting rid of it is to make PHP work
> like a different style of language.
>
>
> Walter
>
> --
> The greatest dangers to liberty lurk in insidious encroachment by men of
> zeal, well-meaning but without understanding.   -- Justice Louis D.
> Brandeis
>

[PHP-DEV] [RFC Proposal] var keyword deprecation/removal

[Colin O'Dell]

Hello everyone,

I'd like to propose an RFC to deprecate and eventually remove the "var"
keyword.

My understanding is that this keyword was kept in PHP 5 for
backwards-compatibility with PHP 4.  However, it's been 9 years since PHP 4
was discontinued, so I'd like to bring this topic up for review.

Usage of "var" doesn't seem to be as widespread recently. I've done a quick
search of several major projects and libraries and found that only a couple
are using it.  I personally haven't seen it used in any PHP 5.3+ project
I've worked on in recent memory.

Because "var" simply acts as an alias for "public", removing it should not
cause any loss of functionality.  Yes, it's a BC break, but developers can
easily replace it with "public" to maintain the same functionality.

PHP 7 deprecated PHP 4 style constructors in favor of the PHP 5
__construct() method.  I'd like to propose doing the same for the "var"
keyword - deprecate it in PHP 7.1 and remove it in a future version (7.2 or
8.0?)

I'd appreciate any thoughts or feedback you may have, especially if you
have any objections to me creating an RFC for this proposal.

Best regards,

Colin O'Dell