Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
FEATURE: Deprecate
WorkspaceFinder
and introduce new API #5279FEATURE: Deprecate
WorkspaceFinder
and introduce new API #5279Changes from 1 commit
f15eabc
c0528e7
6a84332
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
todo discuss
find
vsget
here. The philosophy to use get was we dont find - eg filter - for anything.But when we want to use
find
to signal the the implementation is probably slow (at least uncached) then we should go with that.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would suggest not to use
find
=slow
andget
=fast
as a general concept, because it tries to change the meaning of those words.In this case we don't "find" any workspaces, we just get them all – at least that was my original reasoning :)
However we decide, some doc comment would be nice
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
iirc our convention is
Or in short: yes, we decided to go for get* for fast and find* for slow stuff and I'd rather stick to that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Im torn in between.
getContentGraph
for example also does one SQL query to get the currentContentStreamId, though its "get" there ... but im fine with either way.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I couldnt find discuss post to our find* vs get* philosophy but i found a few old artefacts regarding why
Node::getParent
was renamed toNode::findParent
in the old Neos world:and here #2202
or here #2202 (comment)
And in
findParent
we also definitely dont filter anything still it continues to be namedSubgraph::findParentNode
.Though there is one exception
Subgraph::findNodePath
was eventually renamed toSubgraph::retrieveNodePath
with #4090So it seems
retrieveParent
orretrieveWorkspaces
would also be possibly valid when starting out fresh.But for now for consistency i guess its a good idea to stick the 6year old philosophy and name it
findWorkspaces
instead (especially we could consider adding a filter later:)).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to avoid confusion: My point was that this kind of "magic meaning" makes sense for a single API, Content(Sub)Graph in this case. I would suggest not to adapt in in general if it leads to weird method names.
But I'm fine with either solution in this case!!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really find the distinction between
find*
andget*
hard to grasp, and keep track of. Internals might and can change such that the meaning of find/get is no longer correct, and we cannot change the public API according to our internals. I think this warrants discussion, as I struggled with this naming before as well...