2009/12/11 Eugene M. Hutorny <[email protected]>:
> I have some more questions regarding to Qi4j design and implementation. I
> have stated them as expressions, please comment whether they are correct or
> no (I presume at least some of them are not).
Welcome, and this format is pretty good...
Mind you that all this refers to the Qi4j implementation, and we have
not yet concluded what is required within the Composite Oriented
Programming paradigm. Hoping that some student or doctorate would pick
up and analyze these kind of abstract questions.
> 1. Two composites (instances) of the same composite type (class) may have
> different set of implemented interfaces
No, if you say "composite type" which we define to be the 'most
derived' interface which binds everything together. If you instead
mean "mixin type", which we define as any super type of a composite
type, then it is true.
In the first spike of Qi4j back in 2007, we implemented a fully
runtime-flexible type system, where you could add/remove both types
and implementations on the fly. Rickard correctly observed that this
will make code incredibly difficult to troubleshoot, since no types
are ever for sure fixed.
> 2. A set of interfaces implemented by a composite may be changed during the
> composite's lifecycle.
Yes and No. It will not change over the JVM lifetime, but "entity
lifecycle" is defined from "creation" to "deletion" in entity store,
and for those the composite type and mixin types may evolve.
> 3. One composite may have two different implementations of the same
> interface.
The expression is ambiguously stated. Implementations are not resolved
"per interface" but "per method". So, for instance;
@Mixins( { AMixin.class, BMixin.class } )
public interface MyComposite extends A, TransientComposite
{}
public interface A
{
void methodA();
void methodB();
}
public abstract class AMixin
implements A
{
public void methodA()
{ .... }
}
public class BMixin
implements A
{
public void methodA()
{ .... }
public void methodB()
{ .... }
}
In the above example, methodA() will be resolved to the
AMixin.methodA(), since it has higher precedence in the @Mixins
declaration over BMixin. But BMixin.methodB() will be selected as the
methodB() since there is no such method in AMixin.
There are quite a lot of 'method implementation resolution' rules at
play, since the Mixins could be declared in the MixinTypes, you could
have AppliesTo rules at play, you can declare mixins in the bootstrap
code, and typed implementations have higher priority over generic
method implementations (InvocationHandler).
> 4. A fragment instance can be shared between different composites without
> explicit intent of the fragment author (and/or the fragment user).
Yes. It is more often than not the user of the fragment's
responsibility to use a fragment correctly.
> 5. A reference injected into a @This annotated member may vary from call to
> call.
No for Mixins, and Yes for Concerns, SideEffects and Constraints.
Mixins can be considered injected at 'creation time' and they won't
change. But for the other fragments, they can be re-used between
method calls (still of the same Composite Type) into different
instances, so for instance @This would potentially change. This drives
the "you can't keep inter-method state in Concerns" requirement, since
there are no guarantees that the same Concern will be used next time,
or that the next call is in the same composite.
> 6. When an entity is deleted, references to it in other persisted entities
> are immediately removed.
Incorrect-ish. The references will remain, and when you try to access
them you would either get NoSuchEntityException or perhaps a null
reference. In fact, this is an ill-defined area I think, and we should
possibly tidy the semantics up a bit. For instance;
public interface A
{
Association<B> b();
}
This means that the b() instance is not optional and may not return
null. So what should really happen? NoSuchEntityException or should we
even try to prevent the deletion to occur?
Rickard??
> 7. Joins in the queries are fully supported (e.g. it is possible, with a
> signle query, to find all students and courses they attending where student
> name is Anna and course name contains Art)
There is no such thing as "joins". I know that you have your SQL
goggles on, but whether or not that is expressable, depends on 2
things;
1. Careful modelling and it can be expressed in the Query Fluent API
always available.
2. Using Named Native Queries (NNQ??) has the full power of the query
language being used. At the moment we only have Sparql implemented,
and you could potentially use the full OWL capabilities with inference
and everything, i.e. way beyond what you can possibly express in SQL.
However, it will probably require you to populate the Sesame with
quite a lot of information on how the model really is, since we have a
homogeneous "view" that may not fit the inferences you try to do.
So, to refine your example, it should probably read; Find all Students
where student.firstname()='Anna' and contains( any( student.courses()
).name(), "Art" ).
I think this can currently not be expressed with the fluent API, and
the NNQ is needed. This is mainly due to our "indexing/query expert"
has more or less 'departed' and not actively working on fixing some of
the missing stuff, and Rickard and I have not been motivated enough
(lack of need) to fix it.
HTH.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
