Vista - Suggestion: 1 new operator (well, maybe 6...)

Today I noticed that one important operator is missing in PowerShell: -in
Programming languages such as Pascal/Delphi use the "in" operator to test if
an object is contained in a set or array.
I know that we already have the -contains operator that can do basically the
same thing just with inverted syntax:

PS> 1..10 -contains 5
$true
vs.
PS> 5 -in 1..10
$true

So here are some reasons, why I think we still do need it:

* the -contains operator is too long to type on the command line

* Principle of Least Surprise: great if you're familiar with languages that
use the "in" operator

* the inverted syntax of the -in operator feels more natural in some cases,
e.g.:

switch (1..10) {
{1..5 -contains $_} {'low'}
{6..10 -contains $_} {'high'}
}

vs.

switch (1..10) {
{$_ -in 1..5} {'low'}
{$_ -in 6..10} {'high'}
}

To be consistent with the other operators in PowerShell, this suggestions
also includes the negative and case-insensitive variants:

-In
-cIn
-iIn

-NotIn
-cNotIn
-iNotIn

* another benefit is that -NotIn seems to be better English than
-NotContains, e.g.:

PS> if (5 -NotIn 1..100) {...}
vs.
PS> if (1..100 -NotContains 5) {...}

I'm interested in everyone's opinion on this suggestion, so please tell me
what you think about it.

--
greetings
dreeschkind

----------------
This post is a suggestion for Microsoft, and Microsoft responds to the
suggestions with the most votes. To vote for this suggestion, click the "I
Agree" button in the message pane. If you do not see the button, follow this
link to open the suggestion in the Microsoft Web-based Newsreader and then
click "I Agree" in the message pane.

http://www.microsoft.com/communities...ows.powershell

I like this idea and agree with all the reasons.

--
Thanks,
Roman Kuzmin
PowerShellFar and FarNET: http://code.google.com/p/farnet/

To be honest not coming from a Pascal\Delphi background I am fairly neutral
about this. If -in is added ideally -contains should be removed as the two
are so similar but in reality that could break so many scripts it would be
painful.

From an admins view point the less typing the better so I would support it
from that point of view.
--
Richard Siddaway
Please note that all scripts are supplied "as is" and with no warranty
Blog: http://richardsiddaway.spaces.live.com/
PowerShell User Group: http://www.get-psuguk.org.uk


"Roman Kuzmin" wrote:

> I like this idea and agree with all the reasons.
>
> --
> Thanks,
> Roman Kuzmin
> PowerShellFar and FarNET: http://code.google.com/p/farnet/
>
>
>

"RichS" <RichS@discussions.microsoft.com> wrote in message
news:1B701C7F-2735-48E7-9017-E6F9E3B38DCB@microsoft.com...
> If -in is added ideally -contains should be removed


Why? PowerShell and others (C++ and C#, for example), already have
"redundant" operators like ++, --; += and many others (and there are other
language constructs we can live without). It is up to a user what way to
use. It is nice to have a choice.



One more thought about reducing of typing:

A -in B

B -contains A

In my opinion expression B is usually more complex that A and so B has to be
changed\corrected more often; -IN makes B closer to the end of a command
line than -CONTAINS does, so it reduces typing again.



P.S. currently it is not an issue of great priority, I guess, but why not?

--
Thanks,
Roman Kuzmin
PowerShellFar and FarNET: http://code.google.com/p/farnet/

I filed this suggestion on connect (also adding your arguments) so that
everybody can vote for it:

https://connect.microsoft.com/feedba...6963&SiteID=99

Even if it won't be included in V2 due to its low priority, there's always a
next release. :-)

--
greetings
dreeschkind

"Roman Kuzmin" wrote:

> "RichS" <RichS@discussions.microsoft.com> wrote in message
> news:1B701C7F-2735-48E7-9017-E6F9E3B38DCB@microsoft.com...
> > If -in is added ideally -contains should be removed
>
>
> Why? PowerShell and others (C++ and C#, for example), already have
> "redundant" operators like ++, --; += and many others (and there are other
> language constructs we can live without). It is up to a user what way to
> use. It is nice to have a choice.
>
>
>
> One more thought about reducing of typing:
>
> A -in B
>
> B -contains A
>
> In my opinion expression B is usually more complex that A and so B has to be
> changed\corrected more often; -IN makes B closer to the end of a command
> line than -CONTAINS does, so it reduces typing again.
>
>
>
> P.S. currently it is not an issue of great priority, I guess, but why not?
>
> --
> Thanks,
> Roman Kuzmin
> PowerShellFar and FarNET: http://code.google.com/p/farnet/
>
>
>

"dreeschkind" <dreeschkind@discussions.microsoft.com> wrote in message
news:99E196D2-341F-4830-BC9A-E3C569AA132D@microsoft.com...
> Today I noticed that one important operator is missing in PowerShell: -in
> Programming languages such as Pascal/Delphi use the "in" operator to test
> if
> an object is contained in a set or array.
> I know that we already have the -contains operator that can do basically
> the
> same thing just with inverted syntax:
>
> PS> 1..10 -contains 5
> $true
> vs.
> PS> 5 -in 1..10
> $true
>

It could be that -in, -notin, etc would have been a better choice from the
start but now that we have -contains, etc I don't see much value in adding
the suggested operators. I argued during the beta period that PoSh aleady
had too many duplicate operators (if -eq is case-insensitive do we really
need -ieq?). It makes the surface area of the language larger and believe
it is pretty large as it stands. This makes it harder for folks in general
to learn PoSh. I like Anders approach to C#. He's pretty conservative and
doesn't allow features to creep into the language willy-nilly. I'm sure he
wants to avoid the mess that is C++.

--
Keith

Some more thoughts on this topic:

I agree that -In and -NotIn might have been a better choice right from the
start.
And I also agree that we don't need the case-insensitive operator variants.
(I included -iIn and -iNotIn in my suggestion just for consistency with the
existing operators.)

The difference between these "redundant" operators is that the -IN operator
is easy to understand for the beginner and also very short so it is perfect
if you use it at the command-line frequently.
In contrast, for a beginner it is not obvious what operators like -IEQ or
-ILIKE do. And these variants provide absolutely no additional value if the
default functionality is already case-insensitive. To someone new to
PowerShell those will probably be more confusing than usefull and experienced
users won't use them because they know that case-insensitive is already the
default behaviour.
Why should anyone want to type an additional character if he does not need to?
"We already have too much operators!" is not an excuse as long as those
case-insensitive operators exist.

Unlike many other languages that make heavy use of strange hard-to-remember
ASCII sequences as operators, PowerShell primarily uses "human readable"
operator names (-like, -match, -contains, -and, -or, -not, etc.), which is
actually a great idea. I don't agree that the -In and -NotIn operators would
have a negative effect on the language. On the contrary, they would make
scripts more "human readable".

I'm not sure how familiar you are with the latest additions to the C#
language. Anders might not be as conservative as you might think. Language
Integrated Query (Linq) adds many new SQL-like constructs to the C# language
(from, where, select, sort, groupby, etc.). But at the end, it is all about
making the language more "human readable". The foreach statement,
do-while-loops and the switch statement exist for the exactly the same
reason. You do not need them, but they help making programming languages even
more similar to real world languages.

--
greetings
dreeschkind

"Keith Hill [MVP]" wrote:

> "dreeschkind" <dreeschkind@discussions.microsoft.com> wrote in message
> news:99E196D2-341F-4830-BC9A-E3C569AA132D@microsoft.com...
> > Today I noticed that one important operator is missing in PowerShell: -in
> > Programming languages such as Pascal/Delphi use the "in" operator to test
> > if
> > an object is contained in a set or array.
> > I know that we already have the -contains operator that can do basically
> > the
> > same thing just with inverted syntax:
> >
> > PS> 1..10 -contains 5
> > $true
> > vs.
> > PS> 5 -in 1..10
> > $true
> >
>
> It could be that -in, -notin, etc would have been a better choice from the
> start but now that we have -contains, etc I don't see much value in adding
> the suggested operators. I argued during the beta period that PoSh aleady
> had too many duplicate operators (if -eq is case-insensitive do we really
> need -ieq?). It makes the surface area of the language larger and believe
> it is pretty large as it stands. This makes it harder for folks in general
> to learn PoSh. I like Anders approach to C#. He's pretty conservative and
> doesn't allow features to creep into the language willy-nilly. I'm sure he
> wants to avoid the mess that is C++.
>
> --
> Keith
>

"dreeschkind" <dreeschkind@discussions.microsoft.com> wrote in message
news:8BC46217-6C06-49E1-97A2-78CBBCC863F6@microsoft.com...
> I'm not sure how familiar you are with the latest additions to the C#
> language. Anders might not be as conservative as you might think. Language
> Integrated Query (Linq) adds many new SQL-like constructs to the C#
> language
> (from, where, select, sort, groupby, etc.). But at the end, it is all
> about
> making the language more "human readable". The foreach statement,
> do-while-loops and the switch statement exist for the exactly the same
> reason. You do not need them, but they help making programming languages
> even
> more similar to real world languages.
>

I've been following LINQ and C# since PDC 2005. :-) I didn't stay Anders
doesn't allow any additions to C#. It is just that I think he has a pretty
high bar for those additions. Almost all additions (exception being
automatic properties) to C# are there to support LINQ. It was one of
Ander's goals to make working with relational data from within C# much more
seamless. In short, it was a worthy goal.

--
Keith

Just a quick thought, but "in" and "-in" are already in use.
"in" is used in the foreach loop and "-in" is used in the Add-Member cmdlet.

While it may not be that big of a deal, still, is adding another level
of complexity that worth it to save typing 6 characters? By a level of
complexity I mean having to remember the conditions of use. I.E. '-in'
means X when used here, but Y when used there, and Z when used in a
third spot, but for that case the '-' needs to be removed. Right now we
have Y and Z, but this would be adding Z.

And yeah, somebody can probably come up with a few examples of where
that's already in play, and probably one with even more multiple meanings.

Anyways, as I said at the beginning, it's just food for thought.

I'll be the first to point out my mistake on the Add-Member; that's
-inputobject, got too focused on being about to shorten parameters.
sorry.

SOU630 wrote:
> Just a quick thought, but "in" and "-in" are already in use.
> "in" is used in the foreach loop and "-in" is used in the Add-Member
> cmdlet.
>
> While it may not be that big of a deal, still, is adding another level
> of complexity that worth it to save typing 6 characters? By a level of
> complexity I mean having to remember the conditions of use. I.E. '-in'
> means X when used here, but Y when used there, and Z when used in a
> third spot, but for that case the '-' needs to be removed. Right now we
> have Y and Z, but this would be adding Z.
>
> And yeah, somebody can probably come up with a few examples of where
> that's already in play, and probably one with even more multiple meanings.
>
> Anyways, as I said at the beginning, it's just food for thought.