BANG operator? $fn mashups?

[jasonkuhrt]

Could we support something like this?

{ fruit: { '!$in': ['lemon'] } }

The current equivalent would be:

{ fruit: { '$nin': ['lemon'] } }

The maybe "advantage" of a separate bang operator is that it could be used at will without the requirement of n* function variants. How useful is this? Seems dubious. Plus we actually introduce syntax that now requires keys to be wrapped in quotes. This introduces inconsistency, reduces readability, harder to type; big losses!

Another thought is instead of ! allowing combinations of $fn like so:

{ fruit: { $not$in: ['lemon'] } }

This avoids the quotes problem but how scalable is such a system? Beyond this use-case what would composite $ mean? This seems better than the above idea, but still dubious.

[jasonkuhrt]

Oh, regarding the current equivalent of the latter idea (and for that matter the former too):

{ fruit: { $not { $in: ['lemon'] } } }

So remember, actually, that, there is a $not function that negates whatever it wraps. So this issue about a way to combine it without the burden of wrapping whilst not being adhoc (e.g. the idea of combining would need to be generic enough for other kinds of $fn mashups)

[sssyed]

First thing that pops into my head is that if we support !, why not all other relational operators <, >, == as well? Kind of seems like a slippery slope. As a user i'd assume that if ! is available then I would want to use "like" relational operators. Just a thought.

At the moment I do like the current proposed implementation the best out all the ones you've mentioned { cat: { $nin : ['box'] } } }

Also my very first feeling on combining functions is that we'd be getting into lexical analysis/compiler design to make that direction really robust. Seems really fun to explore :sunglasses:, though it could be a longer term vision / project for this lib.

[jasonkuhrt]

First thing that pops into my head is that if we support !, why not all other relational operators <, >, == as well? Kind of seems like a slippery slope. As a user i'd assume that if ! is available then I would want to use "like" relational operators. Just a thought.

Good, totally agree! Lets consider that direction closed...

At the moment I do like the current proposed implementation the best out all the ones you've mentioned { cat: { $nin : ['box'] } } }

Yeah its not too bad but there are few maybe "issues":

• Requires the lib authors to know this n* prefix convention and provide one for each $fn
• While n* is quite handy once its understood and seen to be consistent for different $fns, its actually obscure for the new user, not unlike gte, lt, etc is fine once memorized but a bit annoying at first.

Of course that's why we have this:

{ fruit: { $not { $in: ['lemon'] } } }

Which users can choose, and then opt for n* over time as they feel comfortable.

Which, new-feature-wise, leaves only this:

{ fruit: { $not$in: ['lemon'] } }

Which apparently is literally just the ability to omit { and }. Value-wise this feature is looking pretty feeble.

Also my very first feeling on combining functions is that we'd be getting into lexical analysis/compiler design to make that direction really robust

Yeah more or less! Though couldn't mashups just desugar into the left-most $fn wrapping each successive $fn in the $fn key?

Anyway outside of $not I haven't thought about the use-cases even.

• $cgte$mod
• $xor$in
• ??? haha

[jasonkuhrt]

Regarding my "issues" list above, to be fair its not practical to provide n* prefix versions of each $fn just because it gets silly for already-abbreviated things:

$ncgte

So the idea of being able to do either:

$not: { $cgte: ... }

# or 

$not$cgte

Is clearly not some sort of newbie only expression but really important for all users.

[jasonkuhrt]

Closing for now.