Mac development begins...

1. I just bought my first iMac top of the line (i7 2.9GHZ+SSD+8GB+1TB) which I am enjoying immensely.
2. I have ported my code over to XCode for the iPhone development.
3. I have updated my svn (under packages) with the latest components.

So I am back to work with a clear development path.

I have added support for inheritence+extensions for objects. For example: IOSView extends UIDisplay without UIDisplay being aware of IOSView. When UIDisplay calls pDisplay = CoreObjectNew(UIDisplayComponent) it creates not only an instance of UIDisplay but attaches to it also an instance of IOSView automatically. This allows IOSView to fill in the display buffer parameters without UIDisplay having to call IOSView. This is a great feature.

I am working on the basic components such as Timers, Pen events, Xml parsing and so on. This should take some time but components are being written quite quickly, so I will hope for the best.

Instead of uploading new zip files, I will from now on just refer to the latest SVN versions.

The means to the end is also important

I have been low on the radar because I have been working hard on the code instead of updating the blog but mostly because I didn't have anything to show.

I now do have a another snapshot of my code to show. While this is in no way Screens, it does preview the object storage with some example components.

I now support singleton components (components with only a single instance) and improved the overall design of how components are used. I also made it simpler to write a component as you can see in the attached code.

You can find the code here: http://www.box.net/shared/5blf9bqexc

About the multi-level assocation hierarchy, I removed that since not only did I find its use limited, but it was too complex for me to handle or explain to others, so I axed it. It was basically to allow each instance to have child instances while still being attached to the same object.

A few notes:

1. Allocation in chunks
It allocates objects per components in single allocations of 256 objects per component (apart from singleton components). It then re-uses allocations of the components. This reduces the problem of memory fragmentation.

2. Object limit
I currently have a maximum limit of about 65,000 objects. This is because I have an overhead of 32bits per objects which contains two 16bit references. However this implementation limit is encapsulated in CoreObject, so in the future this could be changed without an overhall on all the code.

3. Multi-instance support
You can attach multiple instances of the same component to a single object. This is how CoreNotify works where it just attaches each new notification to the same object and then uses CoreObjectCast to retrieve the next notification for message broadcast.

4. Simple component use
I have reduced the component overhead to a single public function that calls CoreObjectInit, a single typedef to define the object type and variable declaration in the header file of the component. The object can be any type, it can be an integer, character pointer, structure, union or anything fixed that C supports (it does not support non fixed character arrays since all objects must be of the same size per component).

Latest batch of components

You can find the latest set of components here: http://www.box.net/shared/ylgxz565id

I have added some components to get the idea of how components are written.
I know that the concept is a little rough around the edges and I am working hard to make it more understandable and explaining the killer app for this kind of technology.

Note that while the code does compile in Visual Studio 2010 Express, I have not done testing so many bugs probably exist in the code.

Dynamic association

Dynamic association is my new 'magic' programming model that allows objects to be collections of functionalities that are dependent/independent of each other as needed.

Most developers are used to inheritance (is-a) or containment (has-a). There advantages are many and most applications today, use them heavily in their application design. I see association (use-a) as the new way for designing the applications of the future.

Inheritance requires heavy amount of design ahead of time of a project. It requires heavy commitment with calculating what should use containment and what should be inherited. While it does sound great on paper, in real world situations where projects change over time, I have noticed that inheritance unless designed heavily before hand, just does not stand the test of time. Designing complex inheritance relationships ahead of time is not always feasible and over big projects with lots of developers make it a real headache.

My solution of course is 'dynamic association'. Dynamic association allows components to be small, concrete and encapsulated but be part of the same objects. Instead of designing inheritance ahead of time, you dynamically associate (attach/detach) components to objects at run-time. If a window uses hierarchy, just attach the node component to the window object. If the window needs input, just attach the input component to the window object. The association is on the object, not on the component (class).

Its based more on the real world model. A chair is a chair because it has chair abilities. You can sit on a table, so is a table a chair? Of course not. So should you derive the chair from the table or the table from the chair? With dynamic association, you don't need to. If it started as a chair, attach an object to a chair component. If it later on has a table usage, attach a table component to the same object. Its not what an object is, but what it does. Once components are attached to objects, you can cast between the different component instances attached to the same object.

I know its going to take me years to convince developers of this model, I am meanwhile using it heavily in Screens. Its allowing me to write functionality faster than ever, keeping each component to a very small size and all written in native C without macros gives me a lot of clarity which higher level languages lack. C's simplicity in its language features and its code portability allow me to target multiple environments easily.

I hope to continue pushing out components, so developers can see the advantages of dynamic association and start using it in any project. If anyone wants to see what it looks like, check out in the code attached to the post below: http://screensenvironment.blogspot.com/2010/08/first-draft-of-object-storage.html

First draft of Object storage

The code can be downloaded at: http://www.box.net/shared/9i4g3mbo5m

Note that the code is a draft and while it does compile in VS2010, it has not been tested very much.
Its just to show the direction I am taking with the Component based programming code.
The licence is public domain and Screens is staying that way for the foreseeable future.

I am now working on the component CoreShadow which allows a component to link
to another component instance of a different component without controlling the linked component instance life-cycle but still not having a dangling pointer. The idea is that components only really control their own instances, not instances of other components unless they are maintained by the component instance itself.

This is dynamic association. CoreObject allows to attach different components together to form an object. Components can be attached or detached from objects, or sent dynamically bind messages to them. All written in native C with no macros. Why use component based objects? It allows to add or remove functionality from objects at run-time with data. Most other languages support adding interfaces but not adding data dynamically. Component based programming using the attached files allows to add also an interface and data to any object.

Because the association is done at run-time, components do not need to be created just because the associations are slightly different. Components are like classes in Java/C++ but do not use inheritance but rather association. Whats the difference? "Inheritance = is a relationship" while "Association = use a relationship". Its a subtle but powerful difference. Instead of deriving types, an object is a combination of different types that together form a single concept.

I know that this is not a known programming relationship but I will explain it better as time goes on.
Meanwhile feel free to peak into the code and enjoy.

Moving forward

As you can see from my twitter updates, things are moving forward. I am slowly but surely moving up the component chain.

The only nagging issue at the moment is that components can be attached freely to objects however when I depend on multiple components, the interface does not specify what components are public. For example: UIWindow uses CoreItem to manage the window hierarchy but how would I specify this in the interface? At the moment I am just adding a ‘using x’ doxygen comment in the component type definition. Not a big issue at the moment but noticed.

The advantage of using components is already making its way and improves with every set of components I add since they can depend on each other for functionality. Its like classes but the relationships are not pre-defined but rather by their use. If component A uses component B only then is it dependent on component B.

I am now on the window related components trying to get back to the original demo state where I first had moving windows without text (I am using 2D OpenGL for this incarnation of Screens). The UI will hopefully be more functional this time.

I hope I keep up this development pace.

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.