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
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
> 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
>
> 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
>
> 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
>
> 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
d you please provide an example where 'var'
is not replaceable by 'public'?
Thanks for your feedback!
Colin O'Dell
hp.net/rfc/mailing_list_discussion
Regards,
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 wrote:
> Hello all,
>
> I have completed my initial draft of the RFC to deprecate "var"
>
> 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
>
> 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
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
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
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
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
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
>
Would your proposal also allow ! to work?
Colin
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
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
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
>
> 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
> 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
>
> $r = new ReflectionClass('ORM\Entity');
> var_dump($r->getAttributes());
>
Oops, that should've been:
$r = new ReflectionClass('Foo');
var_dump($r->getAttributes());
Colin
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
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
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
s. I'd be happy to answer any questions you might have.
Regards,
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 s
>
> 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
>
> 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
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
>
> 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
>
> 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'
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
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
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
.
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
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 right
direction :)
Thanks!
Colin O'Dell
colinod...@gmail.com / colinod...@php.net
--
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
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
41 matches
Mail list logo
