2013-07-19 20 views
5

Dlaczego w poniższych kodach występuje różnica w wartościach zwracanych przez F i G?Zwracanie wyniku wywołania funkcji z nawiasem/bez nawiasów

Function F { 
    Return (New-Object Collections.Generic.LinkedList[Object]) 
} 

Function G { 
    Return New-Object Collections.Generic.LinkedList[Object] 
} 

Function Write-Type($x) { 
    If($null -eq $x) { 
     Write-Host "null" 
    } Else { 
     Write-Host $x.GetType() 
    } 
} 

Write-Type (F) # -> null 
Write-Type (G) # -> System.Collections.Generic.LinkedList`1[System.Object] 

O ile mi zrozumieć, jeśli funkcja zwraca jakąś pustą kolekcji, PowerShell będzie „rozpakować” go na null, a więc F ma co się spodziewać. Ale co się dzieje z G?

Edycja: Jak wskazał JPBlanc, tylko PowerShell 3.0 wykazuje tę różnicę. W wersji 2.0 obie linie drukują się w postaci null. Co się zmieniło?

Odpowiedz

3

Niestety nie odczytałem poprawnie twojego pytania, ponieważ F jest znaczący, gdy używasz() do oceny funkcji. Tak więc wynik funkcji Write-Type jest taki sam dla mnie w PowerShell V2.0.

W PowerShell 3.0 napotykam Twój problem.

Teraz przy użyciu:

Trace-Command -name TypeConversion -Expression {Write-Type (F)} -PSHost 

Versus

Trace-Command -name TypeConversion -Expression {Write-Type (G)} -PSHost 

ile mi zrozumieć() przed przed powrotem przedmiot generować następujące

Converting "Collections.Generic.LinkedList" to "System.Type". 
    Conversion to System.Type 
     Conversion to System.Type 
      Could not find a match for "System.Collections.Generic.LinkedList". 
     Could not find a match for "Collections.Generic.LinkedList". 
Converting "Collections.Generic.LinkedList`1" to "System.Type". 
    Conversion to System.Type 
     Conversion to System.Type 
      Found "System.Collections.Generic.LinkedList`1[T]" in the loaded assemblies. 
Converting "Object" to "System.Type". 
    Conversion to System.Type 
     Conversion to System.Type 
      Found "System.Object" in the loaded assemblies. 
+0

Czy mógłbyś wyjaśnić? –

+0

Nie sądzę, że to jest poprawne.W 'Write-Type F',' F' będzie interpretowane jako ciąg '" F "', który nie jest tym, czego chcę. – ahihi

+0

niezupełnie, @JPBlanc ma rację, nie powinieneś umieszczać argumentów funkcji w nawiasach, ale nie mogłem znaleźć wyjaśnienia dlaczego. Projekt wieku lub nawiasy robią coś specjalnego. Aby F był traktowany jako łańcuch, musiałbyś go otoczyć cudzysłowem. Zatem F jest obiektem, a "F" jest ciągiem. –

0

Jeśli chodzi o funkcję PowerShell , co oznacza "powrót", to wyjście z funkcji wcześnie.

sprawdziłem książkę Bruce'a P za „PowerShell w akcji” strona 262, mówi:

„Dlaczego więc, czy PowerShell potrzebują instrukcji return Odpowiedź jest, kontrolę przepływu Czasem chcesz wyjść?. a. funkcja wcześnie Bez instrukcji return, to że trzeba pisać skomplikowanych instrukcji warunkowych, aby uzyskać kontrolę przepływu dotrzeć do końca ...”

również Keith Hill ma bardzo dobry blog mówi o tym: http://rkeithhill.wordpress.com/2007/09/16/effective-powershell-item-7-understanding-output/

"......" return $ Proc "czy nie oznacza, że ​​wyjście tylko funkcje jest zawartością zmiennej $ Proc. W rzeczywistości ta konstrukcja jest semantycznie równoważna "$ Proc; return". .....”

Na tej podstawie, w przypadku zmiany kodu funkcyjnego tak, wyjście skryptu są takie same:

Function F { 
    (New-Object Collections.Generic.LinkedList[Object]) 
    Return 
} 

Function G { 
    New-Object Collections.Generic.LinkedList[Object] 
    Return 
} 

To zachowanie różni się od tradycyjnego języka tak powoduje pewne zamieszanie

+1

Jak stwierdzono w moim komentarzu do odpowiedzi C.B., problem nie jest związany ze słowem kluczowym "return". Jest to problem, który najwyraźniej został wprowadzony z PowerShell v3. –

+0

Dzięki Ansgar. Nie widziałem ukrytego komentarza po opublikowaniu tego. – Peter

Powiązane problemy