You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by Stephen Mallette <sp...@gmail.com> on 2017/02/24 19:34:33 UTC
[DISCUSS] P.not and __.not
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
RE: [DISCUSS] P.not and __.not
Posted by "Paul A. Jackson" <Pa...@pb.com>.
If you'll forgive "thinking out loud," is there any way to create a wrapper-not that implements both interfaces and just works?
-----Original Message-----
From: Stephen Mallette [mailto:spmallette@gmail.com]
Sent: Friday, February 24, 2017 2:35 PM
To: dev@tinkerpop.apache.org
Subject: [DISCUSS] P.not and __.not
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
________________________________
Re: [DISCUSS] P.not and __.not
Posted by Stephen Mallette <sp...@gmail.com>.
marko, i didn't realize that choice was intentional. ok - guess i'll keep
hating my life then....
On Fri, Feb 24, 2017 at 2:42 PM, Marko Rodriguez <ok...@gmail.com>
wrote:
> 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 <sp...@gmail.com>
> 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
>
>
Re: [DISCUSS] P.not and __.not
Posted by Marko Rodriguez <ok...@gmail.com>.
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 <sp...@gmail.com> 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
Re: [DISCUSS] P.not and __.not
Posted by Daniel Kuppitz <me...@gremlin.guru>.
VOTE: +1 for the deprecation of P.not.
1. nobody's using it
2. you can have the same result using otherPredicate.negate()
3. when people write not(...) they usually want the NotStep
On Fri, Feb 24, 2017 at 8:34 PM, Stephen Mallette <sp...@gmail.com>
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
>