I agree, lets keep it immutable, then its safe to keep the expander around.
Two suggestions:
Your could provide a reusable expander:
Expander e = Expanders.outgoing().along(FRIEND).and(ENEMY);
for(Node n:e.expand(node)){
...
}
or a onetime expander:
for(Node n :
I guess I would have just added a clear() method to the expansion. But of
course I understand that using mutable expansions requires that the user
actually understand the implications, which goes against the simplicity of
the DSL.
On Thu, Jun 24, 2010 at 12:23 AM, Tobias Ivarsson
Hi Tobias,
It seems as though the new changes have broken the AStar code I'm using.
I use:
neo4j-apoc 1.1-SNAPSHOT
neo4j-graph-algo 0.5-SNAPSHOT
AStar uses DefaultExpander and can no longer find it.
Here's an example of the code that worked until now.
DefaultExpander relExpander = new
Hi!
See:
http://www.mail-archive.com/user@lists.neo4j.org/msg04044.html
/anders
On 06/23/2010 03:44 PM, Alex Averbuch wrote:
Hi Tobias,
It seems as though the new changes have broken the AStar code I'm using.
I use:
neo4j-apoc 1.1-SNAPSHOT
neo4j-graph-algo 0.5-SNAPSHOT
AStar uses
Also, the latest graph-algo is 0.6-SNAPSHOT... so use that instead
2010/6/23 Anders Nawroth and...@neotechnology.com
Hi!
See:
http://www.mail-archive.com/user@lists.neo4j.org/msg04044.html
/anders
On 06/23/2010 03:44 PM, Alex Averbuch wrote:
Hi Tobias,
It seems as though the new
Hi guys,
thanks!
I've pulled the latest java-astar-routing and looking at it now.
Have changed to SNAPSHOT 0.6 too.
Has the AStar algorithm been changed to use the Traversal framework now?
If so, is there any way I can use the old AStar version?
The last one required neo4j-apoc 1.1-SNAPSHOT
It works with graph-algo 0.6-SNAPSHOT and there's an AStar.java (which is
the old version) and one ExperimentalAStar.java which uses the new
traversal framework.
2010/6/23 Alex Averbuch alex.averb...@gmail.com
Hi guys,
thanks!
I've pulled the latest java-astar-routing and looking at it now.
Sweet,
Experiments are running fine again.
Thanks for the quick help!
Alex
On Wed, Jun 23, 2010 at 4:17 PM, Mattias Persson
matt...@neotechnology.comwrote:
It works with graph-algo 0.6-SNAPSHOT and there's an AStar.java (which is
the old version) and one ExperimentalAStar.java which uses the
Did anyone have an opinion on what to call the methods on the Expansion
interface that specify which types to expand.
Alternative 1)
ExpansionT and( RelationshipType type );
ExpansionT and( RelationshipType type, Direction direction );
ExpansionT not( RelationshipType type );
Examples:
for (Node
Hi,
Personally I'd prefer and/not.
It's intuitive to any programmer and has the bonus of being much shorter, so
long complex expansions will appear less messy in practice.
On Wed, Jun 23, 2010 at 5:45 PM, Tobias Ivarsson
tobias.ivars...@neotechnology.com wrote:
Did anyone have an opinion on
I like this new API. It is a tiny first step towards making the Java API a
little more DSL-like (1% of the way to the current scala and ruby API's :-)
My vote is actually for the includes() approach only because *and* is such a
widely used keyword. However, a quick test in Ruby showed that while
On Wed, Jun 23, 2010 at 6:10 PM, Craig Taverner cr...@amanzi.com wrote:
(I also noticed that reading the examples with and() correctly indicates
that the order of definition is irrelevant, while includes() almost implies
that the first relationship type has some kind of precedence. Could it?)
Why not have includes() return the same instance with internal state
changed, then the various call options are equivalent.
On Jun 23, 2010 6:41 PM, Tobias Ivarsson
tobias.ivars...@neotechnology.com wrote:
On Wed, Jun 23, 2010 at 6:10 PM, Craig Taverner cr...@amanzi.com wrote:
(I also noticed
Because mutable objects are evil. It would for example make it impossible to
write classes like this:
class Person {
private final ExpansionNode friends;
Person(Node node) {
this.friends = node.expand( FRIEND ).nodes();
}
IterablePerson getFriends() {
return
Mutable objects have their issues, and yet this is a common and popular
paradigm in DSL design. I guess however the point with a DSL is that it is
so simple and limited that it compensates for the potential risks. Similar
to the dynamic versus static language argument.
Now there are ways to
The problem with the code below is that once you've used the
Person.getFriends(minAge)-method once, the friends-expansion will have that
filter added to it forever (if it's mutable), and that means that you will
never be able to get the younger friends of that person.
However, reusing an
16 matches
Mail list logo
