Repository navigation
Future of Add-Type #5725
Description
Activity
Add-Typewas a big change to dotnetcore so I'm personally ok with not maintaining strict compatibility for legacy features that people don't use (with sufficient data).Ideally, we should use dynamic parameters per language.
I think adding a
-CompileOnlyswitch would be useful.Please do add FSharp.
Current versions of FSharp.Compiler.Codedom seem to be broken relative to incorrect version of FSharp.Core -- and no amount of installing packages for various versions had helped me -- or asking on FSharp Slack.
Whose problem would this be? Where should it be reported?
(I think it is stuck half-way between PowerShell & FSharp with no one to care.Reacted by unuunc, Brian Lalonde, FoggyFinder, endowdly, Nikon the Third and queilHerb Martin (@HerbM) Thanks for your feedback. I like this too. But I don't found FSharp classes in Roslyn repo. It seems it is a separate project. So my current plan is to remove a regression and add VisualBasic support. After that we could research in depth how add FSharp support.
Should we support creation new assembly without loading? Currently we always load created assembly, even with -Passthru
One correction:
-PassThrureturns the types that were added byAdd-Type, so the assembly has to be loaded when it's specified.Would it be possible to add PowerShell as a language to overcome the limitation link to the PowerShell's keyword Class?
LMA1980 <aka ichiskaar> (@LMA1980) Could you add more information about your request?
Powershell now have the keyword class and enum. When using that method it allow to quickly generate simple class or even extend other classes.
class MyClass { [string] myProperty; [int] anotherProperty; MyClass() { #...do something - this is a constructor... } MyClass([PSCustomObject] $object) { #... do something using a PSCustomObject as source ... } }Now the issue with such definition, they are only accessible to their Scope and currently they cannot be exported like a Function or a Cmdlet. (https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_classes?view=powershell-5)
With Add-Type -language PowerShell ... This would open up new capability without requiring wrapper like New-MyClass function solution to instanciate such object from outside of a Module scope.
LMA1980 <aka ichiskaar> (@LMA1980) Thanks for clarify! It seems we have already such request (related with Import-Module). I couldn't find a quick the Issue.
Current version of Add-Type cmdlet is partially ported on Roslyn from Dom. It is large breaking change. It is true for most of the parameters. Some parameters was related to Dom and was removed. Some parameters don't implemented. In fact, we already have a new cmdlet.
Before I push new enhancements I want discuss a few points. We could remove old things.
LanguageShould we keep JScript for backward compatibility?
Should we add FSharp for future?
Should we keep CSharpVersion1, CSharpVersion2 and so on? If yes should we add VisualBasicVersion9 and so on? Could we leave only CSharp and VisualBasic in the enum? Why anybody can want to use CSharpVersion1 in PowerShell?! I found nothing on GitHub - I think we should old elements.
Currently I have to add language family type with CSharp and VisualBasic internally. So I'd prefer simplify
public enum Languageand don't use the new type and helper functions to translate these types.How we can better expose the options? Generic or by language? The question related with previous one - with options we can specify the language version. We could Roslyn generic classes but they are not convenient to work in PowerShell. I have no conclusion.
-Passthrou. I think we could add-CompileOnlyswitch./cc Steve Lee (@SteveL-MSFT) Dongbo Wang (@daxian-dbw)