2013-05-16 13 views
13

Nie mogę znaleźć żadnej dokumentacji dotyczącej typu zamknięcia w PHPDoc. Moje pytanie brzmi: jak zdefiniować parametr parametrów wysyłanych do zamknięcia i jego wartości zwracanej?Składnia zamknięcia w PHPDoc

Przykład:

Jak mogę opisać, że "callback" dostanie "MyCustomClass", numer i ciąg i powrócić do "MyOtherCustomClass"?

/** 
* @param MyCustomClass $cls 
* @param Closure  $callback this isn't really explaining what this is 
* 
* @return MyOtherCustomClass 
*/ 
function changer($cls, $callback){ 

    return $callback($cls, 2, "a string"); 
} 

changer($aCustomeClass, function($cls, $int, $string){ 
    return new MyOtherCustomClass($cls, $int, $string); 
}) 

A może w ogóle jest to możliwe?

+0

Nie sądzę, że istnieje rozsądny sposób opisania tego w adnotacjach. Nawet w podręcznikach PHP są one określane jako "wywoływalne" w opisach argumentów. –

+0

Tak właśnie się boję, ale byłoby miło, gdyby to było możliwe. –

+1

"Szczegółowa definicja zamknięcia" dyskusja: https://github.com/phpDocumentor/phpDocumentor2/issues/830 –

Odpowiedz

10

@param callable $callback jest rzeczywiście składnią do zastosowania w tej części. Nie ograniczasz tego parametru do samego zamknięcia ... każda przekazywana do niego wartość jest akceptowana w tej implementacji. Callable jest legalnym "typem PHP", więc phpDocumentor akceptuje go jako prawidłowy typ.

W przykładzie kodu, tam faktycznie nie powód, aby przypuszczać, że metoda changer() zwraca MyOtherCustomClass(), ponieważ jest wyłącznie podyktowana jak piszesz zamknięcie później w używaniu changer(). W najlepszym wypadku, można oznaczać w komentarzu na wykorzystanie changer() że tym konkretnym zastosowaniem changer()MyOtherCustomClass zwrotów, ponieważ jest to, że realizacja Usage, a nie realizacja sama changer(), która zwraca danego typu obiektu.

Jeśli chodzi o dokumentowanie argumentów, że przekazana liczba wywołań jest "wymagana" do zaakceptowania, to przypuszczam, że musiałbyś to zrobić w opisie znacznika param. Nie ma żadnej składni, aby opisać taki przypadek.

Gdybym miał coś zaimplementować w ten sposób, narzucałbym interfejs, który wszystkie kalki muszą jawnie zwracać, a więc mógłbym napisać, że ten interfejs zwraca. Oczywiście oznacza to, że twój MyOtherCustomClass musi implementować ten interfejs, ale nadal wydaje mi się, że jest to jedyny sposób zbliżenia się do "egzekwowania" typu zwrotu z changer().

+0

Interfejs może rozwiązać problem, jeśli ponownie zredaguję kod. W moim przypadku nie jest to opcja. –

+0

Rzeczywiście, przepisywanie kodu może być ograniczeniem ;-) Stwierdziłem, że myślenie o opcjach, które wykluczyłem, może czasami powodować pojawianie się innych nowych pomysłów, więc często wspominam o takich rzeczach, które przychodzą mi do głowy podczas przemyślenia czyichś pytań. . – ashnazg

+0

o tym, że nie jest użyteczny dla mojego obecnego projektu, jest rozwiązaniem problemu w ogóle :) –