 So this particular session, the first time I had a similar session it was more like an unblocked kind of session. The idea was to kind of, you know, to kind of talk about jobs and kind of get together and have an informal discussion around maybe some of the issues that you have been saying or some that people have or something like that. You know, we'll pick some topics and make a scope from there. It's not like a set agenda, we can just go wherever. So yeah, so that's kind of the goal behind this session. So you know, if not any time you want to talk about something that you want to talk about. But otherwise I kind of wanted to go through a bunch of stuff. Before I go to that though, if you attended my previous two sessions you already know the drill. So I have this little console that I used to do my demos in. If you haven't been to the other two sessions then I'll very quickly tell you what this console does. So basically I can write little pieces of script here, hit control enter to run them. If I type correctly without a USB and alert is annoying so you can do this. Then it shows up on the right hand side. If there are errors in your script then there are errors come out of the bottom right hand corner. I should probably do some CSS stuff to make it a little smaller to fit inside. So I'm kind of zoomed in. That's why the error page goes up outside. Hopefully I'll type without errors. But if I do, it will make errors. So that's the console. So I have a bunch of stuff that we can talk about here. We can talk about functions, how we can do octetorient development in Javascript and so on. Maybe we can talk about OO in Javascript. We spoke a lot about functions from this track today I guess. So one thing in Javascript, in fact in the functional programming session I was speaking to you about Javascript being a prototypical language. What do we mean by that? Has anybody here heard of the design pattern about 5-6 people here? Yeah, so the prototype design pattern is a creation pattern. Where the idea is basically a prescription. The way of implementing that aspect of your application where you are instantiating objects. So the entire classification of creation patterns are all patterns which help you instantiate objects in loosely coupled ways. So prototype is one such pattern. So creation pattern helps you create objects. Javascript as a language has been designed ground up as a prototype language where the primary mechanism for code reads in Javascript. So in static object oriented languages like C++, C sharp, we are used to defining classes. Classes are essentially templates for what an object is going to look like at runtime. You define your classes, you instantiate them, all methods on your practices will look different. It turns out that Javascript supports this style of development also. So you might have done stuff like this. You might have run functions in person. And remember I am defining a function which is a bit of a weird aspect of Javascript. I am defining a class but the syntax is... So you keep running into odd things like this in the language. So here, for instance, I tell you what you should probably do is define a constructor function that maybe does nothing in this case. And then I will say prototype.name equals maybe a person.prototype.print equals function. You know maybe I will say print name is this.name. Now I have defined a class. This body called class. Class encodes and I define a class. And this class has a field, a member field called name and a member method called print. So how do I use this? The using bit looks a lot like Java or C sharp or whatever. So I can say var p equals new person and say p dot... And it prints that. Or I can assign a name and say p dot name equals who and you know that word. Now the question is what is really happening here? First of all, a little history behind this. So Bender-Mesh is the inventor of the language. So he was tasked with coming up with the programming language for Netscape navigator in like, you know, ridiculous amounts of time. Like he was asked to do it like, you know, very, very short amounts of time. So that's how he came up with Javascript. So the warps of Javascript can probably complain about the fact that he wasn't the right guy at that time. He was also asked with the job of attracting Java developers. I mean, the language is called Javascript, right? So recently there was a conference in, I think, last year called Mix in Las Vegas where Douglas Crockford. Douglas Crockford is like a Javascript guru. He works for Yahoo. He's on the infamous script to snap to his body and all that. So he was there on a panel. Like it was like a discussion panel. I think we're going to have one today here. A discussion panel where if he was there on the stage and people could ask him questions, he would give answers. So somebody mentioned about the fact that Javascript is really not a scripting language, right? If you define a scripting language as some special purpose language, which is somehow limited in functionality, which is intended for one particular task. I mean, that's what we typically say. We, when we say something is a scripting language, right? Maybe a scripting language that extends Photoshop, a scripting language that allows you to, you know, automate office. So those are very special purpose and somewhat limited in scope of functionality. So the person on the stage was mentioning that Javascript is not such a language. It's a general purpose language. It's a curing, complete language. You can build, you know, pretty much anything you want with Javascript. So Douglas Crockford made a comment. So he was saying, so what he was actually saying is Javascript is not a scripting language. And we all know it's not Java. And then it's a completely wrong name for the language, right? We're calling it Javascript is not Java or a scripting language. Which actually is a very good point. The reason why it was called Javascript is because it was cool to name things Java, with a good Java name at that time. But that's why the standard name for the language is ECMA script, which is about as uncool as it can be, I guess, right? So this... It's gone. So this impact you're seeing here was great. And so that Java people will look at this code and, you know, feel happy about it. But essentially what's happening here is something quite different. You know, under the covers. Under the covers, what is happening is something very similar to what they showed in the other stuff, like object.create. So this is the Javascript described way of creating objects, right? So if you want to create an object, do this. Object.create. Provide the prototype as the first parameter. And... So let's not worry about the second parameter now. Right? And then... Everybody said very step. Remove this. So let's say I have something like, you know, name is that, page is that, right? So I can now say O dot code to the back page. And that prints that. So this is the Javascript way of creating things. And this looks nothing like... I mean, if Java developers had seen this, they would run away, right? What? That's an object creation effect? It turns out this is what Javascript was designed to do. So what you're doing here is you're creating an object called O. And the object's prototype is this particular thing here. So here, essentially, you're saying that it's the prototype that patterns. We're saying that this is what my object should look like. It should have a tropical name and should have a tropical page. Now, create another object for me, which is based on this prototype. So object.create will basically create the object. So if you, you know, essentially what happens here is... So when I say something like code.page, right? I'm accessing code.page here. Javascript has this concept of objects can have own properties. Right? Objects can have properties that have been created directly on... On the object. And objects and properties and members that are part of the prototype, the object's prototype. So essentially here, what is happening is when I say O.page, right? The Javascript runtime has to figure out where this property is. So first, it's going to look at what are the own properties of that particular object. Thus, a property called age exists on O. If it exists great, it just resolves to that, gets the value and that's done, right? It could also happen that there is no property called age on O. In that case, dot front-time will go find out what is the prototype of O. Then look at the prototype and see whether that prototype has a property and it keeps working this prototype change. This can go n-levels, right? So I can say var O2 equals object.create O and I can create dot with the second parameter. So here I'll say O2 dot say O2 dot age equals 20 print O2 dot age, right? So here when I say O2 dot age, what is the Javascript runtime doing? It's going to see if O2 itself has a property called age, it does not. Then it says what's the prototype? Prototype is go. Does O have a property called age? It does not. What is O's property? Prototype. O's prototype is this particular object here. It is a temporary object that created. That indeed does have a property called age. That's what is getting written here and that's how the prototype resolution works, right? So here you will notice that there are no types involved here, right? Not with the person case. With this case, there are no types here. What the prototype here itself is another object, right? And the new instance is also an object. So there is no concept of instantiating an object from the type, which we are familiar with in static languages, right? So when you instantiate a new object, you are saying this object is of a particular type. So what do you guys think? What kind of a language is JavaScript? Is JavaScript a strongly type language or not? No. So what kind of language is it? Sorry. Dynamically typed. It is definitely dynamically typed. But I guess the technically correct term is duck typing. Duck typing. Duck typing is an interesting concept that is associated with JavaScript. Somebody mentioned weekly typing. JavaScript can be thought of as a weekly type language. There are types, right? Do you know what the types are in JavaScript? String, object. Object? Object. Number. Number. Nobody can forget object, right? String and device. String, number. Number. Number. Array. Array. Array. I think that's it. Pretty important type. Those are the types, right? That's it. Pretty much everything else is an object. So there is an operator called type of, right? It's a funny operator because chances are when you say type of something, it will tell you it's an object, right? Which is not very useful because you want to know what type of object it is. So JavaScript is weekly type, right? So there are many frameworks which attempt to build a type system on top of JavaScript and do various interesting things. But really, it's kind of not what it's meant to be. Really fighting the language to build a type system on top of weekly type language. So with ECMAS 5, they introduced object.create where they really embrace the strengths of the language. It's a full type language. Let's talk about object.create. I mean, let's talk about object creation. The way it was meant. When you do var p.p equals new person, what is essentially happening internally is something like object.create. So if I were to, you know, rewrite this object creation as to what actually happens because essentially something like this is happening. Let's say var p.2 and then assign this to an empty object. And then I'll say person.call of p. Right? And then I'll write a line of code which is not valid because it's not possible to do this in Latin JavaScript. At least ECMAScript JavaScript, you can do it in Firefox and some of the other JavaScript engines where you can create a different object by saying underscore code prototype and whatnot but that's an extension. But, you know, it's standard JavaScript. This is not possible. So let's say p.2.protite equals person.prototype. So imagine that, you know, I could write these three lines of code. This is what the single line of code translates to. So if you notice here, I'm still creating an empty new object and I'm calling this as a constructor function. In fact, in JavaScript, this thing is called as a constructor function. It's not called as a constructor function. It constructs an object. And then I'm saying here person.call of p.2. So imagine, you know, sometimes you write code like this, right? So in your constructor function, you actually do some constructing. So you say this. Let's say gender is something, right? So you know that initialization happens when the constructor is called. So here how many of you know what call is? Do you want to take a shot? This is the word there in fact. Exactly. It's also applied method. So what is called, right? So here person is not a class. It's a function. You know, what gave away the fact that it's a function? We said it's a function, right? So it's not a class. So all functions in JavaScript have themselves objects, right? And it has member methods. So a function has a member method, which in turn is a function. Because you know I guess, right? But that's like this. So.call here is a member method on the function object, right? So what can you do with call? So let's create a very simple function here. So for example I say function who, right? And I say print who. So how can I call this? I can call it like this, right? So it will just create a this one. We are in that icon. Oh, yeah, you're right. So this thing prints that, right? Now how else can you call this function? I can also say who.call and you can see that among all this output you can see that who is getting printed, right? Anyway, so this is also the way of calling the particular function. So you might wonder why do you have that, right? It seems redundant. I mean, when I can call it like this, why introduce another way of doing it? The reason is this. So let's say here I do something like this. I say this.bar, right? Then I can do this. I can say who.call and I can pass an object here and I can create a property that it expects. I can say bar is 10. So now you can see that prints a previous here. So you can see it prints who dashed 10 here, right? So now do you see what call does this particular parameter here, the first parameter is basically this inside that function, right? That becomes a context for that particular function call. So that's what I have done in the pseudo code here. So it creates an empty object, then it invokes that particular function passing this object as the context for that particular constructor, which means your gender and all gets created and then I assign the prototype for this object to that object. So this prototype hookup is what happens when you do object.create. So essentially this kind of code is actually running here. In fact, go look up a blog post by Douglas Stockport where he actually provides an implementation of object.create for pre-ecma script 5 versions of the JavaScript engine. So if you have a JavaScript complied with ES3, which does not have object.create, you can use a shim to implement it with Douglas Stockport. It's a very simple like three lines of code, which does very similar to something like this. And that implements the object.create there. So even though you can do this, this is what is happening under the covers. It's still taking advantage of the prototyping nature of the language. So that's like a lot theory about the prototyping nature of the language. Another thing that I wanted to talk about was the question about classes. Is there any way I can clone, like any way I can show inheritance, I can do inheritance in JavaScript? Yes. So for your second object, object.create, but O2 doesn't have anything by itself. So can I define a prototype for O22? You kept saying that there is a second argument, but you kind of skipped it. Yeah, good catch. I want to talk about the second argument object.create, right? So the second argument object.create is basically all properties for that object. So here, what is the first argument? First argument is a prototype. So we want O to inherit from that, from this. And I say inherit from what I mean is the new object's prototype will be this object. And very rarely do you want to just create a prototype of another object and do nothing with it. That object probably will have its own functionality. You are inheriting an overriding maybe. You are inheriting and enhancing, augmenting functionality. So how do you do that? So with ECMAScript 5, what you can do is you can pass another object here as a second parameter, which is basically a dictionary of properties that will be available in the new object. So for example, here I have name and age. Let's say I want to add gender as a property here. So I can say the property name is gender and the value needs to be another object which is called property descriptor for that. So there are some interesting capabilities in ECMAScript 5. Like you can first of all, you can set a default value. So I'll set that. Then you can do stuff like this. I can control whether that will be writable or not. So if I say like the one is true, then that means that through this object I can assign a value to the gender property. Otherwise I cannot. There is something called enumerable, which can be again true or false. And now I remember. The morning I can remember this. Configure which basically controls whether this controls whether this configuration for this property can be changed or not. So let me show you some examples of that. Which one? Enumerable? Configure. Enumerable controls whether you can use reflection to see whether this object has that property or not. I'll show you how that works. So here what do we have? So we have name, age, and gender. So I can say print o.name. Let me get rid of all these other stuff at the top. So it doesn't get better. So if I say print o.name, I get true. So no surprise there because post prototype has name. And o.age equals 20. Then if I say o.gender you see that difference? And I can assign a value to it as well. I can say o.gender equals m and if I put in that s first and difference m. So it works just like a regular property. But the interesting thing is there is a property descriptor associated with that. So for instance if I just go ahead and make this false which means the object is not writable anymore. So now you see that f doesn't change. Even though I'm assigning m to it, that line is just ignored. The last front end sees that gender is a property. This assignment has no effect. If you run this in strict mode JavaScript, this will throw an error. Strict mode is another feature in ECMAScript 5. So that's one thing. Another thing is innumerable. So you can do reflection in JavaScript. Some of you know that you can do reflection in JavaScript. What I mean by reflection is to dynamically inspect an object to see what members it has. That's one of the things that you can do with reflection in JavaScript. So for instance, you can write code like this. You can say for that's a p in group and you can say print p. So it says name H. It's now missing an u. I was wondering about that. Where did gender go? So now it prints gender, name and age. So this can basically introspect over the object to see what property it has. Now you probably can tell what will happen if I say it falls. And you know what's the default also. What is the default? So now you can see that name H is there. Gender is not even showing up as a property here. But you can still use it. I can still assign values to it. It will change. So it does change that to m but it's not there. So it's basically like a hidden property. Or for that matter you don't have to do this. There's another JavaScript thing called as object.keys where you can pass an object and it will return the members. So here see object.keys does nothing. Now the interesting thing about object.keys is it's not like for what I am. In some object it will actually enumerate through all the properties of the own properties of the object and all the properties of the prototype. So it will first iterate through all the properties of who then it will go what is the most prototype. It will go through all the prototypes until it hits object or prototype. So that's why you're seeing all that. Object.keys is a little different because it will only list own prototypes. I mean own properties. So here since we said false it's saying nothing is there. If I say true it says gender. Age and name are there. But it's in the prototype. Object.keys will not give you the non-con members. There's another member get own properties. There's another function in object that you can go look up which does what for what I am does. It will walk your prototype chain and tell you what are the properties. Hasn't probably tells you whether the object has the property or not. There is just like he's there is another one. You don't have connectivity here. Or I can look up another session. In fact in Bangalore JSPOO we had a session on ECMAScript 5. There I think I might have spoken about this. See get own property names. It doesn't sound very promising though right? Get own property names does the same thing. I think get own property name does the same thing as object properties. But the difference is it does not honor the enumerable. Even if you say enumerable is false it will still give you the property names. What can I say? JSPOO is funny. But there are some other interesting side effects of making enumerable false. Like once what happened I know what we will tell you that I made some properties not enumerable. And then I was debugging the code and the debugger for some reason I forgot that I had made enumerable as false. I couldn't see the object properties. So I was like wait a second I was assigning the property here but debugger is not showing this. So it turned out that even the debugger wasn't enumerable. So if you say enumerable as false the debugger itself won't show you that property in the quick watch window or something like that. But yeah so get own property names is different. But if you want to walk the prototype chain I guess the only option is to do what I am doing. So these are some interesting things. Configurable what it does is it allows you to say whether this configuration can be subsequently changed or not. So before you can see how that makes sense you need to know how you can change. So for instance in code if I want to make this property from variable to non-writeable I can write do something like this. I can say object.define property. I can pass that object, I can pass the property name and I can pass a new descriptor. So here I can say value is doesn't matter. I can say writer will is false and I can say enumerable whatever enumerable is true maybe let's figure it out. So now what have I done? So here I have writeable as true maybe I will make this writeable as false and I will make this as writeable true. I am changing the configuration for that particular property. So here if I say gender is m and then say print code or gender what should we get? f. So here I will say gender is m and print code or gender. Let this clear this up. So you can see that in the first case this had no effect. In this case if it changed it became m. Why? Because I did an object.define property here and changed the proper descriptor for gender from writeable to I mean non-writeable to writeable. What configurable does is it allows you to configure whether you can do this or not. If you say configurable is false this will have no effect. The original configuration is permanent you can't change it. So there are all these features that ES5 has brought in and it really makes sense to use them. Sometimes I think that JavaScript is too dynamic for its own good. You can just back on property whenever you want. You can just work crazy but configurable is true on top. And I put it later on I declare it as false. What kind of configuration? Are you saying if I say configurable is false and then change the configurable to true later on? It shouldn't change. So this question was if you made configurable as false which means you cannot change the configuration can you change configurable to true subsequently? It should not be different because configurable is also a property. So what these aspects of ECMAScript 5 does is it limits your language really. We are really limiting stuff here. We are saying you cannot write to this. You cannot do this. You cannot do that. That's actually a good thing because sometimes you want to do that. Sometimes you want to have a property which you don't want clients to modify. How can you implement something like that? You can use this. Is this configurable for already existing objects like window or error? That is for DOM. In recent versions of modern browsers it does work. So ECMAScript 5 support has been in various versions of various browsers. So I cannot say that all of those versions will support all of these properties. I8 has a partial implementation of some of these capabilities in the DOM. I9 has a full implementation. The behavior kind of changes. The same similar sort of things apply in Firefox, Chrome and so on. So for the DOM itself your mileage varies. But for your own objects that you create, you can definitely use it. And the nice thing about ECMAScript 5 is that you will notice that none of this actually introduces new syntax here. So when you want to create a new object you are saying update or create, fine. So that's a new capability that's available in ECMAScript 5. But I can write shims for pretty much all of these, right? If the user who is coming to your site is using an older version of the browser that does not know about ECMAScript 5 what's going to happen? Now, is it possible for me to write a object.create which accepts all this and does nothing with it? I can definitely do that, right? Or I can do something reasonably intelligent with it. I can ignore all this because I cannot implement it. So I can create a property called set the value to F. So in fact if you look at the documentation for ECMAScript functionalities in Mozilla you will find that they are provided a backward, you know, compatible implementation of many of the ECMAScript 5 capabilities. So if you want to use object.create in your project but you have to support a wide matrix of browsers, brands and versions and what not you can use these shims. In fact, if you go to the modernizer page where they have listed, the list of polyfills there are polyfills for ECMAScript 5 also. So you can include that, you know, a JavaScript library in your project. New browsers will simply leverage the new capabilities older browsers you will not get the full capabilities but it will still work. And that is possible because there is no new syntax. So see, imagine that if they had done something like you know, from here on everybody who wants to create an object will write code like this make new object and then give type. I am just cooking up some syntax here. See if they had done this for ECMAScript 5 then you are pretty much screwed, right? You can't use this in your code because older browsers just don't want to work. You can't provide back, you know, you can't, libraries can't do this. They didn't do that, right? So in fact that's like a design philosophy of goal behind ES5. All of this stuff you can simulate to some extent. You can't simulate, for example, writable with an ES3 engine. This is simply not possible. You need support from the engine to do that but this code can still work, right? So that's an interesting design. In fact people ask, you know, there was ES3, ECMAScript version 3 of the standard. Then we have ECMAScript version 5, right? So what happened to code? Does the ECMAScript standard nobody not know how to count? That's not the issue. So basically they had introduced a bunch of sweeping changes in ECMAScript 4 that there was no consensus on making syntax changes. They just really wanted to kind of modernize JavaScript and it didn't fly. So they said, you know, they kind of scaled back on their ambitions and decided to make ES5. But, you know, many of those concepts are still there in the form of APIs like this. So that's one thing I want to talk about. There's probably one last thing that we will discuss and we'll be done. Still to be totally out of time, right? No, we have till 2.45. Yeah, but we have questions. Yes, I mean, yeah, this whole session is open for questions any time. Completely out of time. But this is another interesting topic that I wanted to talk about called Variable Hoisting. Yes. The second parameter for object.create is also an object. It's an object, yes. So what's the how is that created? That's JavaScript. So for example, if you do this just the name is 2. Now the question is what is this? What is this object? So let's find out. So that's a good question because now we can look at another API called object.get prototype object. This is again an ES5 function. You can't get some object. It's a prototype of that object. So I'll say proto is that. Now, what could be the prototype? Any guesses? Object. Object, good guess. So let's test that. Proto equal to equal to object.prototype So you can say that it's it's true, right? So that's all it is. So if you just create an object with this syntax object was prototype is object prototype. And the next question would be what's the prototype of object? So that's where the work ends. So it doesn't go beyond that. The end of the road. So so your question is what happens if I say proto equals object. I wish they had smaller re-gainings like that, right? Let's first do a type-off and see what it will print out. Object. You know, it's fairly a recent guess, right? If anyone says type-off will give you object, it will be right most of the time. It's a completely useless object in my opinion. So I really don't know what it is. Can I say proto is undefined It's not undefined. Null? It's null. It's object's prototype. So this operator, does this look funny or do you guys know what it's already called? No. Triple equal. Normally put two equal tos, right? What in C or C++ languages which have their syntax already in C or C++ So you said two equal tos for equality. JavaScript put three. You say three equals. And if you want to check for not equals instead of saying not equals you'll say not equals equals. It's equal. Typecasting that happens. Implicit typecasting that happens. But type conversion, not even castle. Type conversion that happens. So, you know, for example, if you... I have a question. See, you just made that object right now. Before I tell you... Oh, okay. So O is of prototype object. Objects prototype, yes. You can also... No. This is the same because in yesterday yesterday also you create an object like this. It's prototype. So basically, if you did something like this print one equals equals one in double quotes. What is it going to print? So you guys know what it's like. So it checks for that type. It doesn't do implicit typecasting or type conversion. All right. One thing I want to talk about is gradable hosting. So let's create a function here like this. Let's say I have some line like this. Line of code like this. I'll just have one equals equals one. It really uses it. And I'll declare var i equals 10. And then I'm going to say print i. Now my question is what will it print? What will it call? How many of you say undefined? One, two, three, four, five. What will it say? It's going to print 10. How many of you say 10? It's about six or seven more. What do the rest of you say? Indefined. What? It'll print 10. It'll print 10. It'll print 10. What undefined? The options. It'll print 10. It'll print 10. It'll print 10. And you're probably surprised. If you're coming from a C or C++, this is JavaScript is broken. This is not allowed. This is illegal. Now the thing to understand, I was shocked. When I first saw this, I was like what? No wonder people, some people who have very strong emotions about JavaScript when they come from a C or C++ and they're forced to work on web applications, they're like, ah, but you want to do this? Before explaining, can you just put a print type in both Fs? Good idea. Print type. So let's ask, let's go to the same pool. What's going to print? You're right. If your print undefined, my console has a problem. Let me just do this. If it's undefined, it won't print anything. I have to fix that. I'll just do that. I equals undefined. It is undefined. I say J. What's going to happen now? Reference error. Sorry? Reference error. Yes. So somebody said reference error. There you are. So it says reference error, J is undefined. Right? But it didn't say that for I. Even though I kind of used it the same way. I said I is like that. Now when I run this, it prints, it is undefined. No error. So what's going on? So that's what variable hosting is about. So that's no need. So the thing about JavaScript is there is only one construct in the language which introduces scope for variables. And that construct is a function. C, C++, Java, C sharp, all these languages. Anytime you have a block, code block like that. Right? That introduces variable scope. If you declare something inside it, when control flow exists that block whatever was declared inside of that gets removed or deactivated and what more. JavaScript is not like that. JavaScript only construct that introduces variable scope is a function. So when I declare something like this you know what JavaScript sneakily in the underground goes and does? It does something like this. So it basically takes your variable declaration from inside it and declares it at the top and puts the assignment inside of it. Right? And then that's it. If I had shown this code right, nobody would have any issue with those questions. If I print I here it would be undefined because I didn't assign anything. If I print I here it would be 10 because this is a useless issue. This is what JavaScript is doing. So this particular concept is called variable voicing. No matter how nested it is like you might have a pile loop, you have nested loops whatever it is inside that any variable that you declare without you knowing JavaScript it takes those variable declarations most of the time it might work for you because coming from C++ background for example you might just use it only in that cloud. But what happens if I did something like this? I have some code later on more useless in where I go and say var i equals new person or whatever. Maybe it will still work but the thing is the semantics are completely different here. In both the cases there's only one var i that's being declared in the top just being reassigned. So this could introduce hard to detect problems So the best practice recommendation for this is doesn't it go like out of scope? It doesn't. After what? That's what var is supposed to do right? Isn't var supposed to do that? If I just make it i equals to 10 then it goes like global. That is even worse. I mean i equals 10 makes it global. It could be accessible even outside of it. But yeah, that seems to I mean individually it sounds like it should be like that. But Jaskar doesn't do that. So it goes and changes your code around right? So if you declare this it will go and declare it to the top. It will be as if you declare it like this at the top. So what you know what the best practice is around this? Don't do it. So what seriously though what the best practice is declare everything on the top. So that's the because then you have explicitly it becomes obvious to anybody who's reading the code that all this declared here you know what the scope of that variable is. Because if it is inside you know blocks like this it's implicit. Unless somebody knows that you wouldn't be able to infer what the behavior is like. Do we have a question? Is this behavior a part of like a design philosophy or is it just a quirk? You would have to just blame on the type. This is a quirk I would say. No but why can't we fix it like when you have EC at my fire? That's the drain of the web. I mean if you go and do this go fix the lack of it. There are so many blocks in JavaScript. I don't know just fix it. I don't know how many websites just stop working. Maybe somebody wrote code knowing that this is happening and they're picking advantage of it. I don't know. See that's the thing about shipping code. Once you ship it, you just start with it. Whatever it's supported. So being really careful with foolishness, that's the same thing with APIs. Once you put an API out there, unless you want to piss your developers off, stick with your API. You can't change that. There isn't an alternative for JavaScript. Alternative for JavaScript? I mean I don't know. If you are Google then there is. There is. That's like a method. Language on top of it. It's on top of JavaScript. It's a compiler for JavaScript. JavaScript is a language where it language JavaScript. Google is coming out with a language called what? DRT. DRT. DRT. If Google had its way then everybody would start JavaScript. But I don't think that's going to happen. We just have to stick with this for a very long time. Otherwise we won't have this content. But ultimately the others execute JavaScript. We have to convert that. It doesn't matter. CopyScript is good. I actually like the language and some of these constructs are really nice. Ultimately it just compiles and produces JavaScript and it runs in your browser. It produces good quality JavaScript. Should we start off with these? Should we focus on JavaScript or JavaScript? I would recommend that. Focus on JavaScript. Learn what it does. I don't know what's the status of the problem currently. Because what is actually running in the browser is JavaScript. If you have a problem how do you debug? You have to understand JavaScript code. You have to understand JavaScript code. So you're writing in JavaScript but debugging in JavaScript. A lot of languages are already taking a lot of famous languages are taking copy script. So what about that? That's good. So you can use all the best practices. But as of today JavaScript doesn't seem to have a good story around debugging. Maybe they'll fix it. But right now if you want to debug your browser that is in your browser. Let's say one particular annoying user tells you that this is not working for me. So you have no option other than to debug the browser. Even to a learning point of view I think it makes sense to know what's actually going on. So learn JavaScript. Because the user when you write in copy script sometimes because of the white space issues it generates a different code that you expect. Really? That's a personal view. So what does it work for the first time when you thought something else and because you have a tab instead of space and made something else? Maybe you can try using editors. The same thing is like Python. White space significant. So if we run out of time we'll do that. So we really have enough time. So we'll take it off. Thanks. Thank you very much.