Hey,
Sorry for being slow in responding :-( Been out-of-country and my email
reading goes bonkers. See below:
On 2/19/12 15:13 , Niclas Hedhman wrote:
BUT doing this, something very profound emerges;
* What is the difference between the "MainType" and "OtherType"
module.values( MainType.class).withTypes( OtherType.class )
??
I think the main difference is between "what the object is" and "what
the object does". The maintype is used to determine what the object is,
and then the withTypes() is used to add roles, typically stateless, for
what roles the object can play in different usecases.
This is, of course, still a class-based view of objects, rather than
true OO, where an object should be able to "be" any number of types
simultaneously. The main reason I have not personally been able to get
composites, or entities more specifically, to be many main types at the
same time is persistence and serialization. When loading a composite
from a persistent store, and it "is" many types, then how do you load
it? With the main type concept, it is easy to do this. If a composite
can be many things, then what do we store in persistent store, and how
do we use that during loading?
If that can be solved, and also how types can be added and removed from
a composite during its lifetime, it might be possible to allow many
"main types".
Looking at, for example, XML and RDF, where identity is the core concept
(the URI) and namespaces are used to determine type, it really is up to
the reader to determine how to interpret any given set of data. If I
read an XML document and only understand a single namespace, of many
used, that can be consistently handled. Same thing in RDF, if a URI has
many types associated with it (URI-[rdf:type]->sometype), then I can
choose to use the type that I can understand, and leave everything else
out.
In other words, what exists in memory is a REPRESENTATION of the
"object", rather than "The Object" proper. Like in REST, you can never
see the object "as it is", only through views. I kinda like this,
conceptually, and if we could support this in Qi4j explicitly, it'd be
awesome.
Problems that typically crop up when you do this includes, for example,
id generation. Typically id's are unique *within a type*, and if there's
no "main type", then UUID's (or similar) are pretty much the only
option. Having id's separated based on type becomes meaningless,
because, well, which type?
As I am now working fulltime with Neo4j, in that model this is kinda
natural, as there is no built-in type system, and so there is a global
id generator for all "types of nodes" (i.e. the "no type").
Can we do that? I don't know!
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
