Sometimes dreams do come true.
However, your dreams may turn out to be something quite different from what you thought it to be.
As Mark Rosewatter once wrote: "infatuation is an important rite of adolescence". Now, by no means do I claim I am an adolescent as I write this - nor do I claim that how things happened to me is in any way similar to how they happen to most people, but this is a story about an infatuation.
It's been quite a while since I got to the stage where I was "over" the girl in question. That is, the point where I could honestly say I wasn't in love with her any longer. But that was not where it ended, that was not where this chapter closed.
Oh, believe me, I am not talking about a period in which I was lovesick or even thought about her. No that had indeed passed. However, I still saw the girl from time to time and also from time to time there was some tension - or at least there was tension from my point of view, this really doesn't mean it was also there from hers. I knew I was on thin ice. Saying that I carried a torch for her pretty much covered it.
One day, when I was thinking about how this chapter just had not closed yet for me, I realized when it would be closed. It would be closed when the time came that she asked me how I felt about her and I could tell her that some things best remain a mystery (or something less cheesy and obvious in the same vain). It was a stupid thing to think that such a conversation would come to pass - after all, that's just not how conversations work.
Sometimes dreams do come true.
And indeed no such conversation was ever held. Nevertheless, I recently had an encounter with the girl which makes me believe this chapter has finally closed. I saw her as an attractive girl - an attractive girl and no more than that. And we may not have had an explicit conversation about this, but I acted like that as well. And I knew this was no lie.
However, your dreams may turn out to be something quite different from what you thought it to be.
I knew this because inside of me there was absolutely no difference between her and another attractive girl that was there at the moment. It took a while before I realized, but this was the "conversation" I had dreamed about. The chapter had finally closed.
When you are a straight boy and someone else is an attractive girl there is a chance that something happens. I would consider this extremely unlikely to be the way things turn out. But I can have the peace of mind that if the universe pulls a joke on me and that is the way all of this turns out, it will be in a new chapter, not in the closing act of this one; that closing act has passed already.
Saturday, June 19, 2010
Wednesday, April 21, 2010
YuGiOh Rebirth
Have you ever played that YuGiOh game by Edo? (link)
If you have, you are in luck. While Edo stopped development of the game in 2007 and left us with a program that was far from done, I have decided to remake the game. Please visit www.yugiohrebirth.uni.cc and have a look!
If you have not, this is your chance to play the game... I can't be sure you like it, but if you like yugioh or cheesy storylines, there is a good chance that you will. This is not about competitive playing of the game, this is just for enjoying yourself and having some fun. And the cheesy storylines do really match the style of Yu-Gi-Oh!
Anyway, that's all I had to share with you at this very instant, so see you all later!
If you have, you are in luck. While Edo stopped development of the game in 2007 and left us with a program that was far from done, I have decided to remake the game. Please visit www.yugiohrebirth.uni.cc and have a look!
If you have not, this is your chance to play the game... I can't be sure you like it, but if you like yugioh or cheesy storylines, there is a good chance that you will. This is not about competitive playing of the game, this is just for enjoying yourself and having some fun. And the cheesy storylines do really match the style of Yu-Gi-Oh!
Anyway, that's all I had to share with you at this very instant, so see you all later!
Sunday, October 25, 2009
My hat goes off to javascript
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.
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.
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).
Subscribe to:
Posts (Atom)