Why is objects so hard?

Object oriented programming has existed for over 30 years however users still dont see objects at all. Even when it is object oriented, it is made totally static and fixed so that users dont get any benifit out of objects. When you see research projects show how easy objects would be for users, the first question which pops in my head is why is not here yet. The reason is simple: its easy to whip up a demo but its a whole different thing to deliver an actual useful implementation of objects. The last commerical object oriented system that had real objects was OS/2. I am not talking about kernel objects or objects in code. I am talking about objects visible to the actual user of the system. That he is aware of the objects and can manipulate them. Its hard creating an object system. Look at microsoft and see how in 2 decades they still have not able to release an object implementation that is not demo. I had high hopes for WinFS but it failed because its so hard to limit the user experience on a 'limitless' experience. Its like trying to create the base essence for the world, its nearly impossible (although possible since well, it exists). Objects need to be simple in essense but be complex in structure but simple to use. That sounds hard! No wonder I am still stuck on these basic concepts for over 8 years. I am making great progress... Component Based Programming in C has recieved great feedback from my work environment and I am continuing to evolve the model and write code to evolve it as time goes by. I have never let go of working on Screens, I dream about this project daily and constantly researching in code and on the internet to find the solution to this problem. There are many others trying to find the solution as well. May the best solution win.

Still here

Hi,

I am still working on Screens as you probably can see by my twitter stream. Its still taking me forever to design the interfaces. Once I have an interface design, coding is very quick per component. I just spend alot of time perfecting my interfaces.

I know… I am a perfectionist and this system will never be more than vaporware. But even if so, I owe my full time job to Screens from all the years of research that I am able to use in my coding at work. Many of the projects I work on are directly affected by my work on Screens over the years. So even if Screens never leaves the ground, it has given me my paycheck. Not too shabby.

I think its safe to conclude that PalmOS is out of the picture not because of me but because of Palm. Everyone said that someone else will beat me to the punch, but it looks like the ship sank before that ever happened. Probably why the ship sank.

If I get back to the alpha stage that I got to two years ago, that would be great and show that at least I am doing something. Luckily Screens is multi-platform so it can just be ported to the handheld platform at the time. Again, once I reach the alpha stage again, I will upload my sources back into SVN.

I am now 26, married for 5 years with a 3 1/2 year old son and a 2 year old daughter working at a high-tech job. Screens gave me the last bit.

New Object Storage

OK, Here we go again...

My latest evolution of the object storage is as follows:

Each object can contain an instance per component.

This means that a markup object can contain the following instances:

UIMarkup - Html markup instance for display

FSHtml - Html parser instance

FSXml - Xml parser instance

FSFile - File stream instance

The idea is that the markup object is also a markup object, also an xhtml file, also an xml file, also a file stream and so on.

These components are attached at run-time to an object and there are no rules on attachment.

You create an object using CoreObjectNew, retrieve an instance using CoreObjectInstance, destroy an object using CoreOjectFree and store a handle to an object/instance using CoreObjectStore.

Here are the prototypes:

bool CoreObjectNew(CoreObject ** ppObject);

bool CoreObjectFree(CoreObject ** ppObject);

bool CoreObjectInstance(CoreObject * pObject, CORE_OBJECT_CALLBACK callback, uint32_t size, void ** ppInstance);

bool CoreObjectStore(CoreObject ** ppLocation, CoreObject * pObject);

Its a lot to swallow but once you understand it, its very easy to use.

The object does not contain the instances, the object is an instance. You can just cast any instance directly to a CoreObject pointer. To cast an object to a component you use the component's cast function like this:

UIElement * pElement;

CoreObject * pObject;

CoreObjectNew(&pObject);

UIElementCast(pObject, &pElement);

UIElementMove(pElement, 50, 50);

UIElementResize(pElement, 100, 120);

UIElementShow(pElement, true);

You can also use the shorthand New method on a component as follows:

UIElement * pElement;

UIElementNew(&pElement);

UIElementMove(pElement, 50, 50);

UIElementResize(pElement, 100, 120);

UIElementShow(pElement, true);

The advantage of this design is that each component does only what it needs to and allows objects to be passed freely between components. Each component can access only its own instance on an object so there is complete data hiding.

I have finished writing the object storage and I am now going to start working on UIElement which deals with drawing to the UIDisplay component. I know that previous demos were slow, so I am seeing what I can do about baking drawing performance directly into the new design.

If you have any questions, ask away...

To answer currently know questions:

1. I will be testing the code on the PalmOS simulator, if I found that I have a valid code base (a.k.a demo code) I will try get my hands on a PalmOS device to test it out. So yes, there will be a platform dependent code base for PalmOS.

2. I don't know when Screens will be released, my curse is that I am a perfectionist and feel that there is no point releasing just another middle ware if I have nothing unique to show. I have a rule that if some code is hard to write, the design is probably wrong. So far that has been the #1 reason for all the rewrites over the years.

3. The drawing model for Screens is like a markup model, you create elements, fill in thier properties and the display draws them by itself. This is like the WPF model, not like the GDI model in windows.

4. I don't know if Screens will be ported to Linux/MacOS, but I don't see any problems doing so in the future. The platform dependencies are a minimum. If I get passed the previous demo I showed last april, then I will be buying a Mac for porting purposes to the iPod touch.

Enjoy!

Update: 26 and learning

Hi anyone who still checks this blog, I now I have not updated for a long time. I moved to Jerusalem with my family, had a lot of work to do at my full time job and my son started kindergarden. Alot has changed since I first started Screens is 2001. Screens is not dead, actually on the contrary... I never stopped working on Screens and have in fact tested a few of my ideas at work and they have worked really well. I am very happy with the component object model and do plan to start writing code again. I don't have my lifedrive anymore but the code should be usefull no matter where it runs. Once I start getting into coding again specifically for Screens I will update you and write some editorials... I have alot of them down the pipeline, so keep tuned... Zakai Hamilton

Random Thoughts

1. Don't rely on a compiler extension when doing platform indepedent code

You will never know when your code will hit a compiler you did not anticipate. Keep it cleanand simpleand don't try to be smart. Consistency is key in writing alot of components. Avoid using tricks because their value will decrease over time because you will lose track of the tricks you used.

2. Using a 'better' language (C++, C#) will not reduce the real complexity which is the number of components you need to write and thier dependencies and relationships.

3. Consistency in API function and component naming is sometimes more important than the implementation itself since the implementation can be refactored while an API mostly cannot be changed.

Just a few things that come to mind when writing code for Screens. I am still active on the project and spend between 1-2 hours a day on Screens now thanks to my HP Mini-Note 2133.

I have not got to the graphics code just yet, but I am very close to try it out.

Why is Screens is taking so long?

Screens Environment has been going since 2002 and still no releases have made the light of day. There is a single reason why Screens has taken so long and why I have no idea when it will be released. Its not because I lack time or interest. Its because of the object storage.

If you look at the object oriented OS projects, none of them have made mainstream because they are not practical enough, too complex, too slow and still stuck in a concept. There are many companies trying to bring object oriented concepts to file systems just like me and just like me are still stuck.

If I was not making the object storage, I would of finished Screens long ago but then again the object storage is such a radical change that Screens would not be the same without it. In fact, the object storage would be the main difference between Screens and other middleware platforms.

I need luck, time and persistence to find a combination that works.