Most of the material I have been reading so far introduces concepts which are completely foreign to me using terms that I have never even heard before (”monad”, hyukhyuk!). Some materials like “Haskell Tutorial for C Programmers” attempts to map functional programming concepts in Haskell to imperative programming concepts in C. That was my last attempt to learn Haskell prior to this current one. It starts off slow but in the next chapter it gets deep all of a sudden and I felt lost and eventually gave up.

The approach taken by “Haskell Tutorial for C Programmers” is essentially the same approach that I had taken to learn all the programming languages that I know. This approach consists of three stages:

1. Learn about all the keywords of the new language, then map them to the keywords of a language that you already know.
2. Learn how to do all the concepts using the new language like loops, branching, function definition, etc.
3. Finally, learn how to do advanced I/O like reading/writing files and talking to a network.

This approach has not failed me until I tried to learn functional programming using Haskell. I eventually gave up until better material was available and I had some spare time. I have been especially productive using Django and Python lately so I have been finding a bit of time and with a new book on Haskell available for free, I decided to give it another shot.

I am reading well into chapter 3 as I write this and so far, my brain is still chugging along nicely. I took a completely different approach to learning this time: Zen Mind, Beginner’s Mind. It is at the core of the teachings of Shunryu Suzuki-roshi. Basically it means emptying your mind of all preconceived notions and being free from expectations of what should and shouldn’t be. In this mental state, all you do is explore and observe.

The approach is working thus far. However it would not be possible if “Real World Haskell” itself was written in the same cut-and-dry approach like that found in most of the books on Haskell that I have read. The book takes on a very nice pace in the first 2 chapters so far. It introduces functional programming concepts using small, working, real-world examples. It exposes only as much of the language as it needs to and explains everything in detail without overwhelming you. Considering the depth of the subject, it looks like an excellent book written in a very engaging manner.

a

So what has changed? The most visible change is that there are now at least two separate API’s that you have to work with. You have the File API and the Storage API. The File API which exposes the File class provides a thin wrapper around Python file objects. The Storage API, on the other hand, exposes a base class Storage that you can use to implement custom storage facilities. There is another API that provides FileUploadHandler. This will allow you to customize the way Django handles the uploaded files in their “raw” form. For most purposes, the File and Storage API will suffice.

This post is meant to supplement the information found in the “Handling Uploaded Files” section of the Django File Uploads documentation. You will still need to refer to documentation.

The examples I will be using here implement basic file uploads handling in Django 1.0. The examples provided in the official Django documentation, as of 18 Feb 2009, do not give you an idea of how the File and Storage can be used together. Please note that these examples will not work with Django versions before 1.0.

The Model

Here is the model that we will be using for this example:

from django.db import models

class Attachment(models.Model):
    attached_file = models.FileField(upload_to='attachments')
    mimetype = models.CharField(max_length=64, editable=False)
    created = models.DateTimeField(auto_now_add=True, editable=False)
    updated = models.DateTimeField(auto_now=True, auto_now_add=True, editable=False)

We have marked the 3 fields that are not editable so that the corresponding form fields will not be created for them by Django’s automatic admin and django.forms.ModelForm.

The Form

Normally you would just use django.forms.ModelForm to create the form. Like so:

from django.forms import ModelForm

class AttachmentForm(ModelForm):
    class Meta:
        model = Attachment

This will take care of most use-cases where you have a simple app with one form per model. Taking it a bit further, you could just make use of Django 1.0’s excellent “automatic admin interface”. This is what you should normally do when you are just starting out with Django. However, there are times when you just want a bit more control over the way things are done. In this context, we will create a form class manually to illustrate how you would use Django’s File and Storage API.

from django import forms

class AttachmentForm(forms.Form):
    attached_file = forms.FileField()

    def __init__(self, bound_object=None, *args, **kwargs):
        super(AttachmentForm, self).__init__(*args, **kwargs)
        self.bound_object = bound_object
        self.is_updating = False
        if self.bound_object:
            self.is_updating = True

    def save(self):
        if not self.is_updating:
            self.bound_object = Attachment()
        # Retrieve the UploadedFile object for the attached_file field.
        uploaded_file = self.cleaned_data['attached_file']
        # Clean up the filename before storing it.
        import re
        stored_name = re.sub(r'[^a-zA-Z0-9._]+', '-', uploaded_file.name)
        # Save the file and its metadata.
        self.bound_object.attached_file.save(stored_name, uploaded_file)
        self.bound_object.mimetype = uploaded_file.content_type

In the example above, we used the save() method of the Attachment object’s attached_file field. The save() method’s second argument takes any object that implements the File class’ methods. All file uploads handled by Django’s default upload handlers are UploadedFile objects. Since UploadedFile is a subclass of File we can use it directly in the save() method of our file field.

By default the uploaded file will be saved on the file system under the directory structure specified by settings.MEDIA_ROOT plus the upload_to. So if you have settings.MEDIA_ROOT set to /webapp/media_root adding our upload_to setting for the model above, the file for attached_file will be saved under the directory /webapp/media_root/attached_file. Normally this directory will also be mapped to the appropriate public URL on your webserver’s configuration.

There are times however when you want to change the default storage behavior. This is where the Storage API comes in. For example we want to be able to save files in a different root directory. The problem is that you can only specify one settings.MEDIA_ROOT for your entire app. To do this, we need to pass the parameter storage to our attached_file field.

Here is our model again, this time we specify a custom storage location other than MEDIA_ROOT.

from django.core.files.storage import FileSystemStorage
from django.db import models

attachment_file_storage = FileSystemStorage(location='/webapp/attachments_root', base_url='/attachments')

class Attachment(models.Model):
    attached_file = models.FileField(upload_to='attachments', storage=attached_file_storage)
    mimetype = models.CharField(max_length=64, editable=False)
    created = models.DateTimeField(auto_now_add=True, editable=False)
    updated = models.DateTimeField(auto_now=True, auto_now_add=True, editable=False)

With our modified model, calling the save() method of the attached_file field will save the file under /webapp/attachments_root/attachments.

It does not end with customizing storage locations on the filesystem however. With the Storage API you can customize how files are actually saved by creating a subclass of Storage that overrides the appropriate API methods as documented here and here.

Django FileUploadHandler API

By default Django 1.0 handles file uploads using either django.core.files.uploadhandler.TemporaryFileUploadHandler or django.core.files.uploadhandler.MemoryFileUploadHandler. TemporaryFileUploadHandler is the default for files larger than settings.FILE_UPLOAD_MAX_MEMORY_SIZE. This handler streams the uploaded file to a temporary file saved under settings.FILE_UPLOAD_TEMP_DIR. It then wraps this file with a TemporaryUploadFile object. For smaller files, Django uses the MemoryUploadFileHandler. This handler wraps the uploaded file with a StringIO object. Either way, you get an object with a file-like interface. The only difference is where the file’s data is actually stored.

The FileUploadHandler allows you to customize the default behavior by using subclasses of FileUploadHandler and inserting them into the settings.FILE_UPLOAD_HANDLERS list. This is documented in the “Upload Handlers” section of the Django manual.

Performing Additional Processing

There are cases when you need to do more than just save an uploaded file. For instance, in a photo album application, you might want to use PIL to resize uploaded images or create thumbnails before you save them. In the examples above, we did not do any post-processing of the uploaded files and just saved them right away. It really depends on what you intend to do with the uploaded file. The most common way is to just read the file into a variable using the read() method. You must be careful when you do this however since you will overload your server if the uploaded file is too large. Use the size propery of the File object to test if a file is too large for your system to handle. You would normally do this in your form’s clean() method.

A more efficient way of applying post-processing is to stream the file and do it lazily. PIL’s Image.open() is a good example. Using PIL as an example, here is how you would apply post-processing to uploaded images. This example also shows how to use ContentFile.

from PIL import Image

def postprocess_image(uploaded_file):
    img = Image.open(uploaded_file)
    # ... do image post-processing and manipulation ...
    return img

Elsewhere, in one of your form’s methods (implemented with self.bound_object as the example above)…

def save_uploaded_photo(self):
    uploaded_image = self.cleaned_data['uploaded_image']
    # We assume that uploaded_image.size has been checked in
    # the form's clean() method and that we are good to go.
    img = postprocess_image(uploaded_image)
    if (img.format == 'JPEG'):
        processed_image = ContentFile(img.tostring('jpeg', img.mode))
    elif (img.format == 'PNG'):
        # PIL Image.tostring() does not support PNG encoding for some reason.
        imgstr = StringIO()
        img.save(imgstr, 'PNG')
        imgstr.reset()
        processed_image = ContentFile(imgstr.read())
    elif (img.format == 'GIF'):
        processed_image = ContentFile(img.tostring('gif', img.mode))

    # Clean up the filename before storing it.
    import re
    stored_name = re.sub(r'[^a-zA-Z0-9._]+', '-', uploaded_image.name)
    self.bound_object.image.save(stored_name, processed_image)

The above code is overly simplified and does not perform any additional checking of the file data or any exception handling. Do note that in the versions of PIL I am using, Image.tostring() does not support PNG encoding. This is why some additional code was needed.

At first glance, it may be a bit overwhelming. But the new API allows for greater flexibility in handling file uploads. It allows you to implement anything from custom storage to a CDN to upload progress meters. So learning how to use the new API is well worth the effort.

Please post any corrections in the comments below. Thanks.

a

Facebook, being a PHP-powered site, likes to make the assumption that you will also be writing your app using PHP. They don’t even make any efforts to hide their bias towards PHP. The “official” client library is for PHP. The example program they give to you the first time you sign up is written in PHP. All the relevant starting points all lead towards PHP-centric development.

Thankfully, there are those who realize that PHP is not the be-all and end-all to programming web applications. You can find unofficial client libraries for other programming languages. Download and install the client library for your programming language of choice and follow the documentation and hopefully you get to have everything working on your first try.

If you are programming a web-based Facebook app in Python, you will have two choices:

1. PyFacebook – a little bit on the heavy side since it comes with a framework-neutral core plus Django integration and Google App Engine support. It seems to be more actively maintained. The latest revision was on December 2, 2008 at the time of writing.

2. minifb – small. However it seems that activity has stopped since February 2008.

The choice of client library was a no-brainer for me since the site I am working on was written using Django. After downloading and installing PyFacebook I was able to get a minimal Facebook app up and running. By “up and running” I mean I can view the app’s canvas page on Facebook. However updates to my profile via profile.setFBML() do not seem to be working. After a bit of digging, I was able to find the culprit in a bug report. The modifications suggested by the issue reporter fixed the problem.

The app I was making was supposed to post updates to a Facebook Page. Facebook Pages are a relatively new feature and as a result documentation for it is a bit lacking. The IRC transcript in the Wiki page for Facebook Pages provided some useful clues. There are two things you need to ensure if you need to write a Django view that has to update a Facebook Page:

1. Do not use @facebook.require_login() decorator.

2. The uid parameter for the profile.setFBML() call must be taken from the fb_page_id query parameter.

For example:

from django.template import loader, RequestContext

def update_page_profile(request):
    # facebook attribute in request is added by FacebookMiddleware
    uid = request.GET.get('fb_page_id')
    if uid:
        ctx = RequestContext(request, {'page_id': uid})
        # Do whatever you need to do here...
        t = loader.get_template('facebook/page_fbml.xml')
        # Render the template into the profile parameter for setFBML.
        # We do not use the deprecated markup parameter.
        request.facebook.profile.setFBML(profile=t.render(ctx), uid=uid)
        # Return a redirect to the profile URL for the page.
        # Note that we do not use Django HttpResponseRedirect here.
        return request.facebook.redirect(request.facebook.get_url('profile', id=uid))
    else:
        # Do something else here if the view did not get called
        # with the fb_page_id parameter. One possibility is to check if we got
        # called with a valid user ID and do something completely different.
        pass

One other thing to note about “profile boxes” in Facebook Pages is that they do not automatically update every time you view the Facebook Page. That is, you will need to provide a way of calling the update view manually. What I did was set the update view URL as the “Page Edit URL” for the app when embedded in a Facebook Page. Ideally you should set “Page Edit URL” to output a canvas page where the page admin can update settings for the app. Because the Facebook app I was making was mainly intended for internal use, I opted out of having a dedicated “Page Edit” canvas page and instead linked it directly to the profile update view URL.

a

If you are one of those folks who have been using PHP and nothing but PHP for a long time you will be hard pressed to find an alternative. PHP is, after all, one of those things that are “easy to get into, but difficult to get out of”. PHP lures you in with its forgiving nature, vast library of pre-built extensions, ease of deployment and just plain “instant gratification”. It’s easy to forget that there are other languages for server-side programming/scripting.

More Tools for your Toolbox

When I was teaching CS classes back then, I always told my students never rely on a single programming language and never tie yourself to a single platform. I have always stressed the importance of learning more than one programming language and making sure that whatever you do, do it cross-platform if possible. By not limiting yourself to one language or platform, you will be able to develop solutions using the right tools for the problem at hand.

The following is a short list of programming languages that I have used in the past. These are my “bread and butter” languages in addition to PHP. These are also the reasons why I found it easy to ditch PHP. If you have never used any other programming language besides PHP, perhaps you should take a look at what else is out there.

One Interface Behind Them All

In theory, you can use any programming language to do server-side programming. You read that right: you can use any programming (or scripting) language. You can use C, C++, Fortran, Haskell, Java, Lisp, Lua, Perl, PHP, Python, Ruby, and so on. You can use whatever you want, as long you are able to receive input and send output via the Common Gateway Interface or CGI.

Server-side programming/scripting essentially involves two basic operations:

1. Receiving and acting on a request;
2. Sending back a response.

CGI acts as a bridge between your web server and your server-side program/script. When your web server receives a request and it sees that request as a request to execute a program/script on the server, it will set up everything that is necessary to run your program/script. It then runs the program/script, captures its output, if any, and sends it back to the client who issued the request. In Unix terms, any program/script that can take input from stdin and send output to stdout can be used on a web server that supports CGI. This is an overly simplified description. If you wish to learn more about CGI, use “the Google”.

Because the server runs the CGI program/script as an external process to handle each request, this means that there is an overhead for each request. To boost performance, modern web servers have come up with ways of eliminating or reducing the overhead from external process creation. For instance, Apache allows you to create modules that act as filters and handlers for requests. In most cases, PHP will have been installed as an Apache handler on your server which embeds the PHP interpreter in the running Apache process, eliminating the need to create an external process to run your PHP script. There is also an extension to the CGI standard called FastCGI which takes a different approach. FastCGI runs several instances of your program/script as long-running background processes. The webserver then connects to these processes whenever a requests requires the use of CGI, sends the request and collects the response and sends it back to the client.

Of course, these days you care less about the details and worry more about what your program/script does.

Is it “Programming” or is it “Scripting?”

At the heart of it, programming is programming and scripting is programming using a scripting language. In the early days, it’s easy to differentiate between “scripting” and “programming”. Scripts were written using “interpreted” programming languages which typically ran inside another program (e.g., CAD with Lisp scripting) or a stand-alone interpreter. “Programs”, in the original sense of the word, were written using “compiled” programming languages.

These days, the distinction has been blurred with the advent of compiled programming languages that are run using an interpreter. Java is just one example of this. You write your Java program and then compile it into machine-independent byte-code which you then run using a Java virtual machine or JVM. A JVM is essentially an interpreter but these days, we also have the so-called JVM with Just-in-Time compilation which maps machine-independent byte-code into native instructions for the CPU running the VM.

It’s all become so confusing these days with all the recent developments in VM technology. The distinction between “scripting” and “programming” has eroded. Personally I just prefer to call it programming. So from this point onwards, I will simply use the term “programming” to refer to “scripting” as well and “programs” to refer to “scripts”.

One more thing: Knowing how to write HTML and CSS does not make you a programmer, so please stop calling yourself a programmer or “coder” if all you know is HTML and CSS.

The Duct Tape of the Internet

Let’s begin with the grand daddy of server-side programming: Perl. Created by Larry Wall in 1987, it has evolved into a true, general-purpose programming language. It was developed primarily to automate system administration on Unix systems. It began to gain popularity in the early 1990’s as a convenient way to write CGI scripts. PHP can trace it’s origins back to a CGI script written by Rasmus Lerdorf using Perl. That’s right, a scripting language begat another scripting language. You can see shades of Perl in PHP, the most visible is the use of the $ symbol to start a variable name.

Perl may come across as a quirky, cryptic language to some. It has also been the butt of jokes in recent times with the advent of newer (and sexier) programming languages. The Perl mantra TIMTOWTDI (there is more than one way to do it) is both a blessing and a curse. Take printing a progress bar for example. As one person found out by asking the Perl monks, TMTOWTDI. But make no mistake. Perl is a very powerful language, with a friendly community and a huge library of pre-written modules.

The standard Perl installation comes with the CGI module which allows you to get up and running with CGI very quickly. You can use Perl to write a simple CGI script without using the CGI module. However, using the CGI module frees you from having to deal with a raw CGI environment. It also gives you with useful functions for handling query strings and forms, URL escaping, and error handling.

It also comes with a standard for database interfaces and drivers (DBI and DBD). DBI will usually come pre-installed along with commonly used database drivers. If you are familiar with ODBC or if you have played around with PDO, the Perl DBI is similar in spirit. It provides you with a consistent interface for database access and more importantly, it gives you prepared statements even if the underlying database does not support it.

More importantly, most virtual hosting shops support already support Perl in addition to PHP. You will probably have two options, depending on your hosting provider. First option would be to write your programs as just plain CGI programs and upload them to a special directory on your account. Second option would be to write your program to take advantage of mod_perl if it is installed by your hosting provider. mod_perl not only allows you to write CGI programs, it also allows you to create Apache modules using Perl.

Over-Engineered Beyond Help

Next up we have the programming language that no self-respecting software “engineer” can do without: Java. Although it has all the required facilities needed to write CGI programs, if you must do something in Java, you should do it properly. And the proper way of server-side programming in Java is to write a Java Servlet. In order to do that, you need to run it inside a Servlet Container such as Apache Tomcat.

Java already has database connectivity covered with its standard JDBC. Odds are that your servlet container can also run JSP’s which allow you to embed Java code in your markup. Your servlet container then takes these JSP’s, compiles them into a servlet when handling the first request and uses the compiled servlet to handle subsequent requests.

As you have probably learned by now (or not), it is better to separate your program into distinct areas using the Model-View-Controller paradigm. Java supports this out of the box. You have POJO’s (plain old Java objects) to use for your model. The servlet serves as controller. JSP provides you with the view. Once you have the basics nailed down, it’s all very simple onwards. Or not…

As your program grows in size and complexity you will find the simple MVC approach using POJOs, servlets and JSP’s become unwieldy at best. You will be looking for a better solution. Java has a standard for developing large scale web applications too. J2EE is a collection of standards that encompass everything you need to develop large scale web applications and service oriented applications (SOA’s). Newbies will probably be overwhelmed by the amount of complexity involved in developing and deploying large-scale apps using J2EE. It has more acronyms than a bowl of alphabet soup. Once you’ve finished wading through your acronym soup, prepare to swim in XML tag soup. Almost everything in a J2EE server is configured using XML. But then again, developing and deploying a large-scale J2EE app was never meant to be a job for a lone developer and there are tools you can use to tame all that XML.

As for hosting your Java apps, typically you need to find a specialized hosting service of which there is no short supply.

Ooooooh! Shiny!

Then there’s Ruby. First released to the public in 1995 by Yukihiro Matsumoto, it was an obscure programming language from Japan that exploded in popularity in recent years (due to a well-marketed web programming framework). As one fellow so succinctly put: “Ruby is the language for trendy, non-conformists.”

Ruby by itself is a very capable language with a large set of libraries included as standard. The CGI library is one of them so you can also get to writing server-side programs in no time. Like Perl and Java, it also comes with a standard library for interfacing with databases.

I tried Ruby some time early last year but I find its reliance on on begin and end to be a major annoyance at best. That’s the reason why I hated programming in Pascal and VB so much. Come on, if braces worked for C, C++, Java, Javascript, Perl, PHP, etc. why bother using whole words to delineate blocks of code? Another sticking point, at least at the time, was performance. For small one-off scripts, it’s pretty decent. However, for larger more complex programs which are spread across several files, performance really sucks! The time it takes to launch the interpreter, byte compile your code and run it was simply unacceptable for me. If you’re going to use Ruby for CGI programming, use FastCGI or some other way of keeping a cached copy of your byte-compiled code in memory.

With those two aside, I find some features that make Ruby hard to resist. There’s “monkey patching”. Ruby classes are open classes. This means two things: you can spread class definitions across multiple files and you can modify built-in or standard library class behavior. Being able to spread class definitions across files helps to make your code more manageable as it grows in complexity and size. By modifying behavior of built-in or standard library classes you’re able to create semantics that are more suited to the job at hand. This can also be a problem, especially if your program is reliant on third-party libraries, as it is possible that the modified behavior is not what you really want. But when done carefully, it can extend the usefulness of existing classes (like to what Mootools does for Javascript).

Ruby also makes it relatively simple to map data from a text file or database record into a dynamically generated class at run-time. This proves useful in creating ORM’s (object-relational mappings). Most Java ORM’s use a clunky approach glued together with unholy amounts of XML. Ruby makes it easy by providing the facilities necessary as built-ins.

Another great feature is class composition. This is similar to the concept of interfaces and mixins in other languages. You define a set of methods and properties in a module. When you need them in your class, you simply include the module.

As for finding hosting providers that support Ruby, thanks to a popular web programming framework, most hosting providers now support Ruby in addition to PHP and Perl. Just like Java however, you can get better bang for your buck by going with a specialized Ruby hosting package.

Batteries Included

Now we come to my programming language of choice: Python. While using whitespace to delimit blocks of code may seem strange to those who come from the “bracketed” programming languages such as C, Java, Perl or PHP, it actually makes your programs easy to read by default. You don’t need to remember any silly coding and indenting conventions. As long as you use a consistent means of indenting your code (4 spaces is recommended), you are pretty much set when it comes to readability. It was a bit uncomfortable at first but blocks delineated by indentation sort of grows on you eventually.

With that single “unusual” quirk aside, Python has all of the tools you need to get started with server-side programming: “Batteries Included”. Simply import the cgi module in your code and start plugging away at your program. However just like in Java, there is a standard way of doing things and the standard way of server-side programming using Python is through the use of WSGI. Python’s WSGI is similar in spirit to Java’s Servlet specification. It defines a standard way of writing programs that have to interface with a web server using a request-response model. It takes the server’s execution environment, the client’s request, and the server’s response and packages it into one coherent specification.

One more thing that I like about programming in Python is that your program sort of describes itself. You spend less time writing descriptive comments as to what a section of your code does, unlike other programming languages. Chances are that you can write a Python program now without any documenting comments, come back six months later and look at your code and you will still be able to read and understand what it does.

Performance-wise, Python has consistently outperformed PHP and Ruby as of late. Python programs are compiled into byte-code before it gets executed by the Python VM (interpreter) just like Java. However, unlike Java, there is no explicit compilation step necessary. Unlike Java, Python can run your code regardless of whether or not it is in the byte-code compiled form. Your byte-compiled Python code essentially acts as an on-disk cache for the VM. When you first run your program, the Python interpreter will byte-compile your code and if it can, it will write the byte-compiled code into a file with a .pyc extension. The next time you run your program, the interpreter will check if there is a .pyc file present. If found, it will check to see if your source file is newer than the .pyc file. If your .pyc file is up to date, the interpreter skips the byte-compilation step and runs the .pyc file instead. If your source file is newer, it will byte-compile it and try to write it to disk. This is another reason why I prefer Python over anything else. I can distribute just the .pyc files without the .py source files. I am all for “open source” but there times when you just don’t want clients to be dicking around with your code.

As for libraries, chances are good that the standard Python installation already has everything you need. Python also comes with a standard for database interfaces called DBI, which like its Perl counterpart, provides you with a consistent interface regardless of what database you are using. It also provides you with prepared statements which can be emulated in the driver in case your database does not support it.

Just like Ruby and Java, you are better off going with a specialized Python hosting package if you are going to do WSGI. If you only need to write CGI programs in Python, then many hosting providers already support Python in addition to Perl, PHP, and Ruby.

So there you have it. I hope this goes to show that PHP is not the be all and end all to programming.

a

a

Reading the IRC chat log that lead to the “backslash as namespace separator” decision just affirms my impression that the PHP language is in the hands of neurotic, crack-smoking monkeys. Well except for a few people like Dmitry. Apparently there are two problems with “::” that prove too difficult for them to solve:

1. There are some modifications needed for “::” to work properly but these modifications will break existing code. I would say, what the hell! Break existing code! PHP6 will break existing code anyway. But no, they also want namespaces in PHP5 so there!

2. The engine can’t detect ambiguity without calling autoload. It introduces the so-called “autoload bomb”. Apparently, calling autoload once for each namespace as Dmitry suggested is “impracticable[sic] because it relies on the programmer to know when ambiguity arises”. Huh?!? Forgive me but isn’t it the job of the compiler/interpreter to detect such an ambiguity and tell the programmer???

So instead of fixing the fundamental problems with the engine, they want to use the band-aid solution of adding a different syntax for namespaces. Oh wait, maybe it’s because the engine is so horribly designed that it’s impossible to write in sensible changes without having the whole thing fall apart completely?

I have been fighting so hard to keep this from swaying me away from PHP. I have lived through and worked around the inconsistencies and quirks of the language, but this “backslash as namespace separator” crap is the last straw. It sucks that I have to maintain a lot of PHP code but from this point onwards, I will no longer use PHP for new projects.

a

So, they want to replace the de facto standard namespace separator “::” with “\”. That’s right: replace double-colon with a backslash! Why? It’s because “::” is already being used in class method invocations and it will cause problems during parsing. Consider the following:

class Lol {
    public static function whut() {
    }

namespace Lol;

function whut() {
}

Elsewhere:

Lol::whut();

When you write Lol::whut(), which one are you talking about? Is it the static function in the class Lol? Or is it the function in the Lol namespace? I can think of a few solutions to this very simple problem besides changing the damned separator character.

1. Throw an exception during parsing/compilation and complain that the symbol Lol has already been defined. Ideally it should say something sensible like: “Class name ‘Lol’ defined in main namespace conflicts with existing namespace definition ‘Lol’ found in FILE, line LINE.” For dynamically generated code, throw a runtime error and halt program execution. This is how C++ handles it, I can’t see why PHP can’t do the same. I would prefer it this way because I don’t want some moron programmer who is using my Lol library to write a class named Lol in the main namespace!

2. Throw an exception like in #1 but make it a non-fatal exception and just let the class method defined in the main namespace take precedence. Or even let the function in the namespace take precendence. Do it one way over the other but tell the programmer that there is a problem with his code!

3. Force Lol::whut() to resolve to the class method and ::Lol::whut() to resolve to the function defined in namespace Lol. Or vice versa.

I would really love to see arguments leveled against the 3 solutions above because changing the separator character is just plain stupid. Oh, and it’s butt ugly too. Sure it’s just in RFC but if this sort of stupid shit makes it into PHP6 then it’s time to say bye-bye PHP… It looks like they have their hearts set on using backslash as the namespace separator and it’s pretty much set in stone.

On a side note, when I was reading the RFC I had to take a second look at the date to make sure that it does not say April 1, 2008. They were considering the “smiley” as a namespace separator?!? Surely you jest!

a

I tried the latest version of Eclipse the other night. As usual, I downloaded the “Eclipse Classic” tarball for Linux. It’s an iffy release to say the least, akin to KDE 4.0. There have been major changes in the platform itself. But the most visible part is the way plugins are managed and installed. Personally I had high hopes for the new UI as the old one was a bit unwieldy to work with. Unfortunately, the new UI still needs a lot more work done. The main problem I had with the new UI is that even the plugins that already came with the package I downloaded still show up int the Available Software window. There also appears to be a bug where if you check and then uncheck a plugin, it will still install that plugin. There are also some new issues and regressions introduced by the new UI that they still have to work on.

Right now, I’m back to using Vim. Eclipse 3.4 is just too flaky for me at the moment.

a

encfs: error while loading shared libraries: librlog.so.1: cannot open shared object file: No such file or directory

It turns out that there has been a recent update to rlog and the encfs package was somehow left out of the rebuild. It also appears that the encfs package has disappeared from the Arch Linux Community Repository.

I have been rolling my own Arch Linux packages for quite a while now. I have been using a few locally built packages on my system. Since I already have two custom packages that I wrote myself, I figured it would be a good idea to share them. I’m too lazy to register with AUR and upload these packages and it would be likely that I would forget about updating them as well. So I am posting them here for consumption by the general public.

Download the Arch Linux source package for encfs here. To build this:

1. Make a directory to hold the files contained in the encfs source package.
2. Unpack the tarballed source package into the directory you created.
3. Install boost. Boost is a C++ library that is used by recent versions of encfs. You will also need to install fuse in case you don’t have it yet.
4. Change into the encfs source package directory you made and run makepkg -c. This will download the source for the current version of encfs. When makepkg finishes you will end up with an installable package in your current directory.
5. Install the package using pacman encfs-1.4.2-1-i686.pkg.tar.gz (replace encfs-1.4.2-1-i686.pkg.tar.gz with the correct filename for your custom-built package.)

There you go. You should have encfs working now.

You can also find pyme in my AUR directory.

a