Mark Watson on automatic accessors for Java

Mark Watson proposes a change to the Java language, in the form of making it possible to automatically generate accessor methods for class attributes. It would work a bit like the generic functions created by the :reader, :writer and :accessor slot options given to defclass in Common Lisp.

However, I think that if that part of the language is to be changed — and I agree it should be — the new design should go all the way to hiding the methods from the users of the class. It should be possible to optionally define the accessor methods you want and then have them accessible by simply using the attribute name. So object.attribute = value would invoke object.setAttribute(value) behind the scenes, if such a method was defined. For backwards compatibility, it would need to do the normal assignment if it was permitted and no method was defined. A close relative to look at for inspiration would be C#. This one of those places where the language is, simply put, better.

[UPDATE]

Reading Bruce Eckel's great blog, I stumbled across this: The Java team is clearly not ignoring the threat of C# [...] along with the new features already on the list for "Tiger" (JDK 1.5), including true enumerations, autoboxing, and generics (templates), they are adding attributes, something (along with autoboxing) taken directly from C#, because it's a good idea.

Article page

99 bottles of GOO

Here's a version of 99 bottles written in GOO. I have submitted it.


(df bottles (n)
        (cat
                (cond ((= n 0) "No more bottles")
                        ((= n 1) "One bottle")
                        (#t (cat (num-to-str n) " bottles")))
        " of beer"))

(df bow (n)
        (cat (bottles n) " on the wall"))

(do 
        (fun (n) 
                (post (bow n)) 
                (post "\n") 
                (post (bottles n)) 
                (post "\nTake one down, pass it around\n") 
                (post (bow (1- n))) 
                (post "\n\n")) 
        (range-by 100 >= 1 1-))

Happy easter. Article page


Berkeley DB XML

I just went surfing Sleepycat Software to read some documentation (don't ask me why, I just realized I have it all installed locally), when I noticed this: Berkeley DB XML. Apparently not yet released, but interesting anyway. I'm not big on XML DBs, but with Sleepycat doing it, it might be worth checking out. At least they have a great history of doing high-quality, simple, lightweight products that just do their thing with minimum fuss. And if they continue with their licensing policy, all the better. Then we just need some Python bindings...

Article page


Content management tools fail, Plone marches on

A Jupiter study — I'm usually highly sceptical of these, but hey, maybe they're right for once — says businesses are often dissatisfied with their content management solutions. Complexity, lock-in, overengineering, ridiculous prices abound.

Meanwhile, in Plone land: Plone Improvement Process (a formalized approach to improvements: this sort of thing seems to be pretty popular in the larger free software projects these days, have you noticed?) has a few interesting improvement proposals for an already fine system: Oslo Skin system and Navigation and validation rewrite.

These coupled with improvements to and integration of CMFTypes and possibly the brand spanking new TTWType promise a bright future. It's not perfect and probably not suitable to all situations (there's a clear community site bias, but it doesn't have to be used that way) but it is easy, powerful and has a lot of momentum. And clearly there's still lots of space in the CMS field to conquer. Zope 3 is coming, but this Zope 2 thing is nowhere near its end of life.

Article page

Asynchronous fetching seems to be working

Coolness. Straw is actually successfully fetching the dozens of feeds I'm reading, asynchronously, without the troublesome network thread. DNS lookups with ADNS (ha, yes, another dependency), reading stuff off network via asyncore. And the UI is pretty responsive. It's still slower than it used to be, but I think that's a tradeoff I can make. And, as I said earlier, things can possibly be tuned to work out better.

However, one somewhat serious usability problem remains: the stuff is basically fetched off a queue, where things go like this: request an URL -> resolve the host asynchronously -> add the split URL + IP to the fetching queue -> fetch data asynchronously -> stuff the results into the internal datastructures. Now, when you press 'g' or when the timer triggers a polling run, we request all the RSS URLs, then when we have finally gotten something, we parse it, see if there are any images, and request those. See the problem? Unless name lookups are in some cases seriously slow, all the articles are fetched before any of the images. I suppose that's fine if you are interested only in the text, but if not, and you are sitting in front of your aggregator, waiting to read the words of the bloggerdom hot off their keyboards, you get to read the items without images.

So maybe I should prioritize the images higher. That is, stuff the image requests to the front of the queue. And I suppose that as long as we are talking data structures instead of, say, things you see in Helsinki in front of bars Friday and Saturday evenings, it won't be a queue any longer. Oh well. That's theory for you.

Article page