Siempre es importante el modelo de objetos

Si el modelo de objetos de Javascript es bien entendido, entonces lo siguiente se entiende:
 
Si no, se aprenderá el lenguaje, pero no se llegará con él al Nirvana.

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de bferro

Rato sin estar por acá

Hace un buen rato que no andaba por estos lares. Espero no perderme nuevamente

Imagen de ezamudio

ugh

pues sí, si se entiende el modelo de objetos de JavaScript... pero pues en mi opinión es un error que   no genere una excepción o algo. Eso de simplemente devolver el valor asignado (como si fuera una asignación válida), pffffff.

Imagen de bferro

Es una asignación válida

  es una asignación totalmente válida.

Imagen de bferro

Tan válida como pfffff

 

Imagen de Sr. Negativo

Javascript y la programación orientada a objetos

Estaba confundido con respecto a Javascript y la programación orientada a objetos.

Por ejemplo:
  Lo anterior no es válido en Javascript.

Esto si es válido.
 

Imagen de bferro

Muchas diferencias

Son bastante las diferencias entre un lenguaje orientado a objetos basado en clases y uno basado en prototipos. Entender esas diferencias es necesario.

Imagen de ezamudio

this

  en javascript es una abominación.

Imagen de echan

el scoping en javascript es

el scoping en javascript es el diablo y this es una de sus victimas jeje

Imagen de julgo

impide controlar la pagina

JavaScript puede llegar a ser demasiado molesto al apoderarse del foco y del control de la pagina del navegador, probe esto en internet explorer y fui incapaz de cerrar la ventana (tuve que recurrir al administrador de tareas)
 

Re: Javascript y la programación orientada a objetos

Otra manera que me parece interesante es el estilo de "arreglo", similar a un diccionario:
 

Imagen de bferro

eso es lo que quisiste hacer

EN IE o en cualquier browser va a funcionar de la misma manera, pues eso es lo que quieres hacer. No hay nada extraño en ese comportamiento. el browser está esperando por un evento en el dialog box que creas con alert y eso lo va a a hacer ad eternum.

Imagen de bferro

This es confuso, pero no una abominación

En JavaScript,  dentro de una función, siempre se refiere al dueño de la función. En otras palabras,  se refiere al objeto para el cual la función es un método de él. Si por ejemplo, escribo una función en una página HTML y la llamo de la siguiente manera:
 

En el alert box se visualizará  ya que la función  se añade como método del objeto global, en este caso el objeto  .
Lo mismo sucederá si asocio esa función con un evento disparado por algún elemento de HTML, en este caso un botón, como se muestra a coninuación:
 
Lo que se ha hecho en el código anterior es referirse a la función del objeto global, que es algo diferente (la diferencia es crucial) a si copiamos esa función para que sea un método del elemento HTML correspondiente, en este caso el botón. Para entonces especificar el alcance correspondiente de  , y que se refiera al elemento HTML (objeto) que queremos (en este caso el botón) tenemos que modificar la propiedad onclick de ese objeto asignando a ella la función   como se muestra en el código siguiente:
 
Al dar click ahora sobre el botón, el alert box mostrará [object HtmlButtonElement].

La confusión es aun mayor cuando usamos funciones anidadas, pero tal confusión desaparece cuando llegamos a entender correctamente el scope o alcance. Me referiré a ese caso en el post siguiente.

Imagen de bferro

En este ejemplo, la "confusión con this" es mayor

Escribo a continuación dos códigos. El primero de ellos es erróneo pues se está usando mal el scope de this. El segundo elimina el error, lo que puede hacerse de otras maneras también.
El primero con error:
 

El segundo que elimina el error:
 

Imagen de julgo

si fue a propósito pero era

si fue a propósito pero era una suposición en caso se quiera desactivar a JavaScript o cerrar la pagina no podriamos directamente con alert ,confirm ,etc .y que minimizar ,maximizar y close deberían tener la preferencia.

Imagen de bferro

Eso no tiene que ver con JavaScript

Ese comportamiento nada tiene que ver con lo bueno lo malo de JavaScript, o cualquier otro lenguaje con el que puedas hacer lo mismo. Tiene que ver con el diseño de la aplicación, en este caso el browser que al tener un diálogo abierto inhabilita cualquier otro evento que no esté dirigido al componente que muestra la caja de diálogo. Esa posibilidad es en ocasiones conveniente para asegurar que el usuario responde a lo que solicita el diálogo.

Imagen de echan

Nada mal usar una variable

Nada mal usar una variable para mantener la referencia de this, pero cuando el codigo empieza a crecer se vuelve un dolor de cabeza controlar las referencias globales o fuera del scope de la funcion. Una forma digamos mas "controlable" de mantener la referencia es pasandola como argumento.

 

Imagen de echan

emmmm los programas en

emmmm los programas en javascript son single threaded y se ejecutan dentro de un loop.. si creas un ciclo infinito bloqueas el unico thread del programa.

Imagen de julgo

precisamente al diseño

a veces no es necesario o conveniente , eso era a lo que me referia por ejemplo en el registro de un usuario en pleno proceso quiera abandonar la pagina o no este seguro de sus datos se veria forzado a continuar :
 
pero si no digo que sea culpa de JavaScript sino al mal diseño que se haga .

Imagen de bferro

Prefiero "aplicar o llamar" con this

Pasar la referencia al objeto como argumento o declarar una variable local tiene el mismo efecto. El argumento es una variable local más. Utilizo ambos casos dependiendo del nivel de anidamiento de mis funciones y también utilizo en ocasiones apply, call y bind (métodos de Function prototype) para asegurarme que el this es del scope que requiero. Usando call en el ejemplo quedaría:
 

En fin que no veo abominable ni algo diabólico controlar el scope de this.