Hace unos meses, Michael Fruergaard (mpf), publicó un nuevo post en el que nos contaba que había sido introducida una nueva característica en el lenguaje de programación X++: nada más ni nada menos que el operador IN.
Es cierto que una vez leído el artículo y testeado en nuestras propias máquinas, la primera sensación fue un poco agridulce, puesto que al leer el titular esperábamos que fuese un operador algo más amplio, pero una vez digerido, nos dimos cuenta que se trata de un gran avance en cuanto a extensibilidad del producto se refiere. Vamos a ver por qué.
El operador IN, básicamente, se trata de algo similar a lo que hace el operador IN que todos conocemos de SQL, y no es más que comprobar si un valor concreto se encuentra dentro de un conjunto de valores posibles. Imaginemos que tenemos la siguiente sentencia dentro de nuestro código en la que vamos a obtener valores de pedidos de compra que se encuentren en estado Abierto, Recibido o Facturado:
|
1 2 3 4 5 6 |
PurchTable purchTable; select purchTable where purchTable.PurchStatus == PurchStatus::Backorder || purchTable.PurchStatus == PurchStatus::Received || purchTable.PurchStatus == PurchStatus::Invoiced; |
Pues ahora, podríamos sustituir esta sentencia por otra, en la que añadimos los estados a un container, y posteriormente utilizamos el operador IN para obtener todos los pedidos que se encuentren entre los estados añadidos al mismo, quedando algo así:
|
1 2 3 4 5 |
container conStatus = [PurchStatus::Backorder, PurchStatus::Received, PurchStatus::Invoiced]; PurchTable purchTable; select purchTable where purchTable.PurchStatus in conStatus; |
Como veis, es tan fácil de utilizar como parece, ahora bien… ¿Por qué decía antes que nos hemos quedado con un sabor agridulce? Pues básicamente se debe a que, (por el momento) este operador IN se queda un poquito corto, puesto que solo podemos utilizarlo con valores de enumerados, y en sentencias de acceso a datos (select). Si probamos a utilizar el mismo operador, por ejemplo, dentro de una sentencia if de la siguiente manera:
|
1 2 3 4 5 6 7 |
container conStatus = [PurchStatus::Backorder, PurchStatus::Received, PurchStatus::Invoiced]; PurchTable purchTable; if (purchTable.PurchStatus in conStatus) { // do things... } |
Lo único que obtenemos es un error de compilación indicando que se esperaba un ‘)’, por lo que no podemos utilizarlo para tal caso (de momento), ya que se sabe que Microsoft está trabajando para ampliar la funcionalidad de este operador, aunque por ahora toca esperar.
Pero realmente, una vez analizado, la conclusión que podemos sacar es que es un gran cambio en cuanto a lo que a «extender el producto» se refiere. Pensemos en la primera select que hemos puesto en el artículo, y ahora, pensemos en como añadir un nuevo estado a la misma…, exacto! no hay manera humana de extender el comportamiento de esa sentencia en el caso de que necesitásemos hacerlo, mientras que, ahora, con el operador se abre una puerta en la que por ejemplo, podríamos hacer Chain of command de método en el que nos encontremos con el objetivo de añadir, vía extensión, un nuevo estado al container que se utiliza para obtener los datos.
Lo que está claro es que, desde Redmon, se está haciendo un grandísimo esfuerzo para que tengamos tantas posibilidades de extender el producto como las teníamos antes de el hard seal, y por supuesto, facilitando la vida del programador a la hora de migrar versiones, o mejor dicho, olvidándonos de lo que significa migrar de versión. ¿Qué opináis vosotros de todo esto? Os leo en los comentarios 😉