Well folks, it's that time of year again. Time to set goals with the best of intentions and aim high to better myself. I'm borrowing quite a few of my new years resolutions from last year, there were a couple that didn't go as well as I had hoped. Daily time for devotions, reading, and mediation tops the list. More frequently journaling and blogging also made the cut.
I noticed a handy goal tracking website on Lifehacker which I'm using at the moment. However, I often find that the online nature of tools used to track things like to-do lists and finances can create a small inconvenience which leads to an eventual breakdown. A plain old pen and paper still holds an important place.
In any case, here's to a new year and to best-laid plans.
Tuesday, January 01, 2008
Friday, December 21, 2007
An open source JavaScript library: q12
I've written some JavaScript utility functions as part of my ongoing wiki/note taking application. It is growing into a full fledged Ajax application with a web server and now a minimal Ajax library which I've decided to release as a separate open source project.
From the project's front page:
From the project's front page:
Writing your own Ajax library is also a great way to learn JavaScript (IMHO). I'll be making little tweaks as I work further on my project, it's getting quite close. I think I've probably said that before but rewriting from scratch tends to set one back a bit. Third iteration's the charm?I found myself needing a few common utilities as I was writing an Ajax application. Rather than use a heavyweight or verbose library, I wanted something compact that minimized the amount of typing I needed to do. This is where the name q12 comes from, just three little keys up there in the upper left corner of the keyboard.
This library provides functions for the following:
- Basic DOM manipulation
- Asynchronous HTTP requests with callbacks
- Class methods and inheritance
- Base64 encoding and other forms of data escaping
- AES encryption
Wednesday, December 05, 2007
One Laptop Per Child, Give One Get One
If you are looking for a cheap, power efficient, portable laptop for wireless web browsing and programming, like I was, consider the XO Laptop from the One Laptop Per Child association. I ordered one to keep and one as a donation through the Give One Get One program. It looks like it will be a lot of fun, I'm especially interested in the wireless mesh networking and social aspects to using the laptop. Some of the the music software looks like fun as well.
I'm ordering one for mostly selfish reasons, but this is probably my first computer purchase which will benefit someone else. Who knows, perhaps a child in a developing nation will discover a new world of seemingly limitless possibilities through programming just like I did as a child. This is my personal take on the vision behind this unique program. The opportunity to order one is slipping away fast, the offer to buy one and give one away ends December 31st. Let me know if you've ordered one, perhaps we can organize a laptop party (Arne I'm looking at you ;-)
I'm ordering one for mostly selfish reasons, but this is probably my first computer purchase which will benefit someone else. Who knows, perhaps a child in a developing nation will discover a new world of seemingly limitless possibilities through programming just like I did as a child. This is my personal take on the vision behind this unique program. The opportunity to order one is slipping away fast, the offer to buy one and give one away ends December 31st. Let me know if you've ordered one, perhaps we can organize a laptop party (Arne I'm looking at you ;-)
Labels:
laptop,
one laptop per child,
xo laptop
Thursday, November 29, 2007
Something like Lisp
Ever since compilers class in college, I've toyed with the idea of creating a new programming language. Every year or so a spend a few days thinking about one and get off to a short start. The problem is I often try to bite off more than I can chew and start dealing with the most difficult parts first. So I recently decided to get a minimal language up and running. Something with simple syntax, no concern for efficiency, and an easy to build base.
Lisp has some of the simplest syntax of any of the languages I've worked with (perhaps with the exception of BF). I was looking for something simple which I could quickly implement, so I used it as a model and created an interpreter in Python. The whole project took just a couple of hours, but I was able to write an interpreter that would run the following program:
As you might have guessed, this program displays the following in the terminal:
I just made up this micro language, and haven't given this a great deal of thought. The idea was to create something quick and dirty to create a working interpreter, rather than the usual of intense planning without a working prototype. This language will probably never see any further development. It was a mental exercise, but I found it quite enjoyable. If you'd like to see the source code for the interpreter, please let me know (I get the feeling Matt might be somewhat interested).
Lisp has some of the simplest syntax of any of the languages I've worked with (perhaps with the exception of BF). I was looking for something simple which I could quickly implement, so I used it as a model and created an interpreter in Python. The whole project took just a couple of hours, but I was able to write an interpreter that would run the following program:
set[x 5]
set[x add[1 2 3 4 5]]
set[y add[1 2]]
println[get[x]]
println[get[y]]
As you might have guessed, this program displays the following in the terminal:
15I implemented a simple parser using Python's regular expression module
3
re (The group method can come in quite handy), and I defined each of the above functions in a dictionary which maps function calls in my custom language to functions in a Python script which I import. You might have noticed that each of the methods is designed to take a variable number of arguments (thought only they may not all be used), and all function calls are made recursively, with nested functions being evaluated first. The syntax looks slightly like s-expressions but it's a bit more accessible for someone who has worked with C-like languages (except there's no need to reach for the shift key for those tricky parenthesis). I haven't added a mechanism for lambda expressions yet, but defining new functions might look something like this: function[my_fun group[x y] group[multiply[x add[x y]]]]The above would define a function named
my_fun which takes two arguments, and multiplies the first by the sum of the two arguments.I just made up this micro language, and haven't given this a great deal of thought. The idea was to create something quick and dirty to create a working interpreter, rather than the usual of intense planning without a working prototype. This language will probably never see any further development. It was a mental exercise, but I found it quite enjoyable. If you'd like to see the source code for the interpreter, please let me know (I get the feeling Matt might be somewhat interested).
Monday, November 12, 2007
Fluxbuntu 7.10
Long time readers may remember the saga of my old laptop (a Compaq Presario 1700T circa 2000). I had ditched openSUSE several months ago in favor of Fluxbuntu, a variant of Ubuntu which used the light weight Fluxbox windowing system in place of the Gnome desktop. My old computer has only 128 megabytes of RAM, so memory is at a very high premium. With the release of Gutsy Gibbon, Fluxbuntu picked up a few new features, so I upgraded and gave it a try. I have been extremely pleased. All the good stuff is there that I enjoyed before (installing new free software using Synaptic or Aptitude, Firefox, XMMS, etc.) but there were a couple of great new additions. For one, automounting of USB drives. I have a small pen drive that I carry around to hold many of my files: music, programming projects, etc. Mounting had always been a bit of a pain with my laptop's OS. Now I just plug it in, it mounts, and an icon for the drive appears on my desktop.The discovery came at a perfect time. My in-laws decided they wanted to resurrect an old PC so they could browse the web side by side. All they really needed was Firefox, Open Office, and Picasa and their computer had the same amount of RAM as my old laptop (probably from about the same time frame). Fluxbuntu to the rescue ;-) Can you believe it, my in-laws are running Linux.
Labels:
fluxbuntu,
laptop,
linux,
open source
Thursday, November 08, 2007
IE, XMLHttpRequest, and caching
I recently noticed an oft cited irritation with using XMLHttpRequest in Internet Explorer. Turns out, the browser intercepts HTTP GET requests made from within JavaScript and gives your Ajax application a cached response instead of fresh data.
I was running some tests on scorpion_server, using the JavaScript client in the example that I've packaged with the server, and I noticed that I could change the data stored in a resource when using IE6, but I couldn't get the value I had just set. This means my client-server pair is pretty much useless in IE6 (probably 7 too). But I thought of a solution. IE is just performing a test for exact match when checking the cache, so if any part of the URL is different, IE will actually perform the query like I want it to. So I added a timestamp URL parameter to all GET requests made by the client if the browser is IE, and I configured the server to ignore all URL parameters on GET requests. I wasn't using them anyway, perhaps someday I will, but I don't foresee a need because all I want is a super simple remote data store. (Who knows, YAGNI might just be my new mantra.)
Note that IE was the only browser (of those I tested) that exhibited this annoying behavior. Mozilla based browsers (Firefox, SeaMonkey, Flock), Opera, and Safari all behaved correctly and don't require the timestamp URL parameter hack.
I was running some tests on scorpion_server, using the JavaScript client in the example that I've packaged with the server, and I noticed that I could change the data stored in a resource when using IE6, but I couldn't get the value I had just set. This means my client-server pair is pretty much useless in IE6 (probably 7 too). But I thought of a solution. IE is just performing a test for exact match when checking the cache, so if any part of the URL is different, IE will actually perform the query like I want it to. So I added a timestamp URL parameter to all GET requests made by the client if the browser is IE, and I configured the server to ignore all URL parameters on GET requests. I wasn't using them anyway, perhaps someday I will, but I don't foresee a need because all I want is a super simple remote data store. (Who knows, YAGNI might just be my new mantra.)
Note that IE was the only browser (of those I tested) that exhibited this annoying behavior. Mozilla based browsers (Firefox, SeaMonkey, Flock), Opera, and Safari all behaved correctly and don't require the timestamp URL parameter hack.
Labels:
JavaScript,
programming,
scorpion server
Sunday, November 04, 2007
JavaScript client for my Scorpion Server
I've added a JavaScript client to the simple web server project: scorpion server. The client is able to set the username and password and make authenticated GET and POST requests to retrieve and modify resources on the server. Now that this portion is complete, I'm ready to rebuild my Ajax Wiki application to run on top of this simple web server.
Labels:
JavaScript,
programming,
projects,
scorpion server,
web server
Saturday, October 27, 2007
Hey look, a simple web server
I think I'm done writing my web server. I have gotten it to do what I want, namely this. This server will:
I've also been looking at CherryPy as a framework to create the same type of portable, simple, and secure web server. As usual, stay tuned for details.
- Run just about anywhere. I sometimes run it off of a USB pen drive.
- Send all traffic over an HTTPS connection.
- Handle user authentication and permissions. You can only read and write where you have permissions.
- Allow you to store data in a remote location. Just POST to a URL to store something at that location, GET to retrieve it.
I've also been looking at CherryPy as a framework to create the same type of portable, simple, and secure web server. As usual, stay tuned for details.
Wednesday, October 24, 2007
Varieties in Code Design
One of the interesting things about writing software is the myriad of ways to express what it is that you would like the computer to do. When designing a class, function, or something else, you can make the syntax looks just about any way you like. The real interesting bit, is when multiple people need to work on a large project together. Everyone needs to be able to understand the code, so it's probably a good idea if you agree on code conventions beforehand. All of the below would do equally well, but which is most clear?
x = a + 5;
x = a.plus(5);
x = 5.plus(a); (You could do this in Ruby/)
x = plus(a, 5);
plus(a, 5, x);
a.plus(5, x);
set(x, plus(5, x)); (This looks a bit like Lisp.)
The list goes on and on.
Tune in next time for simple Python web-server fun.
x = a + 5;
x = a.plus(5);
x = 5.plus(a); (You could do this in Ruby/)
x = plus(a, 5);
plus(a, 5, x);
a.plus(5, x);
set(x, plus(5, x)); (This looks a bit like Lisp.)
The list goes on and on.
Tune in next time for simple Python web-server fun.
Labels:
code conventions,
programming,
style
Thursday, October 18, 2007
Design for the simple secure storage server
In my last post, I mentioned my motivation for writing this server and pointed to the foundation I'm building on. Now it's time for more detail.
This server may not be supper fast (single thread execution) and it may not be super secure (user data stored in plaintext on the server) but it will be super easy to set up.
Allow me to clarify the security point in the above summary. In the initial version of this server, all traffic will be sent over an SSL connection (HTTPS) and users will authenticate with the server using Basic Auth. In Basic Auth, the users password is sent to the server in plaintext. There are better authentication schemes out there, but for this version of the server, I'm going for quick and simple. Basic Auth is just barely acceptable for this project because the connection is secure, but the server will likely store these passwords in plaintext as well (for now) so server disk security may be the weak link. With that said, the idea for this server is to provide a simple and portable back-end for my AJAX applications.
This server may not be supper fast (single thread execution) and it may not be super secure (user data stored in plaintext on the server) but it will be super easy to set up.
Allow me to clarify the security point in the above summary. In the initial version of this server, all traffic will be sent over an SSL connection (HTTPS) and users will authenticate with the server using Basic Auth. In Basic Auth, the users password is sent to the server in plaintext. There are better authentication schemes out there, but for this version of the server, I'm going for quick and simple. Basic Auth is just barely acceptable for this project because the connection is secure, but the server will likely store these passwords in plaintext as well (for now) so server disk security may be the weak link. With that said, the idea for this server is to provide a simple and portable back-end for my AJAX applications.
Thursday, October 11, 2007
A simple HTTPS server
Recently, I've been working on an AJAX application in my spare time and there's something I could really use: a simple network data store.
A JavaScript application isn't very useful without some persistent data. However this usually requires running a web server. My original idea was to distribute the application as a file which is loaded from the local disk. At this point you may be saying, "Wait a minute JavaScript running in a browser can't access the local disk." But scripts can read and write to the local disk if they are loaded from disk instead of the Internet. See TiddlyWiki for a great example of a useful application that uses this design. The problem though, is what happens when you want to sync the data from the AJAX application across multiple computers. Well, once again, it looks like I need a web server after all.
So I set out to build a simple server. All it really needs to do is allow applications to store and retrieve data. To make sure that the data remains a secret, the traffic will be sent over an HTTPS connection. Access to certain directories and files on the server will be granted only to select users, so usernames and passwords are required too. Since I've been working with Python recently, I tried to see if it was possible to create a simple HTTPS server which could handle GET and POST requests and perform dynamic behavior. I found a great example on activestate.com which uses an open SSL .pem file. The instructions in the article made setting up this server a breeze. I've been working on a customized version of the above example, but it isn't quite ready. As usual, stay tuned :)
A JavaScript application isn't very useful without some persistent data. However this usually requires running a web server. My original idea was to distribute the application as a file which is loaded from the local disk. At this point you may be saying, "Wait a minute JavaScript running in a browser can't access the local disk." But scripts can read and write to the local disk if they are loaded from disk instead of the Internet. See TiddlyWiki for a great example of a useful application that uses this design. The problem though, is what happens when you want to sync the data from the AJAX application across multiple computers. Well, once again, it looks like I need a web server after all.
So I set out to build a simple server. All it really needs to do is allow applications to store and retrieve data. To make sure that the data remains a secret, the traffic will be sent over an HTTPS connection. Access to certain directories and files on the server will be granted only to select users, so usernames and passwords are required too. Since I've been working with Python recently, I tried to see if it was possible to create a simple HTTPS server which could handle GET and POST requests and perform dynamic behavior. I found a great example on activestate.com which uses an open SSL .pem file. The instructions in the article made setting up this server a breeze. I've been working on a customized version of the above example, but it isn't quite ready. As usual, stay tuned :)
Wednesday, July 18, 2007
New Domain and A New Project
A quick update on the domain name, I've registered jeffscudder.com and set up an email account, so you may be getting some mail from a new address the near future. I'm still looking for an idea on a domain to register for hosting projects. I'd like to get a name where my friends and I can all hook our email monikers (I don't imagine anyone wants to be bob@jeffscudder.com).
I've been working on a new project. I'm a huge fan of tiddlywiki, I've been using it almost a year now for keeping my notes organized. As I've continued to use it, I've found three things I would like to change:
I leave you with a song that has been stuck in my head all of last week: Deathbed by Relient K.
I've been working on a new project. I'm a huge fan of tiddlywiki, I've been using it almost a year now for keeping my notes organized. As I've continued to use it, I've found three things I would like to change:
- Contents are saved in plaintext. I carry my tiddlywiki around on a pen drive and some of the notes contain personal information that I'd like to keep safe. Plus, I like playing with cryptography.
- Notes are saved to a local file. This is both a strength and a weakness, the problem is I sometimes use multiple computers and I want to easily move between them. I'd like to have the option of saving to a local file or a server.
- It is sometimes slow. There is a lot of eye candy and it is very customizable, but I just want something lighweight, small, and simple.
I leave you with a song that has been stuck in my head all of last week: Deathbed by Relient K.
Labels:
domain name,
jeffscudder.com,
projects,
relient k,
tiddlywiki,
wiki
Friday, June 01, 2007
Domain Name Ideas
I've been thinking about getting my own domain for some time now, and I've finally decided to make the leap. The only problem now is that pesky task of choosing. I have a few ideas, but I'd like to hear what you guys come up with. Think of it as a distributed brainstorming session, no idea is too strange. (I was inspired by a discussion on Yed's blog where we helped him choose custom license plates.) I'm keeping the post short and sweet, stay tuned for details.
Wednesday, May 02, 2007
China Trip - Part 5


I will close my retelling of our China trip with our days in Hangzhou and Shanghai. (The Wikipedia articles have great pictures of many of the sites I took pictures of, including the tea plantations and Shanghai's waterfront.) In Hangzhou, we began with a boat ride on the West Lake and took a walk through the gardens nearby. We also visited a tea house and sampled traditional green tea. The next day, we traveled to Shanghai. There, Vanessa and I saw the new developments and skyscrapers which have sprung up over the past few years. It is a city which is growing extremely rapidly, yet all of the land is still owned by the government. They have started a lease program, in which an entity can get a lease from the government to use the land for 70 years. When property changes hands, the lease isn't renewed, you only have the remaining time on the original lease. Some of the real estate prices were outrageous (even by California standards) if you consider that you may only have your property for 50 years before the government can take it back. I imagine this system will seem extremely odd to most Americans. While we were in the waterfront we saw the construction of what will be the tallest building in the world, when it is completed before the 2008 Olympics.In closing, I offer some reflections on the trip. We saw amazing sights, experienced a different culture, and met new and interesting people. Several thoughts occurred to me as I think over my journey, I noticed that their culture had common themes and ideas. Similar stories, values, and ideals, it seems that in some ways, the core of most societies is very much alike. I was also struck by the pace of growth, it seems that China is an economic force to be reckoned with, and they appear to be rapidly expanding. Perhaps I saw only the "good parts"; my view may be inaccurate. Perhaps my view was colored by the pessimism which people say is characteristic of my generation when it comes to our nation's future. Perhaps I was just tired of the Chinese food ;)
Labels:
China,
Hangzhou,
Shanghai,
Tea Garden
Tuesday, April 17, 2007
China Trip - Part 4


We begin this installment of our ongoing series on our China trip in my favorite location. The Lingering Garden is a masterpiece of architecture and oriental style gardens complete with bonsai trees (However, it was devoid of bonsai kittens). I'm not surprised that Chinese poets came to this garden to find inspiration in beautiful Suzhou. I could have easily spent a few more hours walking around the pond and I can't believe that the entire complex of gardens and buildings once belonged to one family.The third picture in this post is from the leaning Huqiu Tower in Suzhou. The brick work on the structure was amazing and it is older than the Leaning Tower of Pisa. Vanessa took this one from a plaza to the side of the tower. Next time, I'll write about the very end of our trip in Hangzhou and Shanghai.
Labels:
China,
Huqiu Leaning Tower,
The Lingering Garden
Tuesday, March 20, 2007
China Trip - Part 3


There were only a few moments where we caught a glimpse of what everyday life is like for the people of China and a couple of them came on this day of traveling. We continued our journey with a rickshaw ride through some of the older areas of Beijing and then we took a trip to the Temple of Heaven. As we walked the long corridor to the temple, we saw a large group of people playing cards, dancing, and making music. It was a glimpse of life that I would like to have taken part in, but I felt like an outsider. I'm still not sure what card games they were playing. The Temple of Heaven was a breathtaking structure and from the top of the hill you could see the entire city.
Labels:
China,
rickshaw,
Temple of Heaven
Tuesday, March 13, 2007
China Trip - Part 2


I'm picking up my narrative on the second half of the first full day in which we visited the Great Wall. It was absolutely breathtaking and the pictures don't do it justice. You could see the wall winding through the mountains for miles standing dark against the new fallen snow.The next morning, we visited Tiananmen Square and the Forbidden City. It was extremely cold when the wind picked up, but the sights were impressive. The Forbidden city is quite a palace, and the bold colors and detailing have been recently restored in preparation for the Olympics. One of the largest buildings was still under wraps. I was struck by the size of the palace. As I walked through the last few corridors I thought I was nearing the end only to walk into a massive courtyard. I think it was about seven courtyards, but don't quote me on it. (Check out the satellite image on Google Maps.) In my next post, I'll write about our rickshaw ride through Beijing and our visit to the Temple of Heaven.
Sunday, March 11, 2007
China Trip - Part 1


Vanessa and I just got back from our trip to China and I'm going to spread out some of the details over several days. We took over eight hundred pictures, so I'll be sharing a few from each of the days. In this first (of many) posts about the China trip I'll talk about our first day of sight seeing in Beijing.It snowed on our first morning in China and it was a welcome if not shocking change from the weather back home. I've been missing the snow since I moved to California so it was good to be in it again, even if it made walking around a bit difficult. We started the day with a short tour of the Summer Palace, which was a gift from the emperor to his mother for her 60th birthday. It was quite a gift, a man made lake and acres of gardens.
After seeing the palace, we traveled to the Ming Tombs and visited the largest tomb. The buildings were massive and filled with artifacts buried with the emperors of days long gone by. The styles and designs of the ancient crowns and armor were very interesting and not quite what I was expecting. If you'd like to see more pictures, I'll point you to a place where you can view them. Tune in for more details from the trip in the very near future.
Labels:
China,
Ming Tombs,
Summer Palace
Wednesday, February 28, 2007
We're going to China
My wife and I leaving for China in the very near future. We're both really excited, I've never been to the eastern hemisphere before and I'm looking forward to experiencing a different culture. The trip will also give Vanessa plenty of opportunities to practice her Chinese.
I'll have a vast array of experiences to share with you, gentle reader, upon our return. So for now I'll leave you with some half finished thoughts. I started no less than three blog posts over the past two weeks, but they are all sitting as unfinished drafts. Here's a brief summary of one of the things I started to talk about. (In the end it turned out to be not quite so brief.)
Cellular Automata
I've been looking into Cellular Automata recently as a source for complex data interactions. There has been some discussion among cryptographers about the use of cellular automata as possible pseudo random number generators. The best known example of a cellular automata is John Conway's Game of Life and I think it illustrates the kind of complex interactions which can occur within a cellular automaton, even though it is a "universe" with very few rules.
I started to look at the behaviors in Wolfram's rule 30 and rule 110 cellular automata because those have been selected as possible candidates for cryptographic systems. I wrote a program to evaluate patterns produced by these rules in a finite two dimensional field which wraps on both ends. I think I may have found other rules which may also prove promising for cryptographic use, but I need to do more evaluating. I'd ultimately like to use a three, four, or five dimensional system to see if I could build a useful PRNG but I will need to spend considerably more time ensuring that the patterns created by the rules remain complex. In the 2D system I evaluated, the vast majority of rules produces very predictable patterns.
See you when I get back.
I'll have a vast array of experiences to share with you, gentle reader, upon our return. So for now I'll leave you with some half finished thoughts. I started no less than three blog posts over the past two weeks, but they are all sitting as unfinished drafts. Here's a brief summary of one of the things I started to talk about. (In the end it turned out to be not quite so brief.)
Cellular Automata
I've been looking into Cellular Automata recently as a source for complex data interactions. There has been some discussion among cryptographers about the use of cellular automata as possible pseudo random number generators. The best known example of a cellular automata is John Conway's Game of Life and I think it illustrates the kind of complex interactions which can occur within a cellular automaton, even though it is a "universe" with very few rules.
I started to look at the behaviors in Wolfram's rule 30 and rule 110 cellular automata because those have been selected as possible candidates for cryptographic systems. I wrote a program to evaluate patterns produced by these rules in a finite two dimensional field which wraps on both ends. I think I may have found other rules which may also prove promising for cryptographic use, but I need to do more evaluating. I'd ultimately like to use a three, four, or five dimensional system to see if I could build a useful PRNG but I will need to spend considerably more time ensuring that the patterns created by the rules remain complex. In the 2D system I evaluated, the vast majority of rules produces very predictable patterns.
See you when I get back.
Labels:
cellular automata,
China,
cryptography,
travel,
wife
Friday, February 02, 2007
Simulating Classes in C - Part 2
Well the $1 C contest has come to an end after generating lots of interest but no full blown solutions. I'm okay with that, thanks to all of you who expressed interest and started on it. From conversations with several of you over chat, I know that there were some great ideas out there. If you don't mind taking the time, please describe your idea in the comments section. As my friend Matt can attest, I love discussing software, ideas, designs, and just about anything related to creative problem solving. This is probably why I really enjoyed math in high school and college. I looked at each problem as a logic puzzle which could be solved multiple ways. Finding the most elegant solution made me feel like I had just written a poem of supreme beauty.
I wrote my solution a few weeks ago, then started researching how other object oriented schemes are implemented. I found out that my code has several disadvantages and some significant advantages as well. For example, I started to comapre the likelyhood of missing the RAM cache to solutions in C++ and Java. There were a few other intersting comparisons but I won't go into all of the nitty gritty details. Overall, I'm very pleased because I learned a lot. Lets discuss!
/* JSObject functions */
void InvokeObjectMethod(JSObject* object, char* methodName,
JSListOfObjects* inputParams,
JSListOfObjects* outputParams) {
int i;
JSClass* class_of_object;
int method_index = -1;
/* Impossible to invoke a method on a NULL pointer */
if(object == NULL) {
/* ToDo: send a "NULL object" error code in the outputParams. */
return;
}
class_of_object = (JSClass*)(object->type);
if(class_of_object == NULL) {
/* ToDo: send a "NULL class" error code in the outputParams. */
return;
}
/* Find the index of the methodName in the object's class. */
/* This part of the code is O(n) efficient, but this could be
improved if the function names were sorted or if a hash
algorithm was used. Hashing could reduce to O(1). */
/* I could also allow the calling code to specify the desired
method directly by index to avoid requiring a string
lookup for each invocation. */
for(i = 0; i <>method_count; i++) {
if(strcmp(class_of_object->method_names[i], methodName) == 0) {
method_index = i;
break;
}
}
/* If the method name was not found in the list of class methods,
return an error code. */
if(method_index == -1) {
/* ToDo: send a "method not found" error code in the
outputParams. */
return;
}
/* Invoke the method at the index corresponding to the method
name. */
(*(class_of_object->methods[method_index]))(object, inputParams,
outputParams);
}
I wrote my solution a few weeks ago, then started researching how other object oriented schemes are implemented. I found out that my code has several disadvantages and some significant advantages as well. For example, I started to comapre the likelyhood of missing the RAM cache to solutions in C++ and Java. There were a few other intersting comparisons but I won't go into all of the nitty gritty details. Overall, I'm very pleased because I learned a lot. Lets discuss!
Labels:
c,
code,
object oriented,
programming
Subscribe to:
Posts (Atom)