You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@metron.apache.org by Casey Stella <ce...@gmail.com> on 2018/06/16 14:17:15 UTC

[DISCUSS] Treating null as false in boolean expressions in Stellar

Right now, because fields may not exist, users can have an awkward time.
For instance, checking for is_alert, you end up having to preface checks
with exists(is_alert).

For instance, in one of our use-cases:
https://github.com/apache/metron/tree/master/use-cases/geographic_login_outliers
we use

"is_alert := exists(is_alert) && is_alert",
"is_alert := is_alert || (geo_outlier != null && geo_outlier == true)",

 instead of :

"is_alert := is_alert || geo_outlier == true",

I suggest that we adopt a convention from javascript whereby we assume a
field not existing or being null should act as false in boolean
expressions.  This will simplify stellar's use and hopefully result in less
awkwardness.

Thoughts?

Re: [DISCUSS] Treating null as false in boolean expressions in Stellar

Posted by Michael Miklavcic <mi...@gmail.com>.
I'm for both of these changes. +1 on the overall idea.

On Tue, Jun 19, 2018, 5:58 AM Charles Joynt <Ch...@gresearch.co.uk>
wrote:

> I'd welcome both of these on the grounds that they'll make life easier
> writing short(er) Stellar code AND deciphering what someone else has
> written.
>
> -----Original Message-----
> From: Casey Stella [mailto:cestella@gmail.com]
> Sent: 16 June 2018 18:33
> To: dev@metron.apache.org
> Subject: Re: [DISCUSS] Treating null as false in boolean expressions in
> Stellar
>
> I created a PR for the empty collection falseyness as well:
> https://github.com/apache/metron/pull/1064 so we can choose either of
> them if we so desire.
>
> On Sat, Jun 16, 2018 at 1:10 PM Casey Stella <ce...@gmail.com> wrote:
>
> > I created a PR for this functionality, in case we decided for it:
> > https://github.com/apache/metron/pull/1063
> >
> > Also, while we're talking, perhaps we should treat empty lists as
> > false as well, like javascript and python.
> > So, for instance, if [] then 'blah' else 'foo' would return foo.
> >
> > Thoughts?
> >
> > On Sat, Jun 16, 2018 at 10:17 AM Casey Stella <ce...@gmail.com>
> wrote:
> >
> >> Right now, because fields may not exist, users can have an awkward time.
> >> For instance, checking for is_alert, you end up having to preface
> >> checks with exists(is_alert).
> >>
> >> For instance, in one of our use-cases:
> >> https://github.com/apache/metron/tree/master/use-cases/geographic_log
> >> in_outliers
> >> we use
> >>
> >> "is_alert := exists(is_alert) && is_alert", "is_alert := is_alert ||
> >> (geo_outlier != null && geo_outlier == true)",
> >>
> >>  instead of :
> >>
> >> "is_alert := is_alert || geo_outlier == true",
> >>
> >> I suggest that we adopt a convention from javascript whereby we
> >> assume a field not existing or being null should act as false in
> >> boolean expressions.  This will simplify stellar's use and hopefully
> >> result in less awkwardness.
> >>
> >> Thoughts?
> >>
> >
>
> --------------
> G-RESEARCH believes the information provided herein is reliable. While
> every care has been taken to ensure accuracy, the information is furnished
> to the recipients with no warranty as to the completeness and accuracy of
> its contents and on condition that any errors or omissions shall not be
> made the basis of any claim, demand or cause of action.
> The information in this email is intended only for the named recipient.
> If you are not the intended recipient please notify us immediately and do
> not copy, distribute or take action based on this e-mail.
> All messages sent to and from this e-mail address will be logged by
> G-RESEARCH and are subject to archival storage, monitoring, review and
> disclosure.
> G-RESEARCH is the trading name of Trenchant Limited, 5th Floor,
> Whittington House, 19-30 Alfred Place, London WC1E 7EA.
> Trenchant Limited is a company registered in England with company number
> 08127121.
> --------------
>

RE: [DISCUSS] Treating null as false in boolean expressions in Stellar

Posted by Charles Joynt <Ch...@gresearch.co.uk>.
I'd welcome both of these on the grounds that they'll make life easier writing short(er) Stellar code AND deciphering what someone else has written.

-----Original Message-----
From: Casey Stella [mailto:cestella@gmail.com] 
Sent: 16 June 2018 18:33
To: dev@metron.apache.org
Subject: Re: [DISCUSS] Treating null as false in boolean expressions in Stellar

I created a PR for the empty collection falseyness as well:
https://github.com/apache/metron/pull/1064 so we can choose either of them if we so desire.

On Sat, Jun 16, 2018 at 1:10 PM Casey Stella <ce...@gmail.com> wrote:

> I created a PR for this functionality, in case we decided for it:
> https://github.com/apache/metron/pull/1063
>
> Also, while we're talking, perhaps we should treat empty lists as 
> false as well, like javascript and python.
> So, for instance, if [] then 'blah' else 'foo' would return foo.
>
> Thoughts?
>
> On Sat, Jun 16, 2018 at 10:17 AM Casey Stella <ce...@gmail.com> wrote:
>
>> Right now, because fields may not exist, users can have an awkward time.
>> For instance, checking for is_alert, you end up having to preface 
>> checks with exists(is_alert).
>>
>> For instance, in one of our use-cases:
>> https://github.com/apache/metron/tree/master/use-cases/geographic_log
>> in_outliers
>> we use
>>
>> "is_alert := exists(is_alert) && is_alert", "is_alert := is_alert || 
>> (geo_outlier != null && geo_outlier == true)",
>>
>>  instead of :
>>
>> "is_alert := is_alert || geo_outlier == true",
>>
>> I suggest that we adopt a convention from javascript whereby we 
>> assume a field not existing or being null should act as false in 
>> boolean expressions.  This will simplify stellar's use and hopefully 
>> result in less awkwardness.
>>
>> Thoughts?
>>
>

--------------
G-RESEARCH believes the information provided herein is reliable. While every care has been taken to ensure accuracy, the information is furnished to the recipients with no warranty as to the completeness and accuracy of its contents and on condition that any errors or omissions shall not be made the basis of any claim, demand or cause of action.
The information in this email is intended only for the named recipient.  If you are not the intended recipient please notify us immediately and do not copy, distribute or take action based on this e-mail.
All messages sent to and from this e-mail address will be logged by G-RESEARCH and are subject to archival storage, monitoring, review and disclosure.
G-RESEARCH is the trading name of Trenchant Limited, 5th Floor, Whittington House, 19-30 Alfred Place, London WC1E 7EA.
Trenchant Limited is a company registered in England with company number 08127121.
--------------

Re: [DISCUSS] Treating null as false in boolean expressions in Stellar

Posted by Casey Stella <ce...@gmail.com>.
I created a PR for the empty collection falseyness as well:
https://github.com/apache/metron/pull/1064 so we can choose either of them
if we so desire.

On Sat, Jun 16, 2018 at 1:10 PM Casey Stella <ce...@gmail.com> wrote:

> I created a PR for this functionality, in case we decided for it:
> https://github.com/apache/metron/pull/1063
>
> Also, while we're talking, perhaps we should treat empty lists as false as
> well, like javascript and python.
> So, for instance, if [] then 'blah' else 'foo' would return foo.
>
> Thoughts?
>
> On Sat, Jun 16, 2018 at 10:17 AM Casey Stella <ce...@gmail.com> wrote:
>
>> Right now, because fields may not exist, users can have an awkward time.
>> For instance, checking for is_alert, you end up having to preface checks
>> with exists(is_alert).
>>
>> For instance, in one of our use-cases:
>> https://github.com/apache/metron/tree/master/use-cases/geographic_login_outliers
>> we use
>>
>> "is_alert := exists(is_alert) && is_alert",
>> "is_alert := is_alert || (geo_outlier != null && geo_outlier == true)",
>>
>>  instead of :
>>
>> "is_alert := is_alert || geo_outlier == true",
>>
>> I suggest that we adopt a convention from javascript whereby we assume a
>> field not existing or being null should act as false in boolean
>> expressions.  This will simplify stellar's use and hopefully result in less
>> awkwardness.
>>
>> Thoughts?
>>
>

Re: [DISCUSS] Treating null as false in boolean expressions in Stellar

Posted by Casey Stella <ce...@gmail.com>.
I created a PR for this functionality, in case we decided for it:
https://github.com/apache/metron/pull/1063

Also, while we're talking, perhaps we should treat empty lists as false as
well, like javascript and python.
So, for instance, if [] then 'blah' else 'foo' would return foo.

Thoughts?

On Sat, Jun 16, 2018 at 10:17 AM Casey Stella <ce...@gmail.com> wrote:

> Right now, because fields may not exist, users can have an awkward time.
> For instance, checking for is_alert, you end up having to preface checks
> with exists(is_alert).
>
> For instance, in one of our use-cases:
> https://github.com/apache/metron/tree/master/use-cases/geographic_login_outliers
> we use
>
> "is_alert := exists(is_alert) && is_alert",
> "is_alert := is_alert || (geo_outlier != null && geo_outlier == true)",
>
>  instead of :
>
> "is_alert := is_alert || geo_outlier == true",
>
> I suggest that we adopt a convention from javascript whereby we assume a
> field not existing or being null should act as false in boolean
> expressions.  This will simplify stellar's use and hopefully result in less
> awkwardness.
>
> Thoughts?
>