$Pscx strongly typed

Topics: Developer Forum
Sep 12, 2007 at 12:36 PM
I got some spare time now, between projects, so I thought I'd fix some issues that are assigned to me :)
BTW I like the new $Pscx object, but I was thinking, would you like making it strongly typed? That way the cmdlets could use it more easily, they could even hide the implementation details using internal properties (eg of set-location stack) and the nasty initialization in Profile.ps1 could be removed...
Sep 12, 2007 at 3:57 PM
I'd vote for that ...
Sep 12, 2007 at 4:40 PM
hi jachym (welcome back, again!)

Myself and Keith talked about this, but not to the extent of making it a full managed class. Do we really need that? Script-only contributors are kinda forced then to ask a dev to code up a new property when they need it. Keeping it a PSObject with ScriptProperties gives us most benefits (tab completion, auto format etc). MoW's $powertabconfig works quite well, although he uses a datatable internally. If we did need some managed functionality, we have CodeMethods etc.

My 0.02 cents
Sep 12, 2007 at 6:38 PM
Well you can add-member on an object of type PscxContext, very much the same like on a PSCustomObject. But you could more easily use this strongly typed object from cmdlets. For example, I am thinking about rewriting the *-Path scripts in BurtHarris branch as cmdlets, among with a "environment stack". It would remember changes to the process environment block and powershell session state, and allow for applying/reverting of them. Another usage of this private runspace-bound storage could be the cd+ cd- directory stack, or the Job object storage in the hypotetical job provider.

I shelved the propsed changes in my PscxContext shelveset.
Sep 15, 2007 at 7:11 PM
Actually this might solve a problem I hadn't fixed yet with the new $Pscx object - the Preferences attribute has not been modified to work with the new $Pscx.Preferences hash table. One the hand, it was nice that the definition of $Pscx was not hidden however as long as I can easily create/use $Pscx.Session hashtable entries from what scripts we have, then I'm OK with this change. Even script devs need to contact someone else to drop in a new preference entry, hopefully the entire $Pscx variable definition can be done in a single file - making it easy for someone to add an entry to.
Sep 16, 2007 at 6:10 AM
Just thought of another benefit to Jachym's approach. A user could completely blow off using the PSCX profile but then want to use a PSCX dot sourced function or Script that relies on having access to $Pscx.Session. By having this in the Snapin, it will always be available.
Sep 16, 2007 at 6:12 AM
Oh yeah, my only request is the we keep the resulting PowerShell global variable name short i.e $Pscx (not $PscxContext).
Sep 19, 2007 at 1:32 PM
At the moment, the $Pscx variable is created from the profile script. I was thinking, we could transform the Start-TabExpansion into a Start-Pscx command, which would create these "hardwired" initialization tasks.

Plus, of course, PscxCmdlet.Context will create the variable lazily, if not already present.
Sep 19, 2007 at 2:38 PM
Can the pscx snapin contain initialisation code? I wonder if we can completely avoid the profile? :D
Sep 20, 2007 at 9:06 PM
Only thing which is called on Add-PSSnapIn is DriveCmdletProvider.InitializeDefaultDrives(), as far as I know. I think the lazy initialization won't be as hacky.
Sep 22, 2007 at 9:55 PM
Edited Sep 22, 2007 at 9:56 PM
Hmm then I guess we will need to do it in the profile because I need to be able to access stuff from $Pscx like $Pscx.Version and $Pscx.Home without necessarily having used a PSCX cmdlet or provider. I like the idea of a single cmdlet like Start-Pscx that initializes $Pscx, tab-completion and other features as dictated by a configuration file?