¿Debería "n items ()" ser más robusto?<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />A menudo me encuentro con problemas en los scripts con "n items ()". Y a menudo veo este error: "El argumento N Items () debe ser una lista"
En una secuencia de comandos, debido a la robustez de mis datos, lo que incorporo a los nítems a veces puede ser una matriz, un número o un carácter. Aka: variable = [5], variable = 5; variable = "05"; variable = {5}; No entrar demasiado en los detalles, sería muy bueno en este caso si "n elementos" recibiera un valor de carácter, también conocido como n elementos ("05"), escupiría 1, si obtuviera una matriz, lo haría. escupir las filas, ect.
Lo positivo es que JSL nunca se desconectaría si se le enviara un elemento de datos inapropiado, ya que haría una transformación suave de sus datos. Esto reduciría enormemente la cantidad de código necesario para que un script sea robusto a muchos datos diferentes. El lado negativo es que podría llevar a una programación perezosa que dificulta encontrar errores. Esto podría llevar a problemas: por ejemplo, alimenta una matriz y desea ncols, no nrows; o su cadena era "05, 05", la cual debería haber analizado primero, ect.
¿Qué piensa la comunidad? Si "n elementos" fuera más robusto, ¿sería una bendición o una maldición?
Re: ¿Debería "n items ()" ser más robusto?Me gusta tu idea para la matriz. nrows (matrix) * ncols (matrix) definitivamente parece que sería más útil que solo devolver nows o ncols.
Yo diría que devolver 3 para "a, b, c" sería un rendimiento pobre ya que los valores podrían estar delimitados por cualquier cosa: espacio, subrayado, dos puntos ("" "_" ";") para nombrar unos pocos. Esto realmente debería dejarse al programador para que analice con una palabra () o regex () antes de enviarlo a un nodo.
Inicialmente pensé que 1 sería lo más apropiado, ya que en mi caso esperaba una lista de cadenas, pero si las declaraciones anteriores no devolvían una lista, simplemente devolvía la variable como una cadena, en cuyo caso quería 1. Sin embargo, ahora que lo mencionas, los Nitems podrían ser muy útiles si devolvieran la longitud de la cadena y tuvieran diferentes aplicaciones.
Re: ¿Debería "n items ()" ser más robusto?Parece que nItems (matrix) podrían ser más útiles si devolviera nows (matrix) * ncols (matrix).
No estoy seguro de lo que esperaría de los nitems ("a, b, c") porque podría hacer un caso para 1, 3 o 5.
Re: ¿Debería "n items ()" ser más robusto?Encuentro que el soporte de JMP tiende a seguir estos foros, y no tengo prisa, además de que no estoy al tanto del tema, por lo que dudo que sea el mejor candidato para solicitar este cambio.
Solo sé que en JavaScript permiten suaves ecuaciones. Por ejemplo, 5 == "5" devolverá verdadero, con las calidades de disco duro denotadas por 5 === "5" sería falso. Las ecualizaciones suaves a menudo pueden conducir a comportamientos extraños y son mal vistos por muchos programadores. Muchas personas tienen prejuicios en usar siempre una igualdad de condiciones, sin embargo, tener una igualdad de condiciones puede ayudar a que el código sea robusto y si el programador sabe lo que está haciendo, pueden salvar vidas.
Sin embargo, JSL es un lenguaje diferente, y me parece que la mayoría de los guionistas no tienen experiencia en programación. Por lo tanto, permitir una base sólida podría ser perjudicial para el lenguaje, pero al mismo tiempo, podría hacer un gran uso de él.
Re: ¿Debería "n items ()" ser más robusto?Creo que tu sugerencia es una buena sugerencia. Además, independientemente de lo que la comunidad en general considere, la sugerencia debe enviarse al grupo de apoyo en JMP. Solo ellos pueden afectar el cambio.
Y me disculpo por leer su discusión demasiado rápido y por haber omitido su solicitud de comentarios de la comunidad.
Re: ¿Debería "n items ()" ser más robusto?Eso no responde a la pregunta.
Re: ¿Debería "n items ()" ser más robusto?Puede verificar si el valor es una lista si la función "Es Lista". Por lo tanto, lo siguiente funcionaría para escaladores, listas y matrices.
x = un escalador, matriz o lista
Si (es la lista (x)
cuenta = 1
)
Re: ¿Deberían "n items ()" ser más robustos?Este hilo es bastante antiguo, pero pensé en indicar lo que finalmente se implementó en JMP 13 y versiones posteriores:
- NItems (matriz) ahora devuelve el número de elementos en la matriz (filas * columnas) en lugar de un error.
- nitems ("gato") todavía devuelve un error
- nitems ([1 2 3] | / [4 5 6]) == 6
