Naming Consistency

Question

Naming Consistency

Closed this issue 6 years ago · 10 comments

Wondering... if where maps to filter then shouldn't take should map to top?

Anyway, if there's a "low-priority" tag mark this as such.

Answer 1 · 2019-01-21T19:48:41.000Z

Yeah, it looks weird. ODataQuery doesn't inherit from jinqu IQuery, so we can name methods same as OData parameters. Why didn't I use filter and take is a mystery. Considering we are still in alpha, I am leaning towards renaming them as filter and take. Maybe we can keep where and top, but couple methods for the one operation doesn't feel right.

Answer 2 · 2019-01-21T19:53:25.000Z

I see it now, I reused QueryPart's static methods for where and take. Their names come from Linq. I am convinced renaming them would be better.

Answer 3 · 2019-01-21T20:24:00.000Z

Done.
I renamed where to filter and take to top for better OData compliance.
Next npm will have breaking changes.

Answer 4 · 2019-01-21T20:27:08.000Z

Just published alpha.10.
I hope renaming them would be OK with you. I sure feel better this way.

Answer 5 · 2019-01-21T20:27:50.000Z

Also, I'm considering losing alpha. What do you think?

Answer 6 · 2019-01-21T22:35:33.000Z

The problem is different APIs express the same concept with different names. For example:

jinqu	jinqu-odata	odata	c# linq	default javascript array prototype
where	filter	filter	where	filter
take	top	top	take	N/A
N/A	expand	expand	include	N/A

So to take filtering as an example - you can be consistent with odata, but now it's not consistent with linq, and has a collision with javascript.

In terms of LINQ representing a unified API, perhaps it makes sense to always use C#'s LINQ terms, rather than having different names to suit each provider. After all, the provider's query format is a sense an implementation detail.

Perhaps there's counterarguments. Not sure.

Answer 7 · 2019-01-21T22:47:22.000Z

Lose the alpha. It's too much like a warning sign "not ready; don't use this" as opposed to "this project will have breaking changes". People can judge from the state of the project (e.g. looking at issues) whether breaking changes are going to happen.

Answer 8 · 2019-01-22T07:59:01.000Z

OK, I'm sold. We should stick to Linq syntax, because our promise is to provide OData with Linq syntax.

What do you think about having all? 'where', 'filter', 'top', 'take'. But Linq versions call OData versions?

Answer 9 · 2019-01-22T14:00:07.000Z

I switched back to where and take. Closing this for now.

Answer 10 · 2019-01-22T16:00:51.000Z

Published npm as 0.1.0.

Now methods are 'where' and 'take'.