Some off-the-cuff ideas… I'd like to catch up to Java. :grin: Here are three examples (very much off the top of my head, so there may some obvious reasons that we wouldn't want to do these) to give the flavor of what I mean, assuming we are talking about a really new API. I don't think anything is too unworldly, depending on our timescale.
• I'd like to see the introduction of Optional on a much larger scale to replace returning "value-or-null" in a new API. Modern JVMs in-line Optional to null-checks, so there is no real performance issue, and Optional (for my money) is no longer confusing and new, it's elegant and clear and concise. • The Streams API has already come up. IMHO it's a no-brainer to introduce it alongside iterators in selected appropriate places in the SPI and a new API. Ideally we would even feature a few good examples of pushing computation back up the line. • The Flow API (reactive streams) seems interesting in the context of SPARQL 1.2 protocol-related discussions: https://github.com/w3c/sparql-12/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+protocol For example, if ideas like https://github.com/w3c/sparql-12/issues/7 or /84 go forward, we could potentially redesign RDFConnection and its underpinnings to use Flows. This is pretty speculative, of course, but there are other areas that might be interesting for this. I suspect that we could use it to do some level of decoupling of SPARQL execution (flows passing to each other), but that is well above my ability to speculate usefully on, knowing as shamefully little as I do about the actual paths through ARQ, and anyway, that's not API-related. Other stuff: I would like to look at the fairly large number of methods on classes like Resource and Model and see if we can corral and regularize them a bit. I'm not against functionality, of course, but we've built up those APIs via the "coral reef" model (accumulation) and so we have little oddities like: Statement getProperty(Resource s, Property p, String lang) and Property getProperty(String nameSpace, String localName) but Statement getRequiredProperty(Resource s, Property p) with no Property getRequiredProperty(String s, String p) That's not such a horrible state of existence, but I find that the dozens and dozens of methods on some of our core types often get a bit hard to sort through, especially with little quirks like that. We might also want to consider nomenclature. Model, for example, isn't really a great term to use any more for what most APIs would call a Graph. Of course, we've used "Graph" elsewhere. In any event, something to think about. Next.0 is the time to make changes like that, if we're going to make them. ajs6f > On Nov 21, 2019, at 12:44 PM, Andy Seaborne <a...@apache.org> wrote: > > So what sort of things do people think we should look at for the main > application API(s). > > Andy
