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

SourceAndConverter naming #72

Open
tischi opened this issue Jan 18, 2020 · 3 comments
Open

SourceAndConverter naming #72

tischi opened this issue Jan 18, 2020 · 3 comments
Assignees

Comments

@tischi
Copy link
Collaborator

tischi commented Jan 18, 2020

We still very often say Source where it is a SourceAndConverter:

image

I would be in favour of changing this to always saying SourceAndConverter or Sac, because otherwise one always needs to look into the code to see what it actually is.

However

  1. SourceAndConverter is quite a bit longer than Source, and
  2. @tpietzsch in bdv-core also often says Source instead of SourceAndConverter

Not sure...

@tischi
Copy link
Collaborator Author

tischi commented Jan 18, 2020

@NicoKiaru

@NicoKiaru
Copy link
Collaborator

NicoKiaru commented Jan 19, 2020

Let's put SourceAndConverter everywhere. Let's do that when we have managed to merge the manual registration and the projection modes.

@tpietzsch
Copy link
Member

@tischi @NicoKiaru In bdv-core, I have to use SourceAndConverter class name because of backwards compatibility. I mostly use source for variable and parameter names, because it's shorter. SourceAndConverter<?> is the canonical "source" object as far as BDV is concerned. Unfortunate class naming but well... Pure (unconverted) Source<?> are never added to the BDV, and a Source always is necessarily associated with a converter.

Following that reasoning, I think in downstream code (vistools etc) it is ok to use "Source" in class names when it is actually a SourceAndConverter. I actually would prefer it that way. It's only worth thinking about, when you actually have a mix of Source and SourceAndConverter in the API. If that is mostly not the case, I would stick with "Source" (and try to hide the Source from public API as much as possible).

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

No branches or pull requests

3 participants