Los cinco cambios principales de VB 6 a VB.NET

Visual Basic 1.0 fue un gran terremoto en toda la programación. Antes de VB1, tenía que usar C, C ++ u otro entorno de desarrollo horrible para crear aplicaciones de Windows. Los programadores literalmente pasaron semanas simplemente dibujando ventanas en pantallas con código exigente, detallado y difícil de depurar. (Lo mismo que puede hacer arrastrando un formulario desde la barra de herramientas en unos pocos segundos). VB1 fue un éxito y miles de millones de programadores comenzaron a usarlo de inmediato.

Pero para que la magia suceda, Microsoft hizo algunos compromisos importantes de arquitectura. En particular, dado que VB1 creó los formularios y los controles, no permitieron que el programador tuviera acceso al código que lo hizo. Dejaste que VB creara todo o usaste C ++.

VB 2 a 6 mantuvo esta misma arquitectura. Microsoft realizó algunas actualizaciones muy inteligentes que dieron a los programadores mucho más control, pero en el análisis final los programadores aún no podían integrar su código con el código VB. Era una caja negra, y tampoco en la buena forma de OOP. Otra forma de decir esto era que el programador no tenía acceso a los "objetos" internos de VB y otra forma de decir eso era que VB6 todavía no estaba completamente "orientado a objetos".

Mientras tanto, Java, Python y muchos otros lenguajes de programación que estaban orientados a objetos comenzaron a aparecer. Visual Basic se estaba pasando por alto, ¡a lo grande! Esta es una situación que Microsoft no tolera... y resolvieron resolver el problema de una vez por todas. La solución es .NET.

Pero para hacer las cosas que .NET necesitaba hacer, Microsoft decidió que tenían que "romper la compatibilidad". Es decir, los programas de Visual Basic habían sido (con excepciones muy pequeñas) "compatibles con versiones anteriores" desde VB1 hasta VB6. Un programa escrito en esa primera versión de VB aún se compilaría y ejecutaría en la próxima versión. Pero con VB.NET, Microsoft descubrió que simplemente no podían hacer que el lenguaje fuera completamente OOP y mantener una compatibilidad ascendente.

Una vez que tomaron esta decisión fundamental, las compuertas se abrieron tras diez años de cambios acumulados en la "lista de deseos" y TODOS entraron en el nuevo VB.NET. Como dicen en Gran Bretaña, "por un centavo, por una libra".

Sin más demora, aquí está mi lista muy personal de los cinco cambios principales de VB6 a VB.NET en orden inverso.

Wellllll... Solo una demora más. Como estamos cambiando de VB6, donde una matriz declarada como Dim myArray (5) tiene 6 elementos, tenemos seis de ellos. Solo encaja ...

(Redoble de tambores por favor ...)

"Premio (5)", nuestro 6to lugar el premio va a la elección de los groupies C: Cambios de sintaxis tipo C!

¡Ahora puede codificar a + = 1 en lugar de a = a + 1, ahorrando TRES CLAVES ENTERAS!

Programadores del mundo, ¡regocíjate! VB se ha elevado al nivel C, y una generación completamente nueva que intenta aprender VB se acercará un poco más a la confusión masiva que enfrentan los estudiantes de C ++.

¡Pero espera! ¡Hay más!

VB.NET ahora presenta "lógica de cortocircuito" que ha introducido errores sutiles en el código C ++ durante años para ahorrar preciosos nanosegundos de tiempo de procesador. La lógica de cortocircuito solo evalúa múltiples condiciones en una declaración lógica si es necesario. Por ejemplo:

Dim R como booleano
R = Función1 () y Función2 ()

En VB6, ambas funciones se evalúan si las necesitan o no. Con VB.NET, si Function1 () es falso, Function2 () se ignora ya que "R" no puede ser True. Pero, ¿qué pasa si una variable global se cambia en Function2 ()? Por casualidad (los programadores de C ++ dirían, "por programación pobre ".) ¿Por qué mi código produce la respuesta incorrecta algunas veces cuando se traduce a VB.NET? Esto podría ser!

por Tratarmás difícil, VB.NET lo hará Captura un poco de suerte y Finalmente ser reconocido por el manejo "excepcional" de errores.

VB6 tenía el último contenido GoTo: "On Error GoTo". Incluso tengo que admitir que el manejo estructurado de excepciones "Try-Catch-Finalmente" de estilo C ++ es una gran mejora, no solo una mejora media.

¿Qué, dices "On Error GoTo" todavía está en VB.NET? Bien... Intentamos no hablar demasiado de eso.

5to lugar la selección es un premio grupal: ¡Los cambios de comando misceláneo! Tienen que compartir este premio y hay miles de millones de ellos. Microsoft ha estado ahorrando durante diez años y realmente se soltaron.

VB.NET ya no admite las funciones VarPtr, ObjPtr y StrPtr que recuperaron la dirección de memoria de las variables. Y no es compatible con VB6 LSet, que se utilizó para convertir un tipo definido por el usuario a otro. (No debe confundirse con VB6 LSet, que hace algo completamente diferente, ver más abajo).

También nos despedimos de Let, Is Missing, DefBool, DefByte, DefLng, DefCur, DefSng, DefDbl, DefDec, DefDate, DefStr, DefObj, DefVar y (¡mi favorito personal!) GoSub.

Circle se ha transformado en GDI + DrawEllipse. Lo mismo ocurre con Line to DrawLine. En el cálculo ahora tenemos a Atan en lugar de Atn, Sign entra por Sgn y Sqrt se adapta para el gran juego en lugar de Sqr.

En el procesamiento de cadenas, aunque todavía están disponibles si hace referencia a una compatibilidad de Microsoft espacio de nombres, tenemos PadRight para LSet de VB6 (de nuevo, totalmente diferente al LSet de VB6, por supuesto) y PadLeft para RSet. (¡Ahí van las tres pulsaciones de teclas que guardamos con "+ ="!)

Y, por supuesto, dado que ahora somos POO, no se preocupe si no se cumplen las propiedades, el alquiler de propiedades y la obtención de propiedades en VB.NET, ¡apuesto!

Finalmente, depurar. La impresión se convierte en depuración. Escribir o depurar. Línea de escritura. Solo los nerds imprimen todo de todos modos.

Esto ni siquiera toca todos los NUEVOS comandos en VB.NET, pero tenemos que detener esta tontería en alguna parte.

En 4to lugar, tenemos Cambios a las llamadas de procedimiento!

Este es el premio de "bondad, pureza y virtud sana" y representa una gran campaña por parte de la facción "no más código descuidado".

En VB6, si una variable de parámetro de procedimiento es un tipo intrínseco, entonces es ByRef, a menos que lo haya codificado ByVal explícitamente, pero si no está codificado por ByRef o ByVal y no es una variable intrínseca, entonces es ByVal... ¿Lo tengo?

En VB.NET, es ByVal a menos que esté codificado por ByRef.

El valor predeterminado de ByVal VB.NET, por cierto, también evita que los cambios en las variables de parámetros en los procedimientos se propaguen involuntariamente al código de llamada, una parte clave de una buena programación de OOP.

Microsoft también "sobrecarga" VB.NET con un cambio en los requisitos de paréntesis en las llamadas a procedimientos.

En VB6, se requieren paréntesis alrededor de los argumentos cuando se realizan llamadas a funciones, pero no cuando se llama a una subrutina cuando no se usa la instrucción Call, pero se requieren cuando se usa la instrucción Call.

En VB.NET, los paréntesis siempre se requieren alrededor de una lista de argumentos no vacía.

El premio de bronce - 3er puesto, va a Las matrices están basadas en 0 en lugar de 1.

Es solo un cambio de sintaxis, pero este cambio obtiene el estatus de "podio de medallas" porque es votado, "lo más probable es que arruine la lógica de su programa". Recuerda, 3er lugar ES "Premio (2)" en nuestra lista. Si tienes contadores y matrices en tu programa VB6 (y cuántos no), este te MENSAJARÁ.

Durante diez años, la gente se preguntaba: "¿Qué estaba fumando Microsoft cuando lo hicieron de esta manera?" Y durante diez años, los programadores tienen tipo de ignorado universalmente el hecho de que había un elemento myArray (0) que solo ocupaba espacio y no se acostumbraba cualquier cosa... Excepto por aquellos programadores que lo usaron y sus programas se veían, quiero decir, simplemente "extraños".

Para I = 1 a 5
MyArray (I - 1) = Lo que sea
próximo

Quiero decir, DE VERDAD! ...

La medalla de plata de Segundo lugar ¡va a honrar a un viejo amigo que se dejó caer en el cubo de la programación con el paso de VB6! No hablo de otro que El tipo de datos variante.

Probablemente ninguna otra característica única de Visual Basic "notNet" represente mejor la filosofía de "rápido, barato y suelto". Esta imagen persiguió a VB hasta la introducción de VB.NET. Soy lo suficientemente mayor como para recordar la introducción de Visual Basic 3.0 por Microsoft: "¡Oh, vaya! Lookee aquí! Con el nuevo tipo de datos Variant mejorado, no tiene que declarar variables o nada. Puedes pensar en ellos y codificarlos ".

Microsoft cambió su tono bastante rápido en ese y recomendó declarar variables con un tipo de datos específico casi de inmediato, dejando a muchos de nosotros preguntándonos: "Si no puede usar Variantes, ¿por qué? ¿tenerlos?"

Pero mientras estamos en el tema de los tipos de datos, debo mencionar que muchos de los tipos de datos han cambiado además de colocar Variant en cemento húmedo. Hay un nuevo tipo de datos Char y un tipo de datos Long de 64 bits. El decimal es muy diferente. Short y Integer ya no tienen la misma longitud.

Y hay un nuevo tipo de datos "Objeto" que puede ser cualquier cosa. ¿Escuché a alguien decir: "Hijo de variante"?

¡Finalmente! La medalla de oro, 1er lugar, el premio más alto que puedo otorgar va a ...

TA DAH!

¡VB.NET finalmente está completamente orientado a objetos!

Ahora, cuando vas a la playa, los programadores de C ++ no te patearán arena en la cara y te robarán tu (novia / novio, elige uno). Y tu puedes todavía codifique un Saldo de prueba de Libro mayor completo mientras intentan averiguar qué archivos de encabezado incluir.

Por primera vez, puede codificar tan cerca del chip como lo necesite y acceder a todos los componentes internos del sistema que desee. sin tener que recurrir a esas desagradables llamadas a Win32 API. Tiene herencia, sobrecarga de funciones, subprocesamiento múltiple asíncrono, recolección de basura y todo Es un objeto. ¿Puede la vida ser mejor?

¿Escuché a alguien decir que C ++ tiene herencia múltiple y .NET aún no?

¡Quema al hereje!