Improvements for classes

[Stephanevg]

Original discussion in #6015

I have the following few things that keep bugging me when I write classes and would would be great to seem them appear in a next version (or at least a few of them)

• Interface creation (Tracking Support interface declaration using classes #2223)
• Abstract classes
• Possibility to Override properties getters and setters (Tracking Properties with accessor and mutator methods #2219)
• Creation of static and non static nested classes
• Implementing comment based help in Classes
• Comment based help for Methods
• Remove the need to reload classes (Currently, when developing, one needs to kill the console, and reload the class to get the latest version. IT would make sense to have the same functionality as in functions: Just F5, and the old version of classes get overwritten by the new version, and we can use it immediatley).

[SteveL-MSFT]

cc @rjmholt if he wants to take on some of these

@Stephanevg thanks for opening this issue, I updated your description into checkboxes so we can track progress as the different items won't all be addressed at once.

[BrucePay]

@Stephanevg What do you mean when you say "Creation of static and non static internal classes". (I can think of a couple of interpretations but i'd like to hear what you're thinking.)

[KevinMarquette]

Here are some nice to have features

• The order of classes (with inheritance) should not matter when in a single file
  As a module author, I concat all my classes and functions into the psm1 at publishing time.
• The ability to create classes in a namespace or auto namespace based on module name.
• Use of default values or optional parameters in constructors
• A way to export classes from a module in a discoverable way
• Add option to mark class as hidden so using module does not expose or import them. (private classes)
• A Get-Class -Module type of command like Get-Command
• The ability to create a class based cmdlet in PowerShell

I want to ask for true private classes and members, but I am aware of why that does not work in PowerShell.

[SteveL-MSFT]

@Stephanevg @KevinMarquette it would be great if you can order your lists from highest priority to lowest priority

[Stephanevg]

@BrucePay The main need I have behind this one is to implement the Builder Pattern.

In my module RegardsCitoyensPS, some of the constructors I have build are simply HUGE, implementing the Builder patter would allow me reduce this.

I want to create a static internal class called Builder to whom I would delegate the mechanism of the creation of the Object. In the end, I will simplify the process of creation of an instance of my class for the engineers using my class.

Example

This is my use case:

Current -->

Class Depute{
    [int]$id
    [String]$Nom
    [String]$Prenom
    [Sexe]$Sexe
    [DateTime]$DateNaissance
    [String]$LieuNaissance
    [String]$Groupe
    [String]$NomCirconscription
    [int]$numcirco
    [int]$PlaceHemicylce
    [DateTime]$DebutDeMandat
    [String]$Profession
    [String]$Twitter
    [int]$NombreDeMandats
    [String]$partirattfinancier
    [Mandat[]]$autresmandats
    [String[]]$Collaborateurs
    [String[]]$Emails
 
}  

    Depute([int]$id,[String]$Nom,[String]$Prenom,[String]$Groupe,[DateTime]$DateNaissance,[String]$LieuNaissance,[Sexe]$Sexe,[string]$nomcirco,[int]$numcirco,[int]$PlaceHemicylce,[DateTime]$DebutDeMandat,[String]$Profession,[string]$Twitter,[int]$NbMandats,[string]$partirattfinancier,[Mandat[]]$autresmandats,[string[]]$Collaborateurs,[string[]]$Emails){
        $this.id = $id
        $this.Nom = $Nom
        $This.Prenom = $Prenom
        $This.Groupe = $Groupe
        $this.DateNaissance = $DateNaissance
        $this.LieuNaissance = $LieuNaissance
        $This.Sexe = $Sexe
        $this.NomCirconscription = $nomcirco
        $this.numcirco = $numcirco
        $this.PlaceHemicylce = $PlaceHemicylce
        $this.Profession = $Profession
        $This.Twitter = $Twitter
        $this.DebutDeMandat = $DebutDeMandat
        $this.NombreDeMandats = $NbMandats
        $this.partirattfinancier = $partirattfinancier
        $this.autresmandats = $autresmandats
        $this.Collaborateurs = $Collaborateurs
        $this.Emails = $Emails

    }
}

Ho I imagined implementing the Builder Pattern to solve this:

Class Depute{
    [int]$id
    [String]$Nom
    [String]$Prenom
    [Sexe]$Sexe
    [DateTime]$DateNaissance
    [String]$LieuNaissance
    [String]$Groupe
    [String]$NomCirconscription
    [int]$numcirco
    [int]$PlaceHemicylce
    [DateTime]$DebutDeMandat
    [String]$Profession
    [String]$Twitter
    [int]$NombreDeMandats
    [String]$partirattfinancier
    [Mandat[]]$autresmandats
    [String[]]$Collaborateurs
    [String[]]$Emails
 
  Hidden Depute([Builder]$Builder){
    $this.Id = $Builder.Id
    $this.Prenom = $Builder.Prenom
    $this.Nom = $Builder.Nom
     #etc...

  }

  Static Class Builder {
     [int]$id
     [String]$Nom
      [String]$Prenom
      [Sexe]$Sexe
      [DateTime]$DateNaissance
      [String]$LieuNaissance
      [String]$Groupe
      [String]$NomCirconscription
      [int]$numcirco
      [int]$PlaceHemicylce
      [DateTime]$DebutDeMandat
      [String]$Profession
      [String]$Twitter
      [int]$NombreDeMandats
      [String]$partirattfinancier
      [Mandat[]]$autresmandats
      [String[]]$Collaborateurs
      [String[]]$Emails
   
     [Builder] Id($Id){
      $This.id = $id
      return $this
     }
     [Builder] Nom($Nom){
       $this.Nom = $nom
       return $this
    }
   [Builder] Prenom($Prenom){
    $this.Prenom = $prenom 
    return $this
   }

   [Builder] Depute Groupe($Groupe){
      $This.Groupe = Groupe
       return $this
    }

   #etc... for every property.

   #The Build Method which actually would create the object
   [Depute] Depute Build(){
     
     Return [Depute]::New($This)

     }

}

Usage

In the end, I hope to reduce the complexity for the consumers of this class, and make the usage of a long constructor more straightforward and easier. The example above would result in something like this:

 [Depute]::New().Builder().Prenom("Emanuel").Nom("Macron").Groupe("LREM").Build()

That is how I imagined it.

Today, I managed to make it work using a static method that would call [Depute]::New() and methods in [Depute] to add the different properties and that return $this.

It works, but I actually liked the idea of having an internal class to attach functionality to it, and build my class through that Static class.

Is that what you had in mind @BrucePay ?

[Stephanevg]

@SteveL-MSFT done. To me, everything that would help us to simply the implementation of Design patterns should be highest prio. (Interfaces and Abstract Classes are the two main ones for me).

Adding help, is really secondary in my opinion, BUT really necessary.

[rjmholt]

@Stephanevg By internal here you mean a nested or inner class rather than an internal namepsace functionality? (I infer your primary language is French, just want to make sure I have the right idea)

[Stephanevg]

Also, There is another small pain I have with Classes, is how we have to load them.
As a lot of PowerShell users, for functions, I had a folder Private and Public, containing several .ps1 files. Each file, contained a function, which I dot sourced via the .psm1

This way of organizing an item per file is not possible using classes, since a Class must be the very first thing to be loaded. Which means, the very first line of a Script.

In the end, as @KevinMarquette mentionned, Either during Build all the Classes will be merged in one psm1 file, or they are all already in a single file during developement.

What I understood from the powershell team members present at psconf in Germany, is that this behaviour was really difficult to change.

I was hoping that that we could find a solution for this.

Maybe, a new property in a .psd1 file with a property like ClassFolderToLoad = @(.\Classes\Public\) which would automatically load the classes during each module load could be an idea?

But this is for me really a small small point. The main topics for me at the moment are Interface and Abstract classes.

[Stephanevg]

Hi @rjmholt

Oui, My first language is French ;)
and oui, you are correct. I meant nested / inner class, when I referred to Internal class. (I updated the first post mentionning Nested Classes instead of internal)

[KevinMarquette]

I updated the order on my list.

[SamPosh]

If all the mentioned things are added then is that not called C#?

[KevinMarquette]

If we add all the mentioned thing then is that not called C#?

We would like all the good class features that C# has, but allow us to do it in PowerShell. This is a valid request because calling out to PowerShell from C# is not near as easy as just writing PowerShell.