Closed adama2000 closed 3 years ago
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.
in my opinion, if error
is false, there should be a data
part.
empty data, like an empty data, is still data/information
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.
in my opinion, if
error
is false, there should be adata
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.
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.
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.
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.
Thank you
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!
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.
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?