Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How should list functions return *no* data? #59

Closed
adama2000 opened this issue Jan 30, 2021 · 10 comments
Closed

How should list functions return *no* data? #59

adama2000 opened this issue Jan 30, 2021 · 10 comments

Comments

@adama2000
Copy link
Contributor

Soliciting comments here.

As pointed out in #53, some of our "List" functions return different things when there is no data found.

52% of the functions return an empty list.
{"status":{"error":false},"data":{"instances":[]}}
48% of the functions return nothing.
{'status': {'error': False}}

I'd like to make them consistent, but how should they work?

The main argument against changing it in either direction, is that any users who have coded expecting one kind of return may find their code breaking if the return has changed.

Thoughts?

@DieSwartKat
Copy link

We have been using Creoson for some time now but still running it on an older version. It will not influence us right now, and I'm therefore arguing that an empty list should be returned as a standard.

In python a none == false and an empty list also == false. If the return from Creoson is validated like this the result would be the same.

Is it Creoson policy that all versions are compatible with existing code bases? Was this something that was promised when it was first published? If not, I think the consistency for the code to react the same is the way forward.

@Zepmanbc
Copy link

in my opinion, if error is false, there should be a data part.
empty data, like an empty data, is still data/information

@phaleth
Copy link

phaleth commented Jan 30, 2021

Different or not, this is an API. In an API breaking changes should never be done and if so only with a major version release. APIs are supposed to remain stable. Consider doing deprecation, which means introducing second way to do the same calls. For a while the old inconsistent calls should remain along with the new ones. Also consider immediate removal of the old way of doing calls but just from the docs, so the old ways of doing calls are less likely to be used by new adopters of the API.

@adama2000
Copy link
Contributor Author

in my opinion, if error is false, there should be a data part.
empty data, like an empty data, is still data/information

Indeed that is a separate issue -- currently any function that returns data will not return a data object if there's no data in it. Should THAT be fixed? I think it causes at least one problem in creopyson.

@adama2000
Copy link
Contributor Author

In python a none == false and an empty list also == false. If the return from Creoson is validated like this the result would be the same.

That may be true, but other languages like javascript and java treat those differently.

@adama2000
Copy link
Contributor Author

We're talking about 9 list functions here that return nothing -- if we made new versions of the same functions, then they'd need to be called something different... which feels cumbersome.

@adama2000
Copy link
Contributor Author

Dave and I discussed this, I'll be modifying the existing 9 list functions to return empty lists. I will also be modifying ALL the functions that return data to always return a "data" object even if it's empty.

@Zepmanbc
Copy link

Zepmanbc commented Feb 2, 2021

Thank you

@gazontimide
Copy link

This is great! I LOVE this tool and am very grateful for all the work you guys put into it to keep it updated and fix bugs!

@stekicar
Copy link

stekicar commented Feb 3, 2021

I am not programmer, just a regular user, but I think that emtpy list should be returned. I do not think it will break any existing codes because any code that is dependable on this data will run through empty list so no harm will be done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants