That said, I'm iffy about tacking on a cross-cutting concern on the type. I can see it as more of an extension method rather being intrinsic to the type.
@IvenBach I might be misreading but the way I understood your code is that you are writing all those code for formatting different types in one big class/method.
and that means you have to do lot more than you should have to
which is why you're trying to find what type it is, etc. etc.
Should the formatter be changed for that? No. Only the string format needs to be changed while the formatter keeps does its job of assembling the output.
@this IMO a formatter that knows how to format any type, knows too many things. So either you need an InspectionResultFormatter : IClipboardFormatter + DeclarationFormatter : IClipboardFormatter + TestMethodFormatter : IClipboardFormatter and then take an IClipboardFormatter, or you make everyone implement IClipboardFormatter
I think having a set of dedicated classes that know how to format one specific thing, is the better approach here
@MathieuGuindon good. That said, it would be less of a problem had we implemented the stairway pattern, putting the interfaces in their own assemblies. Then we don't have to go "oh shoot" whenever we need to deal with a cross cutting concern.
Because we can't really use RD.JunkDrawer because of that, though I would definitely have had it go into a RD.Formatter assembly
> The current state contains a first redesign for annotation processing. That redesign still has quite some rough edges and I'll be changing it significantly to deal with the discrepancy in handling static and non-static information in annotations.
For that I'm going to split the current `IAnnotation` into an `IAnnotation` for dealing with the static information and a `ParseTreeAnnotation` combining an `IAnnotation` and the non-static information.
If I do a rebase on a sequence of that has commits before a merge, a merge, and commits after a merge does it thereafter essentially consider the merge as not existing?
@MathieuGuindon that's another thing I never really fully made up my mind. if we make our own theme, then we start look funny when Windows 11 comes out
OTOH, if we follow windows theme, we have to deal with silliness like icon clipping.
@IvenBach The generic was unnecessary because you used OfType<IExportable> on the enumerable at the only place it was used. After the cast, the gernaric type is completely irrelevent.
BTW, the actual formatting was in the individual classes all along because they all implement IExportable, which provides the ToClipboardString function.
@Vogel612 Ragardin your earlier question, VariableDescriptionAnnotation is both a member annotation and an attribute annotation, like DescriptionAnnotation.
well, we have Description -> ModuleDescription; we could have Attribute -> ModuleAttribute? "non-module" would be the ones without the word "module" in it?
> Version 2.4.1.4704 OS: Microsoft Windows NT 10.0.17763.0, x64 Host Product: Microsoft Office x86 Host Version: 16.0.11901.20218 Host Executable: EXCEL.EXE
**Description** A module in an add-in has the name "Foo". Adding a new module to a different project and attempting to rename gets a dialog warning that a module with that name already exists and proceeding may cause the sky to fall.
**To Reproduce** Steps to reproduce the behavior: 1. With 2 projects have a standard module in
@23fc9a62-56de-47fb-97b4-737890 be sure to make plenty of SO comments as 23f before you change, though, that way there are lots of random @23fc9a62-56de-47fb-97b4-737890 something, something... comments scattered about the site, but nobody named that anywhere!
VBA Rubberducking
VBA Rubberducking