-
Notifications
You must be signed in to change notification settings - Fork 472
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
Cannot inherit from SVGElement due to two internal abstract properties #1162
Comments
@wieslawsoltes - as you had added that code, can you please check if changing these methods to |
Looks like lines 314 and 316 also need to be protected (overrides for these two), after that all tests pass. |
I'll wait some time for @wieslawsoltes to give his opinion, otherwise I see no reason for not making that change. |
I guess we could make all properties & methods generated in AvailableElementsGenerator make protected so anyone can create manually new svg element classes not relying on generator. |
Sounds good to me, I'll see if I can get that in tonight. Thanks for the prompt answer! |
@sunyudai - are you still on it? |
Description
I am trying to extend SvgElement with the intent to create some project specific types that will still render to proper svg. However, I am running into an issue where I cannot inherit from SvgElement directly because it has two members that are marked as both internal and abstract. These properties are ClassNames and AttributeName.
Used Versions / issue location
Found when referencing the 3.4.7 NuGet package for a .NET Framework 4.8 project, but I can see the issue in the master branch at SVG/Generators/AvailableElementsGenerator.cs on lines 248 and 250.
Edit: historical note - these properties have been marked internal abstract since 2021, the initial creation of the file.
Next Steps
I'm happy to quickly change that and create a Pull request if that is preferred, I'm opening the issue because I'm not quite clear on if there is a reason why these two properties might be marked as internal abstract.
If these should not be changed to, say, protected virtual, then what would be a more appropriate class to derive from?
The text was updated successfully, but these errors were encountered: