Powershell: New feature: decorate function with function

[p0W3RH311]

its possible to add this feature because is powerful technique for example...

$user = @{name='mee'; access='guest'}

function make-secure {   
      if($user.access -eq 'admin') {
         return $\.value  
       }
      else {
        return "try again :)"
       }
}

function  Get-Admin  : make-secure {
     return 'pass' 
}

PS >> Get-admin
try again :)

PS >> $user.access = 'admin'  
PS >> Get-Admin 
pass

$\ is a hashtable and contains the name of the caller function and the data returned by caller function

NAME        VALUE
----       ------
Get-Admin   'pass'

in this example function 'make-secure' change the bahaviour to the function Get-Admin without modifyng get-admin

function Get-Admin : make-secure {
   .....
........
}

inside make-secure function i use new variable $\ its contains metadata of caller function ex: name, value returned,...etc

[iSazonov]

I think it is an area for PowerShell classes.
/cc @rjmholt for conclusion.

[rjmholt]

I think it is an area for PowerShell classes.

Actually this wouldn't involve classes at all. Python has an established decorator concept, but an important note is that they rely on closures. PowerShell uses dynamic scope and therefore doesn't naturally have closures (it's possible to make one, but it's really not normal language semantics for us). That might not be an issue, but the motivating example assumes closure-like semantics, which don't apply to PowerShell. It could be made to work as intended (where the user table is private to the end caller) with script/module scope though.

I think the proposed syntax is too conflated with the class inheritance syntax, and we'd be better off using an attribute or similar (that's what Python's @<name> syntax is).

But my experience with Python decorators is that while they look cool, they don't get all that much use in practice, mainly because they're complex and there are plenty of good alternatives. I think if we can find a strong motivator for decorators we should definitely consider them, but we need a strong case before we build a new language syntax or feature like this.

[iSazonov]

I close this until we get important business scenario for the feature.

[msftbot[bot]]

This issue has been marked as answered and has not had any activity for 1 day. It has been closed for housekeeping purposes.