{"action":"created","issue":{"url":"https://api.github.com/repos/PowerShell/PowerShell/issues/2226","repository_url":"https://api.github.com/repos/PowerShell/PowerShell","labels_url":"https://api.github.com/repos/PowerShell/PowerShell/issues/2226/labels{/name}","comments_url":"https://api.github.com/repos/PowerShell/PowerShell/issues/2226/comments","events_url":"https://api.github.com/repos/PowerShell/PowerShell/issues/2226/events","html_url":"https://github.com/PowerShell/PowerShell/issues/2226","id":176141243,"number":2226,"title":"Add support for extension methods (LINQ)","user":{"login":"vors","id":816680,"avatar_url":"https://avatars0.githubusercontent.com/u/816680?v=4","gravatar_id":"","url":"https://api.github.com/users/vors","html_url":"https://github.com/vors","followers_url":"https://api.github.com/users/vors/followers","following_url":"https://api.github.com/users/vors/following{/other_user}","gists_url":"https://api.github.com/users/vors/gists{/gist_id}","starred_url":"https://api.github.com/users/vors/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/vors/subscriptions","organizations_url":"https://api.github.com/users/vors/orgs","repos_url":"https://api.github.com/users/vors/repos","events_url":"https://api.github.com/users/vors/events{/privacy}","received_events_url":"https://api.github.com/users/vors/received_events","type":"User","site_admin":false},"labels":[{"id":401720878,"url":"https://api.github.com/repos/PowerShell/PowerShell/labels/Area-Language","name":"Area-Language","color":"5319e7","default":false},{"id":311043050,"url":"https://api.github.com/repos/PowerShell/PowerShell/labels/Issue-Enhancement","name":"Issue-Enhancement","color":"fc2929","default":false},{"id":401721267,"url":"https://api.github.com/repos/PowerShell/PowerShell/labels/Up-for-Grabs","name":"Up-for-Grabs","color":"000000","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":7,"created_at":"2016-09-10T00:16:56Z","updated_at":"2018-05-02T21:49:11Z","closed_at":null,"author_association":"COLLABORATOR","body":"Copied from TFS item 819298\n\nOriginal Connect item: https://connect.microsoft.com/PowerShell/feedback/details/635454/add-support-for-linq\n\n> When LINQ is available, it can push queries into the native language of the underlying storage without requiring users to learn that query language.  This transformation can speed up queries to perform hundreds times faster, and when the alternative is to ship large amounts of data over the wire to be filtered locally, thousands of times faster.\n> \n> In many cases using LINQ can convert a script which ran so slow as to be infeasible into scripts that we can run every day, and in fact, can run whenever we like -- and it also drastically reduces CPU impact.\n> \n> For a trivial example, see this post on Stack Overflow http://stackoverflow.com/questions/4559233/technique-for-selectively-formatting-data-in-a-powershell-pipeline-and-output-as where the switch to using LINQ (by embedded the LINQ into a C# function via Add-Type and calling it from PowerShell) provided 1000 times speedup.  It's currently not possible to write that LINQ query at all in pure PowerShell, and the alternative (as it was written in the other answer on that StackOverflow question, using Where-Object) is extremely slow even on modest data sets.\n> \n> The bottom line is that the Where-Object and Select-Object cmdlets are very slow, and using them to query databases, and other remote systems results in not only the slowdown of processing thousands of items in a Where-Object, but potentially sending them all over the wire as well.  \n> \n> Since LINQ to events is becoming available through the Rx project, it's more useful, and more important than ever, and we really need a way to write LINQ natively in PowerShell.\n"},"comment":{"url":"https://api.github.com/repos/PowerShell/PowerShell/issues/comments/386132396","html_url":"https://github.com/PowerShell/PowerShell/issues/2226#issuecomment-386132396","issue_url":"https://api.github.com/repos/PowerShell/PowerShell/issues/2226","id":386132396,"user":{"login":"mklement0","id":588825,"avatar_url":"https://avatars2.githubusercontent.com/u/588825?v=4","gravatar_id":"","url":"https://api.github.com/users/mklement0","html_url":"https://github.com/mklement0","followers_url":"https://api.github.com/users/mklement0/followers","following_url":"https://api.github.com/users/mklement0/following{/other_user}","gists_url":"https://api.github.com/users/mklement0/gists{/gist_id}","starred_url":"https://api.github.com/users/mklement0/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mklement0/subscriptions","organizations_url":"https://api.github.com/users/mklement0/orgs","repos_url":"https://api.github.com/users/mklement0/repos","events_url":"https://api.github.com/users/mklement0/events{/privacy}","received_events_url":"https://api.github.com/users/mklement0/received_events","type":"User","site_admin":false},"created_at":"2018-05-02T21:49:11Z","updated_at":"2018-05-02T21:49:11Z","author_association":"CONTRIBUTOR","body":"@BrucePay:\r\n\r\n> I really don't understand where you got this idea from.\r\n\r\nTo be clear: only _you_ can provide behind-the-scenes glimpses - both historical and present - and I always appreciate them.\r\n\r\nBy contrast, I can only talk about de-facto behavior and _guess_ at design intent in cases where it it isn't documented.\r\n\r\n---\r\n\r\n> It has never been the case that we relied only on cmdlets.\r\n\r\n_De facto_, virtually all of PowerShell's _own_ functionality is provided by cmdlets and operators (with the exception of the useful, but little-known and little-used `.ForEach()` and `.Where()` collection \"operator\" methods that [I wish had true operator representation](https://github.com/PowerShell/PowerShell-RFC/pull/126).)\r\n\r\n_Whether that was the original intent or not_, the following de-facto separation makes sense and is worth keeping:\r\n\r\n* Cover _basic_ needs with PowerShell's _own_ constructs - cmdlets and operators - whose syntax - while spanning two distinct parsing modes - doesn't _clash_:\r\n\r\n   * _Cmdlets_ return are high-level, shell-syntax-friendly analogs to OO methods (loosely speaking).\r\n   * Objects returned by them are _typically_ treated as \"property bags\" in basic command-line/scripting scenarios, meaning that only _property_ access is needed.\r\n   * Objects and their properties can be acted on with _operators_ in the context of expressions, without causing _fundamental_ confusion (see below).\r\n\r\n* For _advanced_ needs, provide full access to the .NET framework is _available_, which is a wonderful _option_ to have and sets PowerShell apart from traditional shells; however, this option comes at a cost:\r\n\r\n   * You need to know more about the underlying .NET types and what methods they expose.\r\n        * While `Get-Member` helps in discovering method _signatures_, with respect to getting _help_ you're on your own.\r\n\r\n   * You need to know the subtleties of parameter binding when calling .NET methods directly.\r\n\r\n   * Last not least, you need to be aware of how method syntax differs from command syntax.\r\n\r\n**It therefore makes sense to limit introduction of new PowerShell-native features to cmdlets and operators.**\r\n\r\n> simple example: getting the substring of a string.\r\n\r\nGetting a substring via the `.Substring()` _method_ is actually a good example of something that is _rarely_ needed: due to PowerShell's OO nature and its excellent regex support via `-split`, `-match`, and `-regex` you typically do _not_ need to deal with `.Substring()`.\r\n\r\n---\r\n\r\n> What do you mean by \"resembling\" here? \r\n\r\nUnderstanding PowerShell's two fundamental parsing modes - argument mode vs. expression mode - is a challenge any PowerShell user faces, but it's the unavoidable price to pay for a shell that also offers the constructs of a  \"real\" programming language (again, kudos to PowerShell).\r\n\r\nSo, yes, operators belong to the real of _expressions_, where string literals cannot be barewords (unquoted), for instance.\r\n\r\nAside from that, however, operators being separated from their operands by _whitespace_ (rather than `(...)` and `,` - though `,` has a role in some operators too) is what I meant by \"resembling\" argument mode.  \r\nA negative way of phrasing it: Using literals (quoting need aside) and variable access - including _property_ access on variables - _doesn't clash_ with argument-mode syntax the way that _method_ calls do.\r\n\r\n```powershell\r\n$arr = 'Call', 'me',  'Ishmael'\r\n\r\n# Operator syntax - reminiscent of argument mode (whitespace as separator, no (...))\r\n$arr -join ' '\r\n\r\n# Method syntax - uses (...) and \",\" - both of which function differently in argument mode.\r\n[string]::Join(' ', $arr)\r\n```\r\n\r\n> I've seem a lot of instances where command invocations are written like method calls (and subsequently don't work).\r\n\r\nIndeed, and that's why introducing method calls for basic PowerShell functionality is problematic:\r\n\r\n* In the most benign case, you can _get away_ with confusing the parsing modes, but the underlying misconception may come back to bite you later:\r\n\r\n```powershell\r\n# The web is full of examples of confused syntax like this:\r\nNew-Object Foo.Bar($arg1, $arg2) # should be: New-Object Foo.Bar -ArgumentList $arg1, $arg2\r\n```\r\n\r\n* The introduction of `Set-StrictMode -Version 2` is living proof that the confusion is real:\r\n\r\n```powershell\r\nfunction foo { param($bar, $baz) \"[$bar], [$baz]\" }\r\nfoo(1, 2) # binds *array* 1, 2 to $bar only - BREAKS with Set-StrictMode -Version 2 or higher.\r\n```\r\n\r\n* On a related note, the PSv3 introduction of argument-mode-syntax comparison statements / operation statements to `Where-Object`  / `ForEach-Object` is a nod to how argument-mode syntax is easier to type and read.\r\n\r\n"}}
{"actor":{"display_login":"mklement0"}}