Hey:
On Tue, May 17, 2016 at 6:00 AM, Adam Baratz wrote:
> Hi,
>
> I've encountered a hard-to-consistently-reproduce issue with HashTable
> zvals. I have code that will generate big nested \stdClass structures for
> JSON encoding. It does so using classes that have methods that generate
> those
Hi,
I've encountered a hard-to-consistently-reproduce issue with HashTable
zvals. I have code that will generate big nested \stdClass structures for
JSON encoding. It does so using classes that have methods that generate
those fields. For example, you could have a class like this:
class Block {
On 16 May 2016 at 09:31, Dmitry Stogov wrote:
> I'm sorry, I didn't follow the RFC discussion.
> In general I like the idea, but why not to use Closure constructor?
>
Hi Dmitry,
Several small to medium sized reasons that make me think it's the best way.
As Marco said, constructors cannot be pas
On 5/16/2016 3:05 PM, Rasmus Schultz wrote:
> I'm sorry, but I think that the idea of meta-data that can't error
> somehow, somewhere, at some point, is completely unrealistic.
>
> And I'd much rather have a simple facility that enables those errors
> to surface quickly.
>
It should error and it
On Mon, May 16, 2016 at 2:17 AM, François Laupretre wrote:
> Le 16/05/2016 à 03:33, Larry Garfield a écrit :
>> This still sounds awfully complicated to me. I would far, far prefer
>> the $$ syntax to special casing function aliases just to dance around
>> it. If we had a short-function syntax t
On 16/05/2016 14:05, Rasmus Schultz wrote:
> I'm afraid I don't follow. Why is it a problem to simply add a
> function or class to the global namespace?
>
> << new Memoize() >>
>
> or maybe a class with factory functions for built-in annotations:
>
> << Meta::memoize() >>
Well, those particular na
>
> The RFC
>
> https://wiki.php.net/rfc/forbid_dynamic_scope_introspection
>
> is now in voting. The vote closes on 2016-05-24 with a required majority of
> 2/3.
I voted no. While I agree these appear to be exotic use cases, my quibble
boils down to the assumption these minimally exist in th
Rowan,
I'm afraid I don't follow. Why is it a problem to simply add a
function or class to the global namespace?
<< new Memoize() >>
or maybe a class with factory functions for built-in annotations:
<< Meta::memoize() >>
I tend to agree with Richard though, that system directives really
ought
Results for project PHP master, build date 2016-05-16 06:29:31+03:00
commit: bc63879
previous commit:ccf18da
revision date: 2016-05-15 14:15:04+01:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
On 5/13/2016 2:57 PM, Davey Shafik wrote:
> 2) I like the idea of Hacks memoize for example, how do you see those being
> implemented? Or don't you?
>
I wrote it in the /attribute grammar/ thread and I write it here again.
Stuff like memoize should be implemented as keywords as part of the
langua
On 5/13/2016 2:11 PM, Rasmus Schultz wrote:
> Dear Internals,
>
> I'm announcing a simplified RFC for annotations:
>
> https://wiki.php.net/rfc/simple-annotations
>
-1 again, I am sorry.
The problem is that an annotation by definition is just meta-data. Your
proposal however might result in fa
Le 16/05/2016 à 03:33, Larry Garfield a écrit :
This still sounds awfully complicated to me. I would far, far prefer
the $$ syntax to special casing function aliases just to dance around
it. If we had a short-function syntax then requiring a piped function
to have only a single argument would
On 14/05/2016 20:49, Rasmus Schultz wrote:
Dan,
I've added a note about special annotations to the "future scope"
section, naming the memoization-annotation as an example.
This doesn't really explain how such a feature would fit it into the
proposal. For instance, how can we avoid the syntax
On Mon, 16 May 2016 03:56:38 +0300, Sara Golemon wrote:
On Sun, May 15, 2016 at 11:20 AM, Nikita Nefedov
wrote:
why would you need to support a $this->fieldName case though?
Because to not support it would be to deliberately design in a new
flavor of inconsistency into the language. $obj->
On 16 May 2016 at 10:31, Dmitry Stogov wrote:
> I'm sorry, I didn't follow the RFC discussion.
> In general I like the idea, but why not to use Closure constructor?
>
> $f = new Closure("some_func");
>
> would look more readable than
>
> $f = Closure::fromCallable("some_func");
>
> Sorry, if this
I'm sorry, I didn't follow the RFC discussion.
In general I like the idea, but why not to use Closure constructor?
$f = new Closure("some_func");
would look more readable than
$f = Closure::fromCallable("some_func");
Sorry, if this was already discussed before.
Thanks. Dmitry.
___
16 matches
Mail list logo
