Powershell: Why should Sort be a reserved verb and invalid for modules / commands?

[schittli]

Good evening

Is there any real good reason why the "Sort" verb is reserved for PowerShell itself?
(I think it proves it's necessity because PowerShell itself needs it, too.)

It's really common to offer special sort functions for custom objects with specific internal logic to order items.

(Please don't think about offering a different verb to sort custom things. It makes no sense to distinguish internal and external verbs)

Kind regards, Thomas

[megamorf]

I don't understand the issue - since sort is a valid verb it can be used in all noun combinations. Can you clarify what you actually want to achieve and what's blocking you?

[schittli]

No Sort is not a valid verb. If we use it in an own module and import it, we get:

Import-Module xxx
VERBOSE: The 'Sort-IniContent' command in the PsIni' module was imported, but because its name does not include an approved verb it might be difficult to find. For a list of approved verbs, type Get-Verb.

I think there is no comprehensible reason to not allow Sort as an approved verb.
Kind regards, Thomas

[Alaknar]

Two questions:

1) Why not use Get-SortedIniContent instead?
2) Why not use Get-IniContent -sort instead?

The reason, as I understand it, is that in order to sort something you use Sort-Object anyway (unless you guys so something completely different with your data).

Otherwise I don't see a particular reason against adding it.

[schittli]

Hi Alaknar

thanks a lot for your proposals :-)!,

1. Why not use Get-SortedIniContent instead?
2. Why not use Get-IniContent -sort instead?

Because we are working with the IniContent-Object, changes its content - and at some time we would like to sort it.

Therefore, I thought that … | Sort-IniContent would be more intuitive because it's similar to … | Sort-Object.

Kind regards, Thomas

[RichardSiddaway]

I'm struggling to understand why

get-IniContent | sort-object

doesn't work for you

why do you need another sorting mechanism

[schittli]

why do you need another sorting mechanism

The object in the Pipeline is a complex business object and we need a Sort-Algorithm to calculate it's right, "natural order".

Because PowerShell is used in more and more use cases (e.g. the SAP ERP uses PowerShell to access their data), I think it's the natural development to have more complex objects which needs their own Sort-… command.

Our PowerShell Module offers the business logic to the user, so he can just work with the business objects.

[lzybkr]

As I recall, the thinking was that there is are a few universal cmdlets where the PowerShell cmdlet was the only one necessary - Sort-Object, ForEach-Object, and Where-Object - none of those verbs are approved elsewhere.

Sort-Object allows for some very complicated sorting via the -Property parameter, here is a contrived example that combines properties in a synthetic property for sorting purposes:

class AB { $a; $b }
$data = [AB[]]$(
    @{a="dd";b="aa"}
    @{a="cc";b="zz"}
    @{a="cc";b="mm"})
$data | Sort-Object -Property @{e={"{0}{1}" -f $_.a,$_.b}}

and the output - note the synthetic property is not present, but it is properly sorted if you combine the strings.

a  b
-  -
cc mm
cc zz
dd aa

I think there was also the suggestion that if this was still insufficient, that one would add a -Sort <algorithm> style parameter to their Get-SpecialThing cmdlet.

[schittli]

Good evening

Thank you very much for all your support!, but this is not a technical question.

Of course, there are ways to solve the problem to sort complex business objects.
But in fact, this is the real problem / question:

1. PowerShell has the great verb-noun concept. We should not break it, because it allows us to use PowerShell in a very intuitive way.
2. I'm pretty sure it's a great concept to hide complexity in Modules, so that users of our modules do not have to remember to use
   > $data = [AB[]]$(
   > @{a="dd";b="aa"}
   > @{a="cc";b="zz"}
   > @{a="cc";b="mm"})
   > $data | Sort-Object -Property @{e={"{0}{1}" -f $_.a,$_.b}}

… just to get business objects in the right order.

1. To add a -sort argument to a Get-SpecialThing cmdlet breaks the great verb-noun rule, because we would like to Sort something and not to get something in a sorted way.

Conclusion:

1. The best way to sort Complex Objects should be Sort-BusinessObjects. Because it has the expected verb-noun naming: Sort a Business Object.
2. It does not make to reserve Verbs for internal commands, just to have them reserved. ;-)

You probably recognize that english is my foreign language and I'm fighting with words. A lot. :-)

[iSazonov]

We could try to save this cmdlet universal and add the ability to specify not only Property but also Method/Class/Interface for sorting.

[joeyaiello]

First, I totally ack that certain objects and types require complex business logic for proper sorting. That's a very real business problem, so the question from here is "what's the right technical solution to solve that business problem?"

AFAIK, the original intention of reserving Sort was to discourage users from writing all sorts of custom sorting cmdlets that are incompatible with one another. The fact that anything can be sorted with Sort-Object lends itself to being the "One True Way" to sort objects. For discoverability's sake, you don't have users having to cycle through Sort-Int, Sort-String, Sort-MyObjectFoo, etc. until they get the right one.

From that perspective, I think the right solution here is to expose some sort of way for you to implement the proper custom sort method in your own output type. For instance, maybe if you implement a SortObject method for your output type, we run that thing by default with Sort-Object (or maybe you put an attribute on some method or whatever, you get the point).

That way, you can house that custom logic in the cmdlet itself, and users can continue to use Sort-Object as they would with any other object.

Side note @schittli: your English is fantastic. I genuinely didn't notice until you said something. Thanks for being patient with us. 👍

[joeyaiello]

Also, just to confirm, you're not blocked on your scenario here, right? A verbose message gets thrown, but that shouldn't actually prevent you from exporting the cmdlet (at least I'd hope so).

[iSazonov]

We have Issue to add interface support in PowerShell classes. This automatically enhance Sort-Object capabilities.

[iSazonov]

@joeyaiello @SteveL-MSFT It seems this discussion is exhaustive and it should not be kept open - either allowed or rejected.

[schittli]

The most useful solution would be
if PowerShell would allow adding approved verbs to the internal list of approved verbs.

That's why: 7 of 10 used modules (from public libraries) creates this warning:

Import-Module xxx
VERBOSE: The … command in was imported, 
but because its name does not include an approved verb it might be difficult to find.

Because this warning is displayed very often, it is taken ad absurdum - and users just disable it.

Therefore, module developers should be able to extend the list of approved verbs.

Thus we get back the usefulness of this warning.

[SteveL-MSFT]

@schittli The @PowerShell/powershell-committee has approved new verbs in PSCore6. Allowing module developers to extend the list of approved verbs is counter to the concept of an approved verb list making it easier to discover cmdlets as well as maintaining consistency so that you don't have multiple verbs that mean similar things.

@iSazonov I believe this is answered, so closing this issue.

[yecril71pl]

1. I'm pretty sure it's a great concept to hide complexity in Modules, so that users of our modules do not have to remember to use

$data = [AB[]]$(
@{a="dd";b="aa"}
@{a="cc";b="zz"}
@{a="cc";b="mm"})
$data | Sort-Object -Property @{e={"{0}{1}" -f $_.a,$_.b}}

… just to get business objects in the right order.

Just define the correct default property key for your object type and you are all set.