On Thu, 2014-10-23 at 12:54 -0700, Stas Malyshev wrote:
> Hi!
>
> > P.S. u() is a bad name, will break lots of code, i.e.
>
> Maybe __u()? It's a bit ugly but you're not allowed to use __ so it's safe.
>
/me cringes ...
I wonder how much of a problem it really is, usually when we say some
func
On Thu, 2014-10-23 at 12:47 -0700, Stas Malyshev wrote:
> Hi!
>
> > Not ready for discussion yet ...
> >
> > https://wiki.php.net/rfc/hashkey
>
> Hey, I've just started my own... https://wiki.php.net/rfc/objkey I guess
> we should combine them :)
>
Done, branch @ http://github.com/krakjoe/php-
On Thu, 2014-10-23 at 12:47 -0700, Stas Malyshev wrote:
> Hi!
>
> > Not ready for discussion yet ...
> >
> > https://wiki.php.net/rfc/hashkey
>
> Hey, I've just started my own... https://wiki.php.net/rfc/objkey I guess
> we should combine them :)
>
Happy to port patch already written to confor
On Fri, Oct 24, 2014 at 12:11 PM, Kalle Sommer Nielsen wrote:
> Hi
>
> 2014-10-24 5:02 GMT+02:00 Xinchen Hui :
>> Hey:
>>
>>-1 on this.
>>
>>Actually, your example for explaining usage..
>>
>> I don't see why it is must, add a getSize() will also meet the
>> needs, and more beatiful,
Hi
2014-10-24 5:02 GMT+02:00 Xinchen Hui :
> Hey:
>
>-1 on this.
>
>Actually, your example for explaining usage..
>
> I don't see why it is must, add a getSize() will also meet the
> needs, and more beatiful, as you can change $size to another name if
> you like later.
I disagree on
Hey:
On Fri, Oct 24, 2014 at 7:36 AM, Andrea Faulds wrote:
> Good evening once again,
>
> Here’s another RFC: https://wiki.php.net/rfc/readonly_properties
>
> It proposes, with a working implementation, a modifier for properties that
> makes them readable and writeable from different scopes.
>
> On 23 Oct 2014, at 20:50, Marc Bennewitz wrote:
>
> You addresses data loss on convert float to int.
> Do you also address data loss on int to float?
>
> |to_float(||9223372036854774784) -> pass |as it results in
> 9223372036854774784
> |to_float(|||9223372036854774785|) -> |failas it res
Good evening once again,
Here’s another RFC: https://wiki.php.net/rfc/readonly_properties
It proposes, with a working implementation, a modifier for properties that
makes them readable and writeable from different scopes.
Since I am a big proponent of including specification patches in new RFCs
I have updated the section on Reflection to explain some of the design
decisions: https://wiki.php.net/rfc/returntypehinting#reflection;
hopefully that will help you and others to understand the rationale.
Please let me know if you have follow-up questions.
--
PHP Internals - PHP Runtime Developm
> On 23 Oct 2014, at 20:54, Stas Malyshev wrote:
>
>> P.S. u() is a bad name, will break lots of code, i.e.
>
> Maybe __u()? It's a bit ugly but you're not allowed to use __ so it's safe.
I don't like that. This might sound crazy, but what about adding Unicode string
literals to the parser, e
Hi!
> P.S. u() is a bad name, will break lots of code, i.e.
Maybe __u()? It's a bit ugly but you're not allowed to use __ so it's safe.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: h
You addresses data loss on convert float to int.
Do you also address data loss on int to float?
|to_float(||9223372036854774784) -> pass |as it results in
9223372036854774784
|to_float(|||9223372036854774785|) -> |failas it results in
9223372036854774784
|
Marc
|
On 23.10.2014 21:40, Marc Benn
Hi!
> Not ready for discussion yet ...
>
> https://wiki.php.net/rfc/hashkey
Hey, I've just started my own... https://wiki.php.net/rfc/objkey I guess
we should combine them :)
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime Developme
I really like the strictness of this casting rules except of "010" will
be a valid integer / float.
As of you don't allow "0x" and trailing white spaces as valid numbers
and don't allow floating like syntax as integers even if it result in
mathematical integer.
Allowing prefixed "0" as valid numbe
On Thu, Oct 23, 2014 at 5:50 PM, Andrea Faulds wrote:
> Hi!
>
> > On 23 Oct 2014, at 13:47, Dmitry Stogov wrote:
> >
> > Hi Andrea,
> >
> > The synthetic benchmarks are not always reflect the impact on real-life
> performance.
> >
> > Unfortunately, I wasn't able to run any big real-life apps wi
On Thu, 2014-10-23 at 14:59 +0100, Andrea Faulds wrote:
> > On 23 Oct 2014, at 14:53, Johannes Schlüter wrote:
> >
> >> On Thu, 2014-10-23 at 11:38 +0100, Joe Watkins wrote:
> >> It doesn't solve the problem directly but allows the programmer to solve
> >> it for themselves, just like Object.hash
> On 23 Oct 2014, at 14:53, Johannes Schlüter wrote:
>
>> On Thu, 2014-10-23 at 11:38 +0100, Joe Watkins wrote:
>> It doesn't solve the problem directly but allows the programmer to solve
>> it for themselves, just like Object.hashCode in Java.
>
> The point is that it won't work in this way:
>
On Thu, 2014-10-23 at 11:38 +0100, Joe Watkins wrote:
> It doesn't solve the problem directly but allows the programmer to solve
> it for themselves, just like Object.hashCode in Java.
The point is that it won't work in this way:
$a = [ $ustring => $value ];
foreach ($a as $key => $v) {
> On 23 Oct 2014, at 14:44, Rowan Collins wrote:
>
> Dmitry Stogov wrote on 21/10/2014 10:01:
>> The "right" approach, would be extending zend_string with "encoding" and
>> then adopting near all functions working with zend_string to take
>> "encoding" into account. But, of course, this is going
Hi!
> On 23 Oct 2014, at 13:47, Dmitry Stogov wrote:
>
> Hi Andrea,
>
> The synthetic benchmarks are not always reflect the impact on real-life
> performance.
>
> Unfortunately, I wasn't able to run any big real-life apps with your bigint
> branch, because it misses support for commonly used
Dmitry Stogov wrote on 21/10/2014 10:01:
The "right" approach, would be extending zend_string with "encoding" and
then adopting near all functions working with zend_string to take
"encoding" into account. But, of course, this is going to lead to much more
complicated solution (with some slowdown)
Hi Andrea,
The synthetic benchmarks are not always reflect the impact on real-life
performance.
Unfortunately, I wasn't able to run any big real-life apps with your bigint
branch, because it misses support for commonly used extensions
(ext/session, ext/json, ext/pdo).
I ran bench.php and it's a
i have to explore and contribute to php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> On 23 Oct 2014, at 09:44, Dmitry Stogov wrote:
>
> this won't completely solve the problem, because array keys won't be
> UString anymore.
Sure, but unless we turn arrays into SplObjectStorage that won’t change. Nobody
wants to touch arrays and make them support other key types. Heck, my big
On Thu, 2014-10-23 at 12:44 +0400, Dmitry Stogov wrote:
> this won't completely solve the problem, because array keys won't be
> UString anymore.
http://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#hashCode()
Others solve this problem in exactly this way, the Java implementation
requir
> On 22 Oct 2014, at 21:12, Andrea Faulds wrote:
>
> I ran the script several times, then took the results and put them into Excel
> to produce the above table with its averages.
>
> So common scripts are either unaffected, or will run ever-so-slightly faster.
Just to be clear, though, that d
Marc Bennewitz wrote on 22/10/2014 20:12:
On 22.10.2014 10:37, Bob Weinand wrote:
I know we have that already discussed a lot now, but I’d like to expose my
points on the return value here:
I imagine code like (supposing that we ever will have scalar typehints):
function acceptsInt (int $i =
Joe Watkins wrote on 23/10/2014 09:18:
I'd rather higher level stuff existed at a higher level, I'd rather
solve for ustring the problems that are solved for normal strings and
leave the rest up to whatever the framework/component/library or wants
to do.
It's not really higher level in terms of
this won't completely solve the problem, because array keys won't be
UString anymore.
Thanks. Dmtiry.
On Thu, Oct 23, 2014 at 12:11 PM, Joe Watkins wrote:
> On Tue, 2014-10-21 at 10:30 -0700, Stas Malyshev wrote:
> > Hi!
> >
> > > I wish there was a way for specific objects to opt into this.
>
On Tue, 2014-10-21 at 07:49 -0700, Sara Golemon wrote:
> > On Oct 21, 2014, at 0:06, Joe Watkins wrote:
> >
> > Morning internalz,
> >
> >https://wiki.php.net/rfc/ustring
> >
> >This is the result of work done by a few of us, we won't be opening any
> > vote in a fortnight. We have a lo
On Tue, 2014-10-21 at 10:28 -0700, Stas Malyshev wrote:
> Hi!
>
> > https://wiki.php.net/rfc/ustring
> >
> > This is the result of work done by a few of us, we won't be opening any
> > vote in a fortnight. We have a long time before 7, there is no rush
> > whatever.
>
> Couple of thought
On Tue, 2014-10-21 at 21:42 +0100, Rowan Collins wrote:
> On 21/10/2014 08:06, Joe Watkins wrote:
> > Morning internalz,
> >
> > https://wiki.php.net/rfc/ustring
> >
> > This is the result of work done by a few of us, we won't be opening any
> > vote in a fortnight. We have a long time befo
On Tue, 2014-10-21 at 10:30 -0700, Stas Malyshev wrote:
> Hi!
>
> > I wish there was a way for specific objects to opt into this.
>
> There will be, if __hashKey() or whatever would be the properly
> bikeshedded name, becomes reality as discussed elsewhere. It shouldn't
> be hard to do and it's e
33 matches
Mail list logo
