| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
Hi Staffan Gustafsson (@powercode), I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution! The agreement was validated by Microsoft and real humans are currently evaluating your PR. TTYL, MSBOT; |
Sorry, something went wrong.
There was a problem hiding this comment.
Hemant Mahawar (@HemantMahawar) should we have copyright preamble on the new files?
Sorry, something went wrong.
There was a problem hiding this comment.
Given it is open-source code, I don't think it is needed. Joey Aiello (@joeyaiello) Can you weigh in?
Sorry, something went wrong.
There was a problem hiding this comment.
removing
Sorry, something went wrong.
There was a problem hiding this comment.
Please, avoid copy-paste
Sorry, something went wrong.
There was a problem hiding this comment.
That's probably not needed
Sorry, something went wrong.
There was a problem hiding this comment.
removed
Sorry, something went wrong.
There was a problem hiding this comment.
This method is copied from
Can we avoid such copy-paste?
Sorry, something went wrong.
There was a problem hiding this comment.
I really agree, but I actually think it would be a good Idea to provide these kind of helpers in a public API. This needs to be done by everyone who wants to handle Path and LiteralPath.
What is the right way to go here?
See #2729
Sorry, something went wrong.
There was a problem hiding this comment.
Do we use this pattern of sharing the backing store for parameters elsewhere? If not, it seems like potentially a bad idea to start doing this.
One maybe non-issue is the parameter binder copies all parameters in the cmdlet instance before parameter binding and restores them. It seems unlikely, but possible, that a non-null value in Path could cause problems.
Sorry, something went wrong.
There was a problem hiding this comment.
A quick search gives that the pattern is in
AclCommands.cs CertificateCommands.cs CSVCommands.cs ExportAliasCommand.cs MatchString.cs Out-File.cs SaveHelpCommand.cs SignatureCommands.cs StartTranscriptCmdlet.cs UpdateHelpCommand.cs WriteFormatDataCommand.cs XmlCommands.cs
But the cost of changing is very small.
Sorry, something went wrong.
There was a problem hiding this comment.
I changed it to
get { return _isLiteralPath ? Path : null; }
Sorry, something went wrong.
There was a problem hiding this comment.
Shouldn't ValueFromPipeline be on LiteralPath?
Sorry, something went wrong.
There was a problem hiding this comment.
Corrected.
Sorry, something went wrong.
There was a problem hiding this comment.
I realize this is just a translation of the PowerShell, but it seems overly fancy. I think it would be clearer if the caller just passed errorId, it would make searching for the error string easier too.
Sorry, something went wrong.
There was a problem hiding this comment.
corrected.
Rebased version pushed.
Sorry, something went wrong.
There was a problem hiding this comment.
I realize this is just a translation of the PowerShell implementation, but a psd1 can contain much more than a simple hashtable. For example, the psd1 file contain 2 hashtables as an array, and this implementation would ignore the second one.
As implemented, the cmdlet is mostly useful for typical module manifests, but psd1 files are used for other things, e.g. localization, and sometimes use commands like ConvertFrom-StringData.
We should, as a minimum, not ignore any part of the ast.
We should also consider supporting more than a simple hashtable. Ast.SafeGetValue can certainly handle more (e.g. an array of hashtables).
We might also consider doing something more like what Import-LocalizedData does, though we'd need feedback from Lee Holmes (@LeeHolmes) to understand the important differences and why this cmdlet was introduced.
Sorry, something went wrong.
There was a problem hiding this comment.
Should we start with just the move as descripted in the issue, and open a new issue for the functional changes?
Sorry, something went wrong.
There was a problem hiding this comment.
+1 don't block the PR and open new Issue.
Sorry, something went wrong.
|
Jason Shirk (@lzybkr) and sergei (@vors) Are your concerns resolved or is there additional work left here? |
Sorry, something went wrong.
| [Parameter(Mandatory = true, Position = 0, ParameterSetName = "ByPath")] | ||
| [ValidateNotNullOrEmpty] | ||
| [SuppressMessage("Microsoft.Performance", "CA1819:PropertiesShouldNotReturnArrays")] | ||
| public string[] Path { get; set; } |
There was a problem hiding this comment.
We don't need a change as this code is just following a somewhat broken pattern.
If LiteralPath was set, _isLiteralPath will be set to true. Then, if Path is set, _isLiteralPath is not cleared. This isn't really a scenario I guess, but it is handled correctly in some places in our code base, but in many others it is not.
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Fixes #2734