Patterns as arguments to get_triples, get_quads, etc

[kjetilk]

I have an idea that I just wanted to ask about:

I just intuitively did

$self->count_triples_estimate($pattern)

and it didn't work, and it seems it shouldn't now. But intuitively, shouldn't that work?

So, I was thinking about how it could be made to work without placing too much burden on implementators. What I came up with is roughly that you'd need the idiom

sub get_triples {
  my ($subject, $predicate, $object) = @_;
  if ($subject->does('Attean::API::TriplePattern')) {
    ($subject, $predicate, $object) = $subject->make_search_arguments;
  }
 ...

and similarly for get_quads. Then, make_search_arguments or whatever it is called could be implemented in Attean::API::TripleOrQuadPattern to return undef for variables (and blanks?).
The problem is that you'd need to have those everywhere, count_triples, etc... Not very pretty and a lot of duplication.

So, perhaps get_triples and friends should only take patterns as arguments, and instead allow undefs in the constructor of patterns, and generate variables from them?

[kasei]

How would you feel about just warning/dying if you pass a pattern object to a method expecting nodes? I think I'm hesitant to add lots of different ways the same method can be invoked. And if it died, you could change get_triples($pattern) to get_triples($pattern->values), right?

[kasei]

Something like that (580255e).

[kjetilk]

OK. If it was an easy method to go from a pattern to a list of nodes, it would be OK, I suppose. If it is just one way to pass arguments to git_triples and family, I think I would prefer that to be a pattern.

The motivating case is this: https://github.com/kjetilk/AtteanX-Store-LDF/blob/feature-planning/lib/AtteanX/Store/LDF.pm#L179
I tried replacing that with $plan->values, but that didn't work. That won't give the undef for variables, would it?

[kasei]

$plan->values won't return undefs, but all the Attean get_triples (and similar) methods should accept either undef or variables. Are you implementing the get_triples method in question?

[kjetilk]

Huh, get_triples accepts variables? The get_triples I'm working with is Attean::Store::LDF. So, if it is doesn't, it is a bug?

[kasei]

Yeah. See the Memory store for example.

[kasei]

It might be a bit misleading in cases where you could pass in the same variable in multiple positions, but it's always been like this for convenience. Allowing variables makes it easy to pass in a list of things you got from a pattern object, and allowing undef allows for better syntax when passing in values explicitly (e.g. only passing in a single subject term as get_quads($s)).

[kjetilk]

Oh, OK! Then, we some tests for that... Looking into it.

[kasei]

I suppose a get_quads implementation could respect repeated variables and do the right thing... I wonder how we'd specify that implementations can choose to implement it either way... Or decide if that would even be a good thing.

[kasei]

Unless you object, I'm going to merge 580255e to at least make it obvious when these methods are called with an unexpected pattern object.

[kjetilk]

Yeah, that is ok!