Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Type inference for Select-Object, Group-Object, PSObject and Hashtable #7231

Merged
merged 5 commits into from
Sep 19, 2018

Conversation

powercode
Copy link
Collaborator

@powercode powercode commented Jul 3, 2018

PR Summary

Fixes #7230.

Adding the concept of a PSSyntheticTypeName, derived from PSTypeName,
that extends it with a list of synthetic members.

This allows us to express the inferred type of

[pscustomobject] @{
   A = 1
   B = "2"
}

as a "PSObject#A:B" and with information about the types of A and B.

This is also used to annotate the output of

Select-Object -Property
Select-Object -ExcludeProperty
Select-Object -ExpandProperty

Finally, it adds information about the types of the
Group and Value properties of the output of Group-Object

PR Checklist

…rred types

This reduces allocations and makes the code easier to debug.
@powercode powercode force-pushed the selectinfer branch 2 times, most recently from da09520 to b0f840e Compare July 3, 2018 23:42
@powercode
Copy link
Collaborator Author

I don't intend to fix the remaining CodeFactor issues.

Adding the concept of a PSSyntheticTypeName, derived from PSTypeName,
that extends it with a list of synthetic members.

This allows us to express the inferred type of

[pscustomobject] @{
   A = 1
   B  = "2"
}

as a "PSObject#A:B" and with information about the types of A and B.

This is also used to annotate the output of
Select-Object -Property
Select-Object -ExcludeProperty
Select-Object -ExpandProperty

Finally, it adds information about the types of the
Group and Value properties of the output of Group-Object
@powercode
Copy link
Collaborator Author

Ping

@daxian-dbw
Copy link
Member

Sorry for delaying so long. Will review in a day or two.

@TravisEz13
Copy link
Member

@powercode, @daxian-dbw is on vacation

Copy link
Member

@daxian-dbw daxian-dbw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for being late on the code review. Left a few comments.

@powercode
Copy link
Collaborator Author

@daxian-dbw Thanks for your review! Very constructive as usual!

Copy link
Member

@daxian-dbw daxian-dbw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Left two non-blocking comments.
@powercode Thanks for the great contribution, again!

Copy link
Member

@daxian-dbw daxian-dbw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for addressing the non-blocking comments!

Copy link
Collaborator

@BrucePay BrucePay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are a few little things that we can change later. Otherwise it looks OK to me.

}
}

private static bool IsPSTypeName(PSMemberNameAndType member) => string.Compare("PSTypeName", member.Name, StringComparison.CurrentCultureIgnoreCase) == 0;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not use string.Equals() here? It's faster than string.Compare().


foreach (var propertyName in properties)
{
if (string.Compare(name, propertyName, StringComparison.CurrentCultureIgnoreCase) == 0)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again - should use string.Equals()

/// </summary>
/// <param name="name">The name of the type.</param>
/// <param name="type">The real type.</param>
internal PSTypeName(string name, Type type)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like it should be public but we can do that in a future PR.

return;
if (astParameterArgumentPair is AstPair astPair)
{
object ToWildCardOrString(string value) => WildcardPattern.ContainsWildcardCharacters(value) ? (object)new WildcardPattern(value) : value;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider using PSPropertyExpression - it already handles wildcards in property names.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe even use the ParameterProcessor? So we can handle hashtable arguments also?
I'll leave that to a future PR.

@TravisEz13 TravisEz13 added Review - Committee The PR/Issue needs a review from the PowerShell Committee WG-Engine core PowerShell engine, interpreter, and runtime labels Sep 13, 2018
@TravisEz13
Copy link
Member

Add Committee review for new public interface

@SteveL-MSFT SteveL-MSFT added Committee-Reviewed PS-Committee has reviewed this and made a decision and removed Review - Committee The PR/Issue needs a review from the PowerShell Committee labels Sep 19, 2018
@SteveL-MSFT
Copy link
Member

SteveL-MSFT commented Sep 19, 2018

@PowerShell/powershell-committee reviewed the public constructor for PSTypeName and likes the proposal

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Committee-Reviewed PS-Committee has reviewed this and made a decision WG-Engine core PowerShell engine, interpreter, and runtime
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add type inference for PSObject and Hashtable
5 participants