[CompStrm Wiki] the object model--it is much simpler than you think it is

[Bill la F. <laf...@ya...>]

AgileWiki3 employs, to put it nicely, an innovative
aproach to persistance. Its objects exist on disk, not
in memory. These are not Java objects!

The flip side of that is that there are classes for
creating object proxies. And as with other proxy
systems, there is a concept of narrowing to
instantiate the appropriate subclass for a given type
of object.

Also, as with other proxy systems, the proxy object
does not hold data. Rather, it has only the id of the
object for which it is the proxy. But this does not
mean that this is a slow system. It is much faster
than most databases, while being slower than proper
Java objects.

Speed is achieved through caches. There is a lot of
code dealing with different types of cache, and there
are a lot of caches.

In AgileWiki3, we can apply caches very effectively
because we have a universal model (Rolonics) for
applications which allows us to characterize different
kinds of data and provide for a systematic
implementation. The theory, as it applies to
programming, is almost too simple to understand.

The thing to keep in mind about a theory is that,
while it may be predictive (which is what makes for a
great theory), it is more a recognition of what
already exists. A great example is java.util
collections.

One thing you notice about the util collections is the
lack of participation by the object in a collection.
The good part about this is that it is easy then to
have an object in more than one collection. The bad
part is that, for a given object in a given
collection, you can't get to the next or previous
object (if it is a list) directly for a given object.
(I'm not talking about iterators.) Worse case is when
dealing with a linked list--get the index of an object
in a list, add 1 and then retrieve the object so
indexed. This is a very slow operation, though you
would think that it would be quite fast.

So is there a point to this? Yes. These collections
are generally great. And Rolonicly speaking, they are
done correctly. Relationships between objects are
classifiers, which are distinct from state data
(ledger) and meta data controling an object's behavior
(descriptors). Broadly speaking, good programming
practice always conforms to Rolonic theory. But that's
relatively uninteresting. Here's the hot point:
programming with Rolonics will often lead you well
beyond known programming practices and patterns. And
its simple. But just a little too simple to be easily
understood perhaps.

OK, back to the object model. In AgileWiki3, we
organize the data into four main groupings:
classifiers, descriptors, ledger and journal. That's
it. Doesn't sound like much, no? But here's the
punchline: having grouped all the data this way, you
begin to see much more consistency within each group.
Remember, theory is all about seeing things you never
knew were there before. This increased consistency
within each of the 4 groups of data then allow for an
entirely systematic implementation of application data
structures. And an overall system with much higher
performance, flexibility and ease of implementation.

Also, remember that we have introduced time as a major
element in every query. And still it is fast.

There are only a few data elements. A rolon (topic)
can have a document (ledger). There are ledger,
descriptor and classifier name/value pairs. Some
classifier name/value pairs are inverted. And that's
almost it.

The only thing that's missing is lists. Name/value
pairs are kept in lists. You can order the contents of
a list, get the (unique) names in a list and get the
value assigned to a name in a given list. So all those
name/value pairs in a rolon are actually members of
various lists.

So there's nothing really complicated here. A rolon
has a document and several lists, those lists having
name/value pairs. And some classifier lists get
inverted. Of course, we build complexes of structures
from all this. For example, the ledger of a rolon
(topic) is a list of rolons--the transactions. But you
can then make changes to a transaction--being a rolon,
it also has a ledger. :-) This is a very rich system,
well capable of modeling any business application.
Rolons can serve as classifiers, descriptors and
ledgers as well.

Enough for now? I'll close by repeating one of Norm's
favorite sayings: "It is much simpler than you think
it is."

Bill


		
____________________________________________________ 
Yahoo! India Answers: Share what you know. Learn something new. http://in.answers.yahoo.com