Algunas consideraciones.
En primer lugar, las funciones "no están implementadas" de forma predeterminada. Para que una característica se implemente, alguien tiene que pensar en la característica. Luego tenemos que diseñarlo, especificarlo, implementarlo, probarlo, documentarlo, encontrar un vehículo de envío para él y sacarlo por la puerta. Si alguna de esas cosas no ocurre, no obtienes la característica. Hasta donde yo sé, NINGUNO de estos elementos ha sucedido para esta característica.
En segundo lugar, las características se priorizan en función de sus beneficios netos, es decir, su beneficio total para nuestros clientes, menos los costos totales en su implementación. Aquí hay muy reales "costos de oportunidad" en juego. Cada característica que implementamos es docenas de funciones para las que no tenemos presupuesto. Por lo tanto, las funciones no solo deben valer la pena para que sucedan, sino que tienen que ser MÁS beneficiosas que cualquiera de las miles de características que tenemos en nuestras listas de solicitudes de funciones. Esa es una gran barra para lograr; la mayoría de las características nunca lo logran.
Para explicar mi tercer punto, necesita saber un poco sobre cómo se procesan los idiomas. Comenzamos tomando el código fuente y "léxing" en "tokens" - palabras. En este momento, sabemos si cada personaje es parte de un número, cadena, palabra clave, identificador, comentario, directiva de preprocesador, etc. Lexing es increíblemente rápido; podemos volver a leer con facilidad un archivo entre pulsaciones de teclas.
Luego tomamos la serie de tokens y los "analizamos" en un "árbol de sintaxis abstracta". Esto determina qué partes del código son clases, expresiones, declaraciones de variables locales, nombres, asignaciones, lo que sea. El análisis también es rápido, pero no tan rápido como el lexing. Hacemos algunos trucos, como omitir el análisis de los cuerpos del método hasta que alguien realmente los está mirando.
Finalmente, tomamos el árbol de sintaxis abstracto y hacemos un análisis semántico en él; esto determina si un nombre de pila se refiere a un tipo, una variable local, un espacio de nombres, un grupo de métodos, un campo, etc. Hacemos análisis semántico de "nivel superior" para determinar la jerarquía de tipos del programa y el análisis semántico de "nivel de método" para determinar el tipo de cada expresión en cada método. El análisis semántico de "nivel superior" es bastante rápido, y cualquier análisis de método individual es bastante rápido, pero aún así, es difícil hacer un análisis semántico completo entre las pulsaciones de teclas.
Obviamente, necesitamos hacer análisis semánticos completos para intellisense, pero podemos salirnos de la tarea de averiguar qué método estás escribiendo actualmente, y solo haciendo el análisis semántico del nivel superior y de ese método.
Pero la coloración tiene que funcionar en todo el archivo; no puedes simplemente colorear el método en el que el cursor se encuentra ahora. Por lo tanto, la coloración tiene que ser increíblemente rápida, por lo que históricamente hemos coloreado principalmente en base a la información léxica.
De vez en cuando podemos encontrar cosas especiales como "¿es esto probablemente un tipo?" para darle un color diferente. Pero averiguar cuándo una entidad determinada es, digamos, un grupo de métodos frente a, por ejemplo, un campo de tipo delegado, requiere un nivel bastante rico de análisis semántico, un nivel que actualmente no realizamos en cada pulsación de tecla.
Ahora, hay cosas que podemos hacer aquí. Podríamos ser más inteligentes sobre la comprensión de las ediciones de la secuencia de tokens, y solo volver a realizar el análisis semántico y gramatical en la parte editada del árbol. Estamos investigando esta área ahora, pero es solo investigación; es posible que nunca llegue al producto en realidad.
1 para mí querer saber la respuesta a esta. ¿Por qué no puedo seleccionar un color específico para las clases? ¿objetos? métodos? –