ike 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
e:
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
ine) - $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
drawing 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
y 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
the right
direction :)
Thanks!
Colin O'Dell
colinod...@gmail.com / colinod...@php.net
--
Colin O'Dell
colinod...@gmail.com
https://www.colinodell.com
d 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 consensu
.
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
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 wrote:
> Due to concerns that have not been adequately addressed during the
> discussion period, and mailing list issues which m
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
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
>
> 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'
>
> 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 RF
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 tha
>
> 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
> an
>
> 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 inter
>
> 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 s
s. I'd be happy to answer any questions you might have.
Regards,
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
> 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 ex
>
> 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 logica
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/rand
icipated 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 wrote:
> On 25.03.2016 at 08:12, Dmitry Stogov wrote:
>
> > Java is going to add "var" (http://ope
You're right! Good call :)
On Thu, Mar 24, 2016 at 3:05 PM Sara Golemon wrote:
> On Thu, Mar 24, 2016 at 11:50 AM, Colin O'Dell
> wrote:
> > Would your proposal also allow ! to work?
> >
> I think you means !===, which is "not-identical assignment&qu
Would your proposal also allow ! to work?
Colin
courage 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
>
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
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
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 fa
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
>
> 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 need
>
> 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
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 wrote:
> Hello all,
>
> I have completed my initial draft of the RFC to deprecate "var"
hp.net/rfc/mailing_list_discussion
Regards,
Colin O'Dell
d you please provide an example where 'var'
is not replaceable by 'public'?
Thanks for your feedback!
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
>
> 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
>
> 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 l
> 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
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 wrote:
> On Thu, Feb 18, 2016 at 11:30 AM, Sebastian Bergmann
> wrote:
>
> > On 02/18/2016 02:10 PM, Colin O'Dell wrote:
> >
> >> I
le 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
41 matches
Mail list logo
