Re: [PHP-DEV] Do symbol references always go through a hash table?

On Wed, May 18, 2016 at 1:06 PM, Sara Golemon wrote: > Yes, but that doesn't mean you should micro-optimize around it. Just > write code that's easy to maintain and trust the compiler to do the > best job at making it not-slow. :) > > Do you happen to know whether or not HHVM

Re: [PHP-DEV] Do symbol references always go through a hash table?

On Tue, May 17, 2016 at 7:51 PM, Jesse Schalken wrote: > Does that mean a function which accepts an instance of an interface and > calls a method on it will have to do a full lookup of the method whenever > the concrete class isn't the same as when that function was first

Re: [PHP-DEV] Do symbol references always go through a hash table?

Thanks Nikita, Does that mean a function which accepts an instance of an interface and calls a method on it will have to do a full lookup of the method whenever the concrete class isn't the same as when that function was first executed? (or was last executed, depending on how the cache works)

Re: [PHP-DEV] [RFC] Pipe Operator

On 17/05/2016 18:46, Sara Golemon wrote: On Tue, May 17, 2016 at 4:14 AM, Rowan Collins > wrote: >> On 17/05/2016 11:55, Jesse Schalken wrote: $id |> >> StringList::decode($$) |> array_replace($$, $replace) |> >> StringList::encode($$) |> $id; >> >> >> Sara, what do

Re: [PHP-DEV] [RFC] Simple Annotations

On 17/05/2016 18:47, Rasmus Schultz wrote: I don't really understand what closures have to do with annotations, or how that relates to capturing context. The point is that, rather than trying to capture context, you can just as well ask for what you need. I'm going to use a very contrived

Re: [PHP-DEV] [RFC] Simple Annotations

On 5/17/2016 7:47 PM, Rasmus Schultz wrote: > You're not annotating the function - this is just a round-about way of > annotating the argument. > > You would do that directly, like this: > > function foo( > << ValidateRange(0, 100) >> > int $percentage > ) { ... } > What is this good

Re: [PHP-DEV] [RFC] Pipe Operator

On Tue, May 17, 2016 at 5:47 AM, Ryan Pallas wrote: > Can the place holder be used twice? > In the current PR version, no. It adds complexity to the implementation when dealing with temp vars. In the interest of keeping the implementation simple, I opted for making the

Re: [PHP-DEV] [RFC] Simple Annotations

> I don't really understand what closures have to do with annotations, or how > that relates to capturing context. The point is that, rather than trying to capture context, you can just as well ask for what you need. I'm going to use a very contrived example, because I really can't think of any

Re: [PHP-DEV] [RFC] Pipe Operator

On Tue, May 17, 2016 at 4:14 AM, Rowan Collins wrote: > On 17/05/2016 11:55, Jesse Schalken wrote: > $id > |> StringList::decode($$) > |> array_replace($$, $replace) > |> StringList::encode($$) > |> $id; > > > Sara, what do you think of this tweak, and my

Re: [PHP-DEV] [RFC] Simple Annotations

On 5/17/2016 11:06 AM, Rasmus Schultz wrote: > I believe I have already stated my position on all of these concerns > in my last email. > Sorry if I cannot keep everything in my mind. On 5/17/2016 11:06 AM, Rasmus Schultz wrote: > There's no such thing as optional dependencies - if you depend

Re: [PHP-DEV] [RFC] Simple Annotations

On 17/05/2016 17:21, guilhermebla...@gmail.com wrote: It all sounds reasonable on #2 what everyone is heavily forcing/suggesting because of DbC, but it *only* makes sense in the context of a function call (or a bound object in case of OO members). In any other case its outcome is unpredictable.

Re: [PHP-DEV] [RFC] Simple Annotations

@Rasmus: This approach is too broad, allowing situations like Marco pointed out. I'd have to vote -1 on it too if you move forward, specially if you consider things like << "How do I grab this?" >> and other weirdness. @Rowan: Annotations should be immutable by nature. Still, I would love if you

Re: [PHP-DEV] [RFC] Simple Annotations

On 05/17/2016 04:22 PM, Rasmus Schultz wrote: I'd like to finish this RFC, but I have two remaining issues. The syntax is a minor issue - since any valid PHP expression can be used, the bit-shift ambiguity is technically an issue, however marginal. A lot of people commented on the syntax when

Re: [PHP-DEV] [RFC] Simple Annotations

On 17/05/2016 15:22, Rasmus Schultz wrote: The other issue is the dependency (context) injection example - no one seems to be able to cite an actual use-case, and if that's the case, I should probably just remove it from the RFC entirely? @Larry can you think of a case example in the myriad

[PHP-DEV] Re: [VOTE] Forbid dynamic calls to scope introspection functions

On Sun, May 15, 2016 at 10:46 PM, Nikita Popov wrote: > Hi internals, > > 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. > > Nikita > Thanks to a comment on

Re: [PHP-DEV] Do symbol references always go through a hash table?

On Tue, May 17, 2016 at 3:03 PM, Jesse Schalken wrote: > Hi Internals, > > I'd like to know whether references to > classes/functions/methods/properties/variables always go through a hash > table at runtime, or if the name is optimised into a pointer or fixed > offset. I

Re: [PHP-DEV] [RFC] Simple Annotations

I'd like to finish this RFC, but I have two remaining issues. The syntax is a minor issue - since any valid PHP expression can be used, the bit-shift ambiguity is technically an issue, however marginal. A lot of people commented on the syntax when I posted the RFC on reddit - they don't like it.

Re: [PHP-DEV] [RFC] Pipe Operator

On 17/05/2016 13:48, Jesse Schalken wrote: On Tue, May 17, 2016 at 9:14 PM, Rowan Collins > wrote: To reiterate my comments from earlier in the thread, I think the "$id = $id" looks really weird here, and spoils the step-by-step

[PHP-DEV] Do symbol references always go through a hash table?

Hi Internals, I'd like to know whether references to classes/functions/methods/properties/variables always go through a hash table at runtime, or if the name is optimised into a pointer or fixed offset. I recall seeing such an optimisation for local variables, but what about the others? Thanks

Re: [PHP-DEV] [RFC] Pipe Operator

On Tue, May 17, 2016 at 9:14 PM, Rowan Collins wrote: > To reiterate my comments from earlier in the thread, I think the "$id = > $id" looks really weird here, and spoils the step-by-step layout - and, in > this case, the symmetry. > We have the same thing already when

Re: [PHP-DEV] [RFC] Pipe Operator

On Tue, May 17, 2016 at 6:15 AM, François Laupretre wrote: > > > >> The question of function aliases is not so serious because we'll need very >>> few. Almost every functions have only one 'natural' argument to >>> substitute >>> as lhs. I'm not sure I understand what you mean

Re: [PHP-DEV] [RFC] Pipe Operator

Le 16/05/2016 à 19:53, Sara Golemon a écrit : I think you're making a false equivalence here. One can see argument ordering consistency as a serious problem without seeing a Heath Robinson version of call chaining as the solution to it. I appreciate that you want to seize onto any opportunity

Re: [PHP-DEV] [RFC] Pipe Operator

On 17/05/2016 11:55, Jesse Schalken wrote: $id = $id |> StringList::decode($$) |> array_replace($$, $replace) |> StringList::encode($$); To reiterate my comments from earlier in the thread, I think the "$id = $id" looks really weird here, and spoils the step-by-step layout - and,

Re: [PHP-DEV] [RFC] Pipe Operator

Not sure if it's already been mentioned, but I've noticed this operator would be useful when you want to modify something but need to transform it before and after. For example, I have a class that serializes/deserializes arrays of strings, and I need to modify the array that it has encoded. The

[PHP-DEV] NEUTRAL Benchmark Results for PHP Master 2016-05-17

Results for project PHP master, build date 2016-05-17 06:28:54+03:00 commit: 1fe7b3b previous commit:bc63879 revision date: 2016-05-17 02:09:29+03:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB

Re: [PHP-DEV] [RFC] Pipe Operator

Hi Sara, On Apr 30, 2016 3:11 AM, "Sara Golemon" wrote: > > This is one of my favorites out of HackLang. It's pure syntactic > sugar, but it goes a long way towards improving readability. > https://wiki.php.net/rfc/pipe-operator After I first read the rfc my immediate feeling

Re: [PHP-DEV] [RFC] Simple Annotations

Richard, I believe I have already stated my position on all of these concerns in my last email. Short recap: There's no such thing as optional dependencies - if you depend on a Doctrine ORM annotation, you depend on that package. The code should (must) error the moment you try to instantiate