Thanks for all the input guys!
As of revision 4717 these methods no longer exist in trunk. Since this was
just a tentative API.
I will continue experimenting with this API in a branch and it will likely
make it back into the core API in a later release.
Cheers,
Tobias
--
Tobias Ivarsson
Hacker,
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 <
tobias.ivars...
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 : node.expand().outgoing().along
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 expansion
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 reduce
Because mutable objects are evil. It would for example make it impossible to
write classes like this:
class Person {
private final Expansion friends;
Person(Node node) {
this.friends = node.expand( FRIEND ).nodes();
}
Iterable getFriends() {
return persons( friends
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 wrote:
>
> (I also noticed that r...
On Wed, Jun 23, 2010 at 6:10 PM, Craig Taverner 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?)
I get that
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
i
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
Did anyone have an opinion on what to call the methods on the Expansion
interface that specify which types to expand.
Alternative 1)
Expansion and( RelationshipType type );
Expansion and( RelationshipType type, Direction direction );
Expansion not( RelationshipType type );
Examples:
for (Node nod
Sweet,
Experiments are running fine again.
Thanks for the quick help!
Alex
On Wed, Jun 23, 2010 at 4:17 PM, Mattias Persson
wrote:
> 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 framew
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
> Hi guys,
> thanks!
>
> I've pulled the latest java-astar-routing and looking at it now.
> Have changed to
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 & ne
Also, the latest graph-algo is 0.6-SNAPSHOT... so use that instead
2010/6/23 Anders Nawroth
> 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 brok
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
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 DefaultEx
Hi Neo4j enthusiasts!
Yesterday I committed an API that Mattias and I have been working on for a
few days. It comes in the form of two new interfaces Expander and Expansion
(in the org.neo4j.graphdb package), and four new methods in the Node
interface (method names starting with "expand").
The tw
18 matches
Mail list logo
