Tinselcity

Diferencias

Muestra las diferencias entre dos versiones de la página.

Enlace a la vista de comparación

Ambos lados, revisión anterior Revisión previa
Próxima revisión
Revisión previa
whys:this-is-so [2018/03/15 14:54]
flynn traducido
whys:this-is-so [2018/04/07 14:39] (actual)
flynn ↷ Page moved from why:this-is-so to whys:this-is-so
Línea 23: Línea 23:
  
  
-===== Prototipos y ausencia de Clases =====+===== Prototypes and the absence of Classes =====
  
 Guided by those ideas of simplifying and, also, by the inspiration from Scheme and Self, Eich opts for a inheritance/delegation system based on prototypes and the complete absence of classes. This simplifies a lot of things. Guided by those ideas of simplifying and, also, by the inspiration from Scheme and Self, Eich opts for a inheritance/delegation system based on prototypes and the complete absence of classes. This simplifies a lot of things.
Línea 83: Línea 83:
 Or maybe instead of //distorted//, what happens is that "this same object" need to mean something equally dynamic, something that must be established in that same moment we make the call. **There's no other alternative.** At no other moment can we know what "this same object" means in a certain function call, except at the moment of making the call. Even more, the only thing that makes //sense// to be reffered as "this same object" is what the particular call says (''o.prop()'' -> ''o''). Or maybe instead of //distorted//, what happens is that "this same object" need to mean something equally dynamic, something that must be established in that same moment we make the call. **There's no other alternative.** At no other moment can we know what "this same object" means in a certain function call, except at the moment of making the call. Even more, the only thing that makes //sense// to be reffered as "this same object" is what the particular call says (''o.prop()'' -> ''o'').
  
-So, the fact that ''this'' refers to the //subject// of the call, and has to be so for //every call, is not so much a //design decision// but //the only available option// given the rest of the design.+What's more, this is something that happens for **every** call, for **each** call; and so it makes sense that ''this'' should not //be inherited// or //be resolved from the container lexical context// as other references do, because it is not tied to the //definition context// but to the //calling context//
 + 
 +<WRAP center round info 90%> 
 +It is true, though, that more recently, years later, //arrow functions// were introduced and what these do is precisely that: //resolve the reference of ''this'' from the definition context//. Personally I believe that this was not the best decision possible and that it //adds// more complexities instead of reducing them. I would have preferred, say, that //arrow functions// couldn't reference ''this'' at all. This would've limited their usage a lot, of course. In any case, I'm aware that this new syntax (and semantic) for functions had additional motivations from the developer community. Well, such is life. 
 +</WRAP> 
 + 
 +So, the fact that ''this'' refers to the //subject// of the call, and has to be so for //every call//, is not so much a //design decision// but //the only available option// given the rest of the design.
  
 ===== Other values for 'this' ===== ===== Other values for 'this' =====
Línea 89: Línea 95:
 Personally I feel that most confusion around ''this'' in JavaScript doesn't come from the explanation above -which I sincerely think is perfectly reasonable-, but instead comes from some design omissions elsewhere. Personally I feel that most confusion around ''this'' in JavaScript doesn't come from the explanation above -which I sincerely think is perfectly reasonable-, but instead comes from some design omissions elsewhere.
  
-That is, in my opinion, there would be no -or much less- confusion if, e.g., there was some //restriction// that wouldn't allow referring to ''this'' in a call where no subject is available. Maybe a ''ReferenceError'' should be thrown. But instead, and here I think it is difficult to find any explanation other than //urgency// a shortcut was taken ((Or at least an apparent shortcut; if we go by the general policy decision of making the language very permissive and avoiding throwing errors as much as possible, then this decision here is perfectly cromulent)) to assign "by omission" the global object to ''this'' on the call, just to have //something// assigned. (Later, this would be "fixed" leaving it as ''undefined'' which would then throw, but the error thrown is then the same as if we tried to de-reference ''undefined'' in any other case.)+That is, in my opinion, there would be no -or much less- confusion if, e.g., there was some //restriction// that wouldn't allow referring to ''this'' in a call where no subject is available. Maybe a ''ReferenceError'' should be thrown. But instead, and here I think it is difficult to find any explanation other than //urgency// a shortcut was taken ((Or at least an apparent shortcut; if we go by the general policy decision of making the language very permissive and avoiding throwing errors as much as possible, then this decision here is perfectly cromulent)) (([[http://www.dictionary.com/browse/cromulent|cromulent]] -- ([[https://www.youtube.com/watch?v=FcxsgZxqnEg|ironic]]) Appearing legitimate but actually being spurious)) to assign "by omission" the global object to ''this'' on the call, just to have //something// assigned. (Later, this would be "fixed" leaving it as ''undefined'' which would then throw, but the error thrown is then the same as if we tried to de-reference ''undefined'' in any other case.)
  
 And I say that this is what adds confusion because it allows for something we never want, to happen with normalcy. It lets us write code apparently valid but //conceptually erroneous//. The only case where we want to call a function that tries to reference "myself", "this same object" is when there really is such a thing, not when doing calls without a subject. And I say that this is what adds confusion because it allows for something we never want, to happen with normalcy. It lets us write code apparently valid but //conceptually erroneous//. The only case where we want to call a function that tries to reference "myself", "this same object" is when there really is such a thing, not when doing calls without a subject.