filter(null) and filterExact(null) *should* produce the same result about crossfilter HOT 10 CLOSED

Are you willing to rewrite my code to accomodate this API change? :)

from crossfilter.

Is your code open source?

Well.. that's why I say should
It's a proposal for the next version.
When unions, dimension removal, and group removal changes are, possibly, added.

I took time to update my version of cross filter, and make the changes to my code.

I posted this because it just seemed odd that for the execution to take that path.

Pass undefined as the parameter, then: update filter() to have if(range === undefined)
Then, anywhere you call filter(null) update to filter() or filter(undefined).

i may be oversimplifying things.

from crossfilter.

I'm no javascript expert, but I'm not certain deliberate use of undefined is a common idiom in js apis. I pose it as a question.

There may also be some precedent (expectations) based on null and three-state logic used in SQL.

We have a textbook case here in the difficulty of executing the principle of least astonishment. Honestly when I used filter(null) it seemed very natural. But again, my data does not contain nulls, so I never filter on a null value.

from crossfilter.

Actually, it's not deliberately using undefined as a parameter, more so the exclusion of parameters to the filter() function.

This should be enough to say that we wish to call filterAll() (which in itself expects no parameters)
All other filter handler functions expect one or more parameters.

from crossfilter.

I'm not passionate about it either way, but FYI here is my typical use case.

var filter = someControlViewer.getTheFilter();
dimension.filter(filter);

So.. the proposal means my control needs to return "undefined" rather than "null" to mean - there is no filter selected. As I mention previously, this is a bit of an odd idiom.

Alternatively, I need intermediary controller logic which determines if the control's filter is empty, or selected, and calls concrete methods filterExact(filter) or filterAll(). By this logic, the filter() method is completely unnecessary and redundant.

As a convenience function filter() has the exact semantics I am looking for and follows "null as empty" conventions I am accustomed to. Rather than describe this as an "inconsistency", I would argue it is a very useful feature.

from crossfilter.

simple change would be: dimension.filter(filter||undefined);

If filter is null, the undefined value is passed instead.

As a convenience function filter should be meant to filter on whatever is passed.
If you pass nothing, nothing is filtered (aka filterAll()) if null is passed, filter on null (as in the filterExact() test cases)

Brandon Myers
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

On Wednesday, February 13, 2013 at 3:15 PM, aaronaverill wrote:

I'm not passionate about it either way, but FYI here is my typical use case.
var filter = someControlViewer.getTheFilter();
dimension.filter(filter);
So.. the proposal means my control needs to return "undefined" rather than "null" to mean - there is no filter selected. As I mention previously, this is a bit of an odd idiom.
Alternatively, I need intermediary controller logic which determines if the control's filter is empty, or selected, and calls concrete methods filterExact(filter) or filterAll(). By this logic, the filter() method is completely unnessary and redundant.
As a convenience function filter() has the exact semantics I am looking for.

—
Reply to this email directly or view it on GitHub (#54 (comment)).

from crossfilter.

"dimension.filter(filter||undefined);"

If your goal with this bit of code is a more consistent, readable and easily understood API, you have failed, at least for me. Now we have not only added "undefined", but the null || idiom in passing function arguments. Pity the junior coder that comes along on the project and tries to unravel the reason for this, or the outsourced overseas agency that needs to make a quick change on a short term contract.

I leave these kinds of gymnastics to the js minifiers but understand it is a personal preference to style. I guess we will have to disagree on this.

from crossfilter.

Having different behavior for null vs. undefined is a bit surprising, since null == undefined and they are sometimes used ambiguously. More generally, dimension.filter is a convenience function for calling dimension.filterExact, dimension.filterRange or dimension.filterAll; so, if you want to be unambiguous, you should use those methods exclusively rather than dimension.filter.

from crossfilter.

null == undefined
but
null !== undefined

In any case, it was just a suggestion since filterExact(null) actually performs a filter function, and I am using filter as a entry for multiple filter types on a common code path. So this would make sense for my case.
Being readable, I would indeed split into each filter function based on type… but I would be repeating the same work that filter already does.
Additionally, I use the union feature, which means, for my case, the filter variable as an array could be a union or a filterRange.
filter() already does the detection for me. I call dimension.filter.apply with the dimension and data array parameters.
If I have no values to filter, then filter() is called with no parameters, which means filterAll(), one value filterExact (even if null), etc….

From the test cases, there are several values of "null" for tip. (which is suppose to convert to zero) for numeric values that is fine.
But for string or object values where null means null, this might be a problem. I don't know yet as I haven't hit that possibility.

Brandon Myers

On Wednesday, February 13, 2013 at 4:22 PM, Mike Bostock wrote:

Having different behavior for null vs. undefined is a bit surprising, since null == undefined and they are sometimes used ambiguously. More generally, dimension.filter is a convenience function for calling dimension.filterExact, dimension.filterRange or dimension.filterAll; so, if you want to be unambiguous, you should use those methods exclusively rather than dimension.filter.

—
Reply to this email directly or view it on GitHub (#54 (comment)).

from crossfilter.

As discussed in #151 an active fork is being developed in a new Crossfilter Organization. Please take further discussion there (if you haven't already) where it should be warmly welcomed by the new maintainers. Cheers!

from crossfilter.