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

Clarify attribute names, or rename package ID #45

Closed
lg2de opened this issue May 15, 2020 · 8 comments
Closed

Clarify attribute names, or rename package ID #45

lg2de opened this issue May 15, 2020 · 8 comments
Milestone

Comments

@lg2de
Copy link
Contributor

lg2de commented May 15, 2020

You are going to release version 1.0. That's great!
But I would like to take the (last) chance to ask whether the naming of the attributes is "as good as possible".

I'm so far a bit confused about the many different versions.
Currently I'm using the UIFact because I want to have a thread with SynchronizationContext applied, even my use case in not a UI thread.

Could you please check again the names, e.g. by creating overview documentation when to use which version?

Finally a recommendation just from my point of view:

  • UIFact is not really for UI. There are more specific version with WpfFact and WinFormsFact.
  • This attribute could be named like one of the following
    • SCFact (synchronizaton context fact, very close to STAFact)
    • ContextFact (readable, but not fully qualified)

I'll update this list as soon I have new ideas. Maybe you have additional ideas!?

@AArnott
Copy link
Owner

AArnott commented May 16, 2020

Yes, I am preparing a 1.0 stable release. And you make a valid point about UIFact not really being UI specific. However, nearly everyone I've observed that deals with SynchronizationContext is also dealing with some UI framework, so it's accurate for that scenario, even though it is applicable more broadly than that. I'd rather not rename the attribute at this point because there are already over 100K downloads and I don't want to make upgrading more difficult than necessary.

As far as naming goes, I was most tempted to rename the package since hardly anyone is interested in StaFact actually -- they really want one of the other attributes that apply a SynchronizationContext. But that too, would probably disrupt more than help. I'm not sure. Maybe I'll rename and deprecate the original package on nuget.org so folks discover the new one.

@AArnott AArnott added this to the v1.0 milestone May 16, 2020
@lg2de
Copy link
Contributor Author

lg2de commented May 17, 2020

IF you EVER rename attributes and/or package, then NOW.

@AArnott
Copy link
Owner

AArnott commented May 17, 2020

@weltkante @RussKie @josetr @Serg046 @apobekiaris Do you have an opinion on the package ID? Should we keep it or rename it? Perhaps to UIFact.Xunit, since I think Xunit is now a reserved namespace on nuget.org. Or perhaps Nerdbank.XUnit.UIFact.

@AArnott AArnott changed the title Clearify attribute names Clarify attribute names, or rename package ID May 17, 2020
@weltkante
Copy link

Personally I don't have any issues with renaming things. Not speaking for WinForms repo owners but I can do the necessary changes there as well if it becomes necessary, doesn't look like its integrated into arcade infrastructure so should be straightforward to apply any renaming of package references or code.

@RussKie
Copy link
Contributor

RussKie commented May 17, 2020

Thank you for asking, but I don't have a strong opinion. We'll use whatever the name is (assuming you're not planning to delist old versions).

I don't think we use anything but WinForms* or STA* attributes, so don't have a strong opinion about UI* attributes either. Though following the logic laid out above, I'd go for a longer name SynchronizationContext* purely for descriptive reasons.

@AArnott
Copy link
Owner

AArnott commented May 17, 2020

The [UIFact] attribute does a little more than just set a SynchronizationContext. It also runs the test on an STA thread if on Windows.
I think I'll keep the names we have, but I'll improve the documentation on the package and attributes to better describe their features and behavior.

@AArnott
Copy link
Owner

AArnott commented May 17, 2020

Closed with 782b084.

@AArnott AArnott closed this as completed May 17, 2020
@lg2de
Copy link
Contributor Author

lg2de commented May 17, 2020

Would be great to have some documentation in README.md too, e.g. a table with the attributes and its primary intention.

@AArnott AArnott reopened this May 17, 2020
AArnott added a commit that referenced this issue Jan 5, 2023
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

4 participants