Kilka myśli.
Po pierwsze, funkcje domyślnie nie są "zaimplementowane". Aby funkcja była zaimplementowana, ktoś musi pomyśleć o tej funkcji. Następnie musimy go zaprojektować, określić, wdrożyć, przetestować, udokumentować, znaleźć pojazd transportowy i wyciągnąć go z drzwi. Jeśli któraś z tych rzeczy się nie wydarzy, nie dostaniesz tej funkcji. O ile wiem, ŻADNEGO z tych rzeczy nie stało się dla tej funkcji.
Po drugie, funkcje są traktowane priorytetowo w oparciu o ich korzyści netto - czyli całkowitą korzyść dla naszych klientów, minus całkowite koszty ich wdrożenia. Występują tutaj bardzo realne "koszty alternatywne". Każda funkcja, którą wykonujemy, to dziesiątki funkcji, na które nie mamy budżetu. Więc funkcje nie tylko muszą być warte pracy, aby je zrealizować, ale muszą być WIĘCEJ korzystniejsze niż jakikolwiek z tysięcy funkcji, które mamy na listach żądań funkcji. To wysoki próg do osiągnięcia; większość funkcji nigdy tego nie osiąga.
Aby wyjaśnić moją trzecią kwestię, musisz wiedzieć trochę, jak przetwarzane są języki. Zaczynamy od pobrania kodu źródłowego i "dodania" go do "tokenów" - słów. W tym momencie wiemy, czy każdy znak jest częścią numeru, łańcucha, słowa kluczowego, identyfikatora, komentarza, dyrektywy preprocesora i tak dalej. Lexing to niesamowicie szybki; możemy łatwo ponownie przesłać plik między naciśnięciami klawiszy.
Następnie przechodzimy serię tokenów i "parsujemy" je w "abstrakcyjne drzewo składniowe". Określa, które części kodu są klasami, wyrażeniami, lokalnymi deklaracjami zmiennych, nazwami, przypisaniami, cokolwiek. Przetwarzanie jest także szybkie, ale nie tak szybkie, jak leksykowanie. Robimy kilka sztuczek, na przykład pomijamy parsowanie ciał metod, dopóki ktoś ich nie obejrzy.
Wreszcie, bierzemy abstrakcyjne drzewo składniowe i wykonujemy analizę semantyczną; to określa, czy dana nazwa odnosi się do typu, zmiennej lokalnej, przestrzeni nazw, grupy metod, pola itd. Przeprowadzamy zarówno analizę semantyczną "najwyższego poziomu", aby określić hierarchię typów programu, oraz analizę semantyczną "poziomu", aby określić typ każdego wyrażenia w każdej metodzie. Analiza semantyczna "najwyższego poziomu" jest dość szybka, a każda indywidualna analiza metody jest dość szybka, ale wciąż trudno jest przeprowadzić pełną analizę semantyczną między naciśnięciami klawiszy.
Oczywiście musimy przeprowadzić pełną analizę semantyczną dla intellisense, ale możemy uciec, zastanawiając się, jaką metodę obecnie wpisujesz, i tylko wykonujesz analizę semantyczną najwyższego poziomu i tej metody.
Ale kolorowanie musi działać na całym pliku; nie można po prostu pokolorować metody, w której znajduje się kursor. Dlatego kolorowanie musi być szalenie szybkie, więc historycznie koloryzowaliśmy głównie w oparciu o informacje leksykalne.
Od czasu do czasu możemy wymyślić specjalne rzeczy takie jak "czy to jest prawdopodobnie typ?" nadać mu inny kolor. Ale ustalenie, kiedy dany byt jest, powiedzmy, grupą metod, na przykład pole typu delegata, wymaga dosyć bogatego poziomu analizy semantycznej, poziomu, którego obecnie nie wykonujemy na każdym naciśnięciu klawisza.
Są rzeczy, które możemy zrobić tutaj. Moglibyśmy być mądrzejsi w zrozumieniu zmian w strumieniu tokenów, a jedynie powtórnej analizie gramatycznej i semantycznej w edytowanej części drzewa. Prowadzimy teraz badania w tej dziedzinie, ale to tylko badania; może nigdy nie wejść do produktu.
+1 dla mnie chce poznać odpowiedź na to pytanie. Dlaczego nie mogę wybrać określonego koloru dla zajęć? obiekty? metody? –