interesting! I like that you're contemplating multiple backends from the outset. I couldn't tell: are queries composable?
-
-
Replying to @avibryant @johnmyleswhite
that is, instead of `
@query iris |> filter(...)` can you do `@query iris | fn()` where fn() returns `@query filter(...)`?1 reply 0 retweets 1 like -
Replying to @avibryant @johnmyleswhite
Good question! That's in the works, and should be quite easy to implement. Seehttps://github.com/davidagold/StructuredQueries.jl/issues/20 …
1 reply 0 retweets 2 likes -
Replying to @daemonomania @johnmyleswhite
I'm conscious that I'm dropping in on this without much context, but if you don't mind a random observation:
1 reply 0 retweets 0 likes -
it seems like being able to extend queries removes the need for dummy sources -
1 reply 0 retweets 2 likes -
2 replies 0 retweets 3 likes
-
could also imagine flipping arg order and currying (but wouldn't be idiomatic julia IIRC)
1 reply 0 retweets 2 likes -
Replying to @hadleywickham @avibryant
That all seems very reasonable! I appreciate the feedback. Why did it seem a design smell? I'd like to learn.
2 replies 0 retweets 0 likes -
Replying to @daemonomania @hadleywickham
I think because it's a composition/currying mechanism, in a language that already provides that
1 reply 0 retweets 1 like -
Replying to @avibryant
Yes, though it is part of a DSL. My initial thought was, why generate a bunch of `Query` objects when one would suffice?
1 reply 0 retweets 0 likes
my experience is the cost of executing the query >>> time of building/planning it, so that's a needless optimization
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.