I just started loading my streaming TNG episode, intending to watch it immediately, but then I thought I could better let it load for a while, while I gave private static some more thought. (Yes, last time I wrote about star trek I was at the first episode of DS9 and now I am halfway TNG. I tend to go through series at a reasonable pace - there was some time of not watching any Start Trek between watching DS9 and TNG.) Well... let's just say Javascript is powerful, really believe me! Now!
Oh man, the solution is so simple yet so good. All I did was declare an anonymous function that encapsulates both our class definition and our static functions and call that function right away. This requires a little change in syntax to make the class available outside that function, but that truly is a piece of cake. Once that is done, our private static variables can live in this new class.
It truly is amazing how powerful javascript is.
Sunday, October 25, 2009
Jasoop Redesign
I have been typing for the documentation of Jasoop - which is what I called my style of javascript oop I talked about two days ago (technically yesterday, but not in reality).
And now I have already decided that I am going to change it all already. Here's the story.
I had thought of a way to create static functions, however, I had not realized that it would fail if the function was later redefined. Of course, this does not really matter for functions, but it did mean that I could not use the same technique for static variables. So I was once again posed the same question: how to design static in Jasoop.
I did come up with an answer: if each static property would be an object with one property (say static) I could write some code to make sure these variables were static, while keeping the syntax rather clean. Alright you would now have to type "varName.static", but that's hardly a loss. Then it hit me, if I reversed the syntax there, the code to make the variable static would be (ironically) static, rather than depend on the static variables - and I would get a nicer syntax to boot. Say it yourself: "static.varName". Isn't that much better?
My next issue was deciding whether to use the same syntax for functions or not (I mauled this all over in my head while cooking my dinner). My first impulse was not to do so, because I thought not having to write that static there would just feel much more natural. In the end, the uniformity for variables and functions did win - partly due to an argument that is really nonsense, but I only realize that while writing this. Oh, and don't worry, currently I have more than enough reason to keep it the way it is. The door was now ajar.
Next I thought of a way to create protected variables. I did think of a way (giving the class a return value if it was not called with the new operator), but that did leave me with two challenges: how to differentiate them from private variables and how to pass them through a single return value. Both questions had a single answer, I could simply use the syntax I just made up for static variables. "protected.varName" makes sense, right? Suddenly the door was swinging wide open.
And then opportunity presented itself. I could get rid of all those differences between the variables with different access levels, while getting rid of that ugly _this variable I had to introduce. Man, it cleaned up the syntax, it sure did. I was standing in front of an open door and the other side was much more beautiful than this one - needless to say I went through.
So now, inside the class we have "public.publicVar", "protected.protectedVar", "private.privateVar" and "static.staticVar". One little thing to note is that all static variables are public, but as of yet I do not see any way I can change that (unless static functions are defined outside the "class definition" they can only be accessed once the first object of the class has been created, and outside the class definition you cannot reach protected or private variables).
From the outside you can reach "object.static.varName" and public variables in some way, but I am not sure yet whether that will be "object.varName" or "object.public.varName". Perhaps it will make itself clear once I have found a way to make static variables with different access levels.
Anyway, Jasoop is coming to life and I am pretty sure the result will be nice and it will probably even include features not yet seen in javascript (protected variables, to name one thing).
And now I have already decided that I am going to change it all already. Here's the story.
I had thought of a way to create static functions, however, I had not realized that it would fail if the function was later redefined. Of course, this does not really matter for functions, but it did mean that I could not use the same technique for static variables. So I was once again posed the same question: how to design static in Jasoop.
I did come up with an answer: if each static property would be an object with one property (say static) I could write some code to make sure these variables were static, while keeping the syntax rather clean. Alright you would now have to type "varName.static", but that's hardly a loss. Then it hit me, if I reversed the syntax there, the code to make the variable static would be (ironically) static, rather than depend on the static variables - and I would get a nicer syntax to boot. Say it yourself: "static.varName". Isn't that much better?
My next issue was deciding whether to use the same syntax for functions or not (I mauled this all over in my head while cooking my dinner). My first impulse was not to do so, because I thought not having to write that static there would just feel much more natural. In the end, the uniformity for variables and functions did win - partly due to an argument that is really nonsense, but I only realize that while writing this. Oh, and don't worry, currently I have more than enough reason to keep it the way it is. The door was now ajar.
Next I thought of a way to create protected variables. I did think of a way (giving the class a return value if it was not called with the new operator), but that did leave me with two challenges: how to differentiate them from private variables and how to pass them through a single return value. Both questions had a single answer, I could simply use the syntax I just made up for static variables. "protected.varName" makes sense, right? Suddenly the door was swinging wide open.
And then opportunity presented itself. I could get rid of all those differences between the variables with different access levels, while getting rid of that ugly _this variable I had to introduce. Man, it cleaned up the syntax, it sure did. I was standing in front of an open door and the other side was much more beautiful than this one - needless to say I went through.
So now, inside the class we have "public.publicVar", "protected.protectedVar", "private.privateVar" and "static.staticVar". One little thing to note is that all static variables are public, but as of yet I do not see any way I can change that (unless static functions are defined outside the "class definition" they can only be accessed once the first object of the class has been created, and outside the class definition you cannot reach protected or private variables).
From the outside you can reach "object.static.varName" and public variables in some way, but I am not sure yet whether that will be "object.varName" or "object.public.varName". Perhaps it will make itself clear once I have found a way to make static variables with different access levels.
Anyway, Jasoop is coming to life and I am pretty sure the result will be nice and it will probably even include features not yet seen in javascript (protected variables, to name one thing).
Saturday, October 24, 2009
Javascript OOP
Go ahead, try googling "javascript oop". Or you you can just take it from me: you'll get a thousand ways to do object oriented programming in javascript.
Don't get me wrong, javascript a very powerful language. And I really mean very powerful. Most people working with it, though do not know its full power. For example, javascript lets you write curried functions - the syntax will be strange, but you will have curried functions, meaning you can actually go and use javascript as a functional programming language (oh, it will look horrible, but the point is that you can).
As I said, there are a lot of ways to do object oriented programming in javascript, and it appears there are few people who use the exact same way. There is a way that s default in javascript, but it has its limitations, which - as powerful as javascript is - you can work around. I picked up a style in this that turns out not too be all that common, used some more common elements in it and even added a little that is completely my own.
So that is why I decided that I am going to document this stye of object oriented programming and all its powers. For example, the model supports private data and functions, has its own (but really solid) way to define inheritance. I will document not only how to do something, but also why it is done in this way and not in some other way.
First and foremost, this will be a reference for me, so I can write consistent OOP code in javascript and so I can use powerful features - such as static functions - without first having to dig through old work to see how I did that again. However, I will make it available for others to use, as it can be a useful guide how to achieve some standard OOP features in javascript - and one might even consider using the style as a whole in order to be consistent in one's own work while having a number of powerful features at your disposal.
I do not know how I will exactly provide this documentation, right now I am just typing out the text that documents it. However, I will get back to you on that point.
Don't get me wrong, javascript a very powerful language. And I really mean very powerful. Most people working with it, though do not know its full power. For example, javascript lets you write curried functions - the syntax will be strange, but you will have curried functions, meaning you can actually go and use javascript as a functional programming language (oh, it will look horrible, but the point is that you can).
As I said, there are a lot of ways to do object oriented programming in javascript, and it appears there are few people who use the exact same way. There is a way that s default in javascript, but it has its limitations, which - as powerful as javascript is - you can work around. I picked up a style in this that turns out not too be all that common, used some more common elements in it and even added a little that is completely my own.
So that is why I decided that I am going to document this stye of object oriented programming and all its powers. For example, the model supports private data and functions, has its own (but really solid) way to define inheritance. I will document not only how to do something, but also why it is done in this way and not in some other way.
First and foremost, this will be a reference for me, so I can write consistent OOP code in javascript and so I can use powerful features - such as static functions - without first having to dig through old work to see how I did that again. However, I will make it available for others to use, as it can be a useful guide how to achieve some standard OOP features in javascript - and one might even consider using the style as a whole in order to be consistent in one's own work while having a number of powerful features at your disposal.
I do not know how I will exactly provide this documentation, right now I am just typing out the text that documents it. However, I will get back to you on that point.
Subscribe to:
Posts (Atom)