Hi,

It is not random. Preference is always given to the P operators over their 
traversal counterparts. If there is some random component, we should fix it, 
but we should always give precedence to P so we are backwards compatible.

Marko.

http://markorodriguez.com



> On Feb 24, 2017, at 12:34 PM, Stephen Mallette <[email protected]> wrote:
> 
> P.not and __.not unfortunately tangle with each other when using static
> imports. I think we allowed the console to dictate to us that P.not is the
> lucky one that gets to be used without its qualifying prefix. I'm not sure
> there was any conscious decision to do it that way. Indeed, I think i would
> prefer getting __.not over P.not. I also think that the behavior is sort of
> random that we get P.not rather than __.not (for reasons I can go into in
> more detail if anyone cares).
> 
> Anyway, I'd like to resolve this issue in 3.3.0. I think that immediately,
> I can introduce the breaking change to the console that explicitly imports
> __.not rather than P.not - this will remove randomness. In the longer term
> we can deprecate P.not and either drop it all together or rename it. I'm
> not sure how strongly folks feel about usage of P.not so I guess I'll just
> open it up for discussion as to what the long term fix should be here.
> 
> If we don't develop any real consensus here for the longer term option I
> will just create an issue in JIRA and it can be dealt with later. I'm
> mostly interested in getting a short-term solution in place to solve some
> problems I'm facing right now.
> 
> Thanks,
> 
> Stephen

Reply via email to