You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We still very often say Source where it is a SourceAndConverter:
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
SourceAndConverter is quite a bit longer than Source, and
@tpietzsch in bdv-core also often says Source instead of SourceAndConverter
Not sure...
The text was updated successfully, but these errors were encountered:
@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).
We still very often say
Source
where it is aSourceAndConverter
:I would be in favour of changing this to always saying
SourceAndConverter
orSac
, because otherwise one always needs to look into the code to see what it actually is.However
SourceAndConverter
is quite a bit longer thanSource
, andbdv-core
also often saysSource
instead ofSourceAndConverter
Not sure...
The text was updated successfully, but these errors were encountered: