forked from MatiasNAmendola/SharpDevelop
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathTODOnewNR.txt
212 lines (155 loc) · 10.7 KB
/
TODOnewNR.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
Commented code, needs to be ported and re-enabled:
ParseProjectContent
Class Browser (removed from source tree; to be reimplemented using WPF)
NRefactoryLanguageConverter
Context Actions (EditorContext etc.)
RefactoringService
FindReferencesAndRenameHelper
NamespaceRefactoringService
RefactoringMenuBuilder
TaskService.UpdateCommentTags
CodeManipulation.cs (btw, I think this doesn't belong into AvalonEdit.AddIn - more a job for a language binding)
--> See TODO-list on Google Docs
Important features (self-hosting):
Ctrl+Space Completion
ctor snippet
Rename refactoring
Run unit test from icon bar margin
"Add using" context action (and other resolve error MD context actions)
ILSpy-AddIn
Stuff that was renamed/moved:
ICSharpCode.SharpDevelop.Dom -> the type system and resolvers now are part of ICSharpCode.NRefactory
IDocument -> moved to ICSharpCode.NRefactory.Editor
IClass -> ITypeDefinition
ICompilationUnit -> IUnresolvedFile
ITextBuffer -> ITextSource (in ICSharpCode.NRefactory.Editor)
IReturnType -> ITypeReference (unresolved) or IType (resolved)
Location -> TextLocation in ICSharpCode.NRefactory
TextLocation -> moved to ICSharpCode.NRefactory
Functionality changes:
SharpDevelop.Dom was replaced by NRefactory 5:
Apart from plenty of API changes, there are also a couple of architectural changes
to look out for.
Most importantly, the type system has been split up into an unresolved and a resolved
version. When porting code using SD.Dom, be careful which one of the two you choose.
If possible, try to avoid using the unresolved type system. The planned observable code model
(will be implemented for the 5.0 class browser) might be a better alternative in some cases.
Features related to the type system / refactorings should probably wait for this code model
before they are ported to 5.0.
NRefactory 5 introduction: http://www.codeproject.com/Articles/408663/Using-NRefactory-for-analyzing-Csharp-code
Static services replaced with interfaces:
To make writing unit tests easier, the static services in SharpDevelop are getting
replaced with interfaces. The class "SD" has static properties to get references
to the services, so the call "ResourceService.GetString()" becomes "SD.ResourceService.GetString()".
In unit tests, Rhino.Mocks can be used to easily create mocks of the services:
SD.InitializeForUnitTests(); // initialize container and remove services from previous test cases
SD.Services.AddService(typeof(IParserService), MockRepository.GenerateStrictMock<IParserService>());
SD.ParserService.Stub(p => p.GetCachedParseInformation(textEditor.FileName)).Return(parseInfo);
SD.ParserService.Stub(p => p.GetCompilationForFile(textEditor.FileName)).Return(compilation);
It is possible to define a service interface in ICSharpCode.SharpDevelop.dll and have the implementation
somewhere else (SD will find it using the AddInTree).
This allows for AddIns to consume each other's functionality (e.g. debugger accessing the decompiler service)
without having to define a custom AddIn tree path.
The long-term goal is to have only interfaces and helper classes in ICSharpCode.SharpDevelop.dll (the API for AddIns)
and have the implementation details in SharpDevelop.exe (which AddIns aren't supposed to reference).
ICSharpCode.Core.WinForms hidden behind service interfaces:
This is an extension of the previous point.
The whole assembly ICSharpCode.Core.WinForms still exists and has the old static services,
which makes porting old AddIns a bit easier.
However, it should no longer be used in new code and AddIns should get rid of the reference
to ICSharpCode.Core.WinForms if possible.
The services in SD.WinForms provide the same functionality.
Namespaces in ICSharpCode.SharpDevelop reorganized:
I'm currently moving types around in ICSharpCode.SharpDevelop, so you'll have to update
plenty of usings.
The idea behind the new namespaces is that grouping the code into 'Gui' and 'Services'
isn't very useful; so I'm getting rid of those namespaces and the old folder structure,
and re-group the types into feature areas.
Within the ICSharpCode.SharpDevelop project, the 'Src' folder contains the old code
that hasn't been cleaned up yet and may still be in an old namespace.
When I'm done cleaning up a code file, I'm moving to out of the 'Src' folder into one of
the new folders corresponding to the new namespace.
As part of this cleanup, I'm also replacing static services with service interfaces (see above).
AddInTree paths reorganized
Plenty of AddIn tree paths have been changed to better match the new namespace structure.
I used a global replace operation for renaming paths; so AddIns that are in the SharpDevelop
repository but not in the SharpDevelop solution (because they haven't been ported yet)
have been adjusted as well.
SD.MainThread:
The new best way to invoke a call on the main thread is:
SD.MainThread.InvokeAsync(delegate { ... }).FireAndForget();
Note that InvokeAsync returns a Task (like all .NET 4.5 *Async APIs). If any exceptions occur while
executing the delegate, they will get stored in the task object. This can cause the exception to get
silently ignored if the task object isn't used later. The "FireAndForget()" extension method solves
this problem by reporting any (future) errors to the message service.
It is also often possible to avoid explicit thread switches alltogether by using the C# 5 async/await feature.
ICSharpCode.Core.ICommand replaced with WPF ICommand
New menu commands should derive from 'SimpleCommand' instead of 'AbstractMenuCommand'.
If 'IsEnabled'-handling is required, new commands should just implement ICommand directly without using any base class.
The old class AbstractMenuCommand still exist and simulates the old API, which makes porting AddIns a bit easier.
I'm thinking about writing a tool that automatically ports AbstractMenuCommand-derived classes to SimpleCommand,
so you don't need to bother updating your commands manually.
SD.PropertyService:
The Get()/Set() methods no longer support nested Properties objects or lists of elements -
you will need to use the new dedicated GetList()/SetList()/NestedProperties() methods for that.
The Get() method no longer causes the default value to be stored in the container; and GetList()
results in a read-only list - an explicit SetList() call is required to store the resulting value again.
However, a nested properties container still is connected with its parent, and any changes done
to the nested container will get saves without having to call the SetNestedProperties() method.
The property service now uses XAML serialization instead of XML serialization. This might require
some changes to your classes to ensure they get serialized correctly, for example
you need to use public properties instead of public fields.
SD.ParserService:
The result of a parser run (ParseInformation) now may contain a fully parsed AST.
The ParserService may cache such full ASTs, but may also drop them from memory at any time.
This will be implemented by keeping the last N accessed files in the cache. (currently we just keep the caches around forever)
Every parse information also contains an IUnresolvedFile instance with the type system information.
The IUnresolvedFile is stored permanently (both in ParserService and in the IProjectContents).
Solution model:
The class 'Solution' has been replaced with the interface 'ISolution'.
The static events that report changes to the solution (e.g. project added) no longer exist on IProjectService;
instead the ISolution.Projects collection itself has a changed event.
Text editor and document services:
In SharpDevelop 4.x it was possible to use IDocument.GetService(typeof(ITextEditor)) to find the
editor that presents the document.
This is no longer possible in SharpDevelop 5, as the same IDocument may be used by
multiple editors (e.g. split view).
ITextEditor and IDocument now use separate service containers.
ITextEditor.GetService() will also return document services, but not the other way around.
The attributes [DocumentService] and [TextEditorService] are used to mark the service interfaces
that are available in the document and in the editor respectively.
The attributes exist purely for documentation, and some services may not use them
(for example the service interfaces defined in AvalonEdit, where the attributes aren't referenced).
View content services:
Instead of casting a view content to an interface "var x = viewContent as IEditable;",
code should use the viewContent.GetService() method.
This allows the view content implementation to be flexible where the interface is implemented,
it no longer is necessary to implement everything in the same class.
Interfaces that are supposed to be used as view content services are marked with the
[ViewContentService] attribute.
In the case of the AvalonEditViewContent, all text editor and document services are
also available via IViewContent.GetService().
If split view is in use, the view content will return the services from the editor that has the focus.
XML Forms:
Classic .xfrm still exists and can be used in SD 5.0.
However XML forms support should be considered a temporary feature for making AddIns easier to port,
we still plan to get rid of all .xfrms and the associated infrastructure by the time SD 5.0 ships.
Simply porting an .xfrm to a regular WinForms control with InitializeComponents() is acceptable,
but porting it to WPF is preferred.
What wasn't changed:
SD-1234 still makes implementing view contents difficult by preventing them from loading/saving
files when they want to. I'd like to fix this, but this likely won't fit into 5.0 and will have to wait for 5.1.
The IProject/ProjectItem model is mostly unchanged and still does not provide proper change notifications
(apart from those in the static ProjectService).
Lacking a good project model, we also haven't started moving the project browser to WPF.
This is a major refactoring on top of the already existing major changes in 5.0, so it doesn't fit.
But it's definitely a goal for 5.1.
Context Actions vs. Member Context Menu:
Members context menu should include refactoring options that can be applied from the outside,
for example in the classes pad when the code file isn't open.
Refactorings that don't make sense without opening the file shouldn't be in the member menu.
The context actions menu should show all refactorings (even those that are also in the members context menu).
Automatic Translation:
WorkbenchSingleton.AssertMainThread() -> SD.MainThread.VerifyAccess()
AbstractMenuCommand-derived classes that do not override IsEnabled -> SimpleCommand