Notes

Thoughts on Addressing API's

Goals

• Developers creating items don't need to specify a parent
• Developers don't need to create a Kind item in order to create an item
• Items can be instantiated from other item instances

Thinking out loud

Today we have:

Item(name, parent, kind)

So one step is:

kindItem.newItem(name)

Eliminating the parent (the kindItem decides the parent). The problem with this that in order to get the kindItem, you had to look it up and then create it.

How could we use a factory?

Factory.newItem(name, kindItem)

This just moves the method to Factory, and you still have to look up the kind. The Factory or the Kind determines the parent (it's hidden from the client which piece of code makes that decision). This allows the possibility of different Factories to layout items of the same kind differently, rather than burying that logic inside the kind. Do we need that level of flexibility?

I think I prefer this one, where you supply the name of the Kind -- you don't have to look it up:

Factory.newItem(name, kindName)

If you already had an item of the appropriate kind, you could do:

itemInstance.newItem(name)

which would get you an item of the same kind, and laid out internally the same way.

The above give you a way to get rid of parents, and in some cases kinds. It doesn't discuss how items will be laid out (parented). It also doesn't account for the multiple dimensionality being proposed in http://lists.osafoundation.org/pipermail/dev/2004-May/001475.html, although I think that the dimension/axis information is hidden using the same technique for hiding the parent.

-- TedLeung - 25 May 2004