On Apr 9, 1:57 pm, John Firebaugh <[email protected]> wrote:
> I encounter this situation when I have an external datastructure and I need
> to convert it to a filter hash, via inject({}) {...} or similar. With the
> current API, I need to create an extra branch in my code to handle the empty
> case.
Are these cases where you wouldn't have access to the dataset?
Because anything possible with a filter hash is going to be possible
with individual filter calls:
ds = ds.filter(data.inject({}){|d, (k,v)| d[k] = v; d})
# vs.
ds = data.inject(ds){|d, (k,v)| d.filter(k=>v)}
> I consider it a code smell when an API does not have a sensible behavior for
> obvious boundary conditions in its input. This is of particular concern for
> functions like filter that are commonly used in situations where the
> arguments are not a static condition but built dynamically from runtime
> input.
Agreed. Like I said, I'm certainly willing to consider this patch.
The implementation isn't difficult and the performance hit is modest.
Simply because I think there are generally better ways doesn't mean I
think Sequel should violate the POLS.
BTW, how do you think this should be handled?:
ds.filter(nil)
That currently raises an error. I think it should probably use WHERE
NULL (there just isn't a when clause for nil), but I could see some
people thinking filter(nil) should be the same as filter().
Jeremy
--
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sequel-talk?hl=en.
