It is difficult to have a co-existing world for this, since it is part of the Core itself, which is Java 7.
We could allow libraries of Java 8 only to be added, but must be able to co-exist with a Java 7 Core. So, the Builders that i pulled out to libraries/geometry (which perhaps should be in libraries/spatial), could be made with java.util.function & Co. To find a sweet DSL with closures, will take some experimentation to get right. But important aspects of that is; a. Values are created, i.e. newInstance() is called. b. Additional mixins/concerns can be added to, and initialized, to the Geo types. I see if I have any time to fool around with this (last night wasn't available)... Cheers Niclas On Fri, Jun 5, 2015 at 4:18 AM, Jiri Jetmar <[email protected]> wrote: > Hi Niclas, > > Regarding samples - there are spatial regression tests > at AbstractSpatialRegressionTest.java. > > Indeed closures can help a lot to defined/structure a query DSL. Do you > have already something concrete in mind ? Do you think on a kind of > co-existence of the new/old approach ? > > Cheers, > jj > > 2015-06-04 0:24 GMT+02:00 Niclas Hedhman <[email protected]>: > > > It has been good to see these examples, and I realize that the Java 8 > > closures could help a lot, > > > > It seems that Java 8 closures could help a lot to define the DSL, and > > maybe(!) that is a strong enough reason to defer the geospatial inclusion > > until 3.0, so we can make it "right" from the beginning, without worrying > > of two different syntaxes? > > > > If so, we should collaborate to formulate such a DSL, without too much > > concern over the existing work. It can really make things a lot less > > verbose. > > > > > > Cheers > > > > On Thu, Jun 4, 2015 at 4:47 AM, Jiri Jetmar <[email protected]> > > wrote: > > > > > Hi Niclas, > > > > > > hmm, yes I;m using the expression like > > > > > > module.newValueBuilder(TMultiPoint.class).prototype(); > > > > > > in the TXXXBuilders. I was not aware that this is not supported. I try > to > > > understand > > > the "deep" secrets of Zest type approach, but this is pretty hard to > > get... > > > > > > I think it should be fine to fix it in the TXXXBuilders in the > > > "org.qi4j.api.geometry.internal.builders" > > > package as in *all* other cases the builders are used to create spatial > > > types. I;m not 100% sure here, > > > but the reason to introduce the TXXXBuilders is the fact that spatial > > types > > > tend to be complex in terms > > > of definition : > > > > > > ValueBuilder<TLinearRing> builder = > > > module.newValueBuilder(TLinearRing.class); > > > assertNotNull( > > > builder.prototype().of > > > ( > > > > > > module.newValueBuilder(TPoint.class).prototype().of > > > ( > > > > > > module.newValueBuilder(Coordinate.class).prototype().of(1d), //x > > > > > > module.newValueBuilder(Coordinate.class).prototype().of(1d) //y > > > ) > > > , > > > > > > module.newValueBuilder(TPoint.class).prototype().of > > > ( > > > > > > module.newValueBuilder(Coordinate.class).prototype().of(2d), //x > > > > > > module.newValueBuilder(Coordinate.class).prototype().of(2d) //y > > > ) > > > > > > ) > > > ); > > > > > > versus > > > > > > TLinearRing ring = TLinearRing(module).ring(new double[][] > > > { > > > {0, 0}, > > > {1, 0}, > > > {1, 1}, > > > {0, 1}, > > > {0, 0} > > > }).geometry(); > > > > > > Let me know how I can support you on this topic. > > > > > > Thank you. > > > > > > Cheers, > > > jj > > > > > > > > > > > > 2015-06-03 17:42 GMT+02:00 Niclas Hedhman <[email protected]>: > > > > > > > Let's decide that a little bit later... > > > > > > > > Another anomaly that I notice everywhere; > > > > return module.newValueBuilder( TPoint.class ).prototype(); > > > > > > > > This is invalid (read unstable/unsupported) use of prototypes, since > > you > > > > don't instantiate them. Is it because you where unsure of the > > > > TransientComposites or how/when to make them into ValueComposites. I > > > > recommend that Values are used, due to the nature of the datatypes, > but > > > > right now, they are broken... Any comments before I fix the rest > > (already > > > > sorted out the many Builders)? > > > > > > > > Cheers > > > > > > > > On Wed, Jun 3, 2015 at 10:45 PM, Jiri Jetmar < > [email protected] > > > > > > > wrote: > > > > > > > > > Hi Niclas, > > > > > > > > > > this ST_XX follows the http://en.wikipedia.org/wiki/DE-9IM and > > > > > http://en.wikipedia.org/wiki/Simple_Features standards that are > > indeed > > > > > "SQL" related. I used this expression to be similar with e.g. > > PostGIS, > > > > > means when someone knows how to use spatial expressions on PostGIS, > > > > > he should be able to understand the Apache Zest approach. > > > > > > > > > > But clearly I can "lowercase" the ST_Xx expressions in the code. > > > > > > > > > > Cheers, > > > > > jj > > > > > > > > > > 2015-06-03 16:22 GMT+02:00 Niclas Hedhman <[email protected]>: > > > > > > > > > > > Jiri, > > > > > > There is one thing that bothers me; ST_Within and similar doesn't > > > > follow > > > > > > the Java convention at all. I have researched and seen that many > > DBs > > > > uses > > > > > > this, but don't you think we should lower case st_ instead for > > > methods? > > > > > > > > > > > > > > > > > > Cheers > > > > > > -- > > > > > > Niclas Hedhman, Software Developer > > > > > > http://zest.apache.org - New Energy for Java > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Niclas Hedhman, Software Developer > > > > http://zest.apache.org - New Energy for Java > > > > > > > > > > > > > > > -- > > Niclas Hedhman, Software Developer > > http://zest.apache.org - New Energy for Java > > > -- Niclas Hedhman, Software Developer http://zest.apache.org - New Energy for Java
