| Re: [jts-dev] JTS deprecations |
The problem for transpilation has nothing specifically to do with deprecations or constructors per se.Overloaded constructors and/or methods can be equally problematic for the transpilation but only in some cases. It boils down to that in _javascript_ overloading can only be implemented using runtime introspection of the actual passed parameter(s).For example createMultiPoint in GeometryFactory has this problem, specifically the two versions that takes Coordinate[] and Point[] respectively. The type of array is erased in transpilation and the array might also be empty so there is no good way to introspect the parameter in runtime.
A similar case is when null values are valid input for overloaded parameters which is why I have, for the JTS fork used for transpilation, introduced parameterless versions of the create* methods in GeometryFactory to create empty geometries and changed calls to for example createPoint(null) to createPoint() throughout the JTS source.
So, you are right that it will not be necessary to remove all deprecations and I'll be glad to work on a PR with the removals I'd like to see for the benefit of transpilation and hopefully follow that up with additional PRs that will make my fork obsolete./Björn2016-11-10 22:49 GMT+01:00 Martin Davis <mtnclimb@xxxxxxxxx>:Absolutely the next major version (JTS 2) will start with a clean, non-deprecated API.I sympathize with wanting to remove the deprecated constructors. In fact all Geometry subclass constructors should not be public, to allow transition to an interface-based API.Are deprecated methods a real problem for you? Can't you just transpile them along with everything else?So overloaded constructors are a problem for the transpiler? The JTS fix will be to kick the problem up into GeometryFactory - are overloads there ok?The 1.15 version is probably as good a time as any to do this, since it's not a drop-in upgrade.It would be best if you can log an issue or even better a PR containing the deprecations which you need to have done (PR will let us see exactly which). It sounds like its not necessary to do a clean sweep of deprecated methods - if not that reduces the workload to merge and test.On Thu, Nov 10, 2016 at 11:50 AM, Björn Harrtell <bjorn.harrtell@xxxxxxxxx> wrote:Yes, I currently need to remove them for the JSTS transpilation, mainly because of the numerous overloaded constructors for geometries which would be hard to get right and if I remember correctly a few methods too (deprecated classes can be ignored without patching the source). It's not that big of a problem as a removal patch is easy to maintain, but would of course be preferable to be able to avoid patching at all.But I was also wondering about it in the context of JTS future and maintainability. Would be a nice cleanup I think, although perhaps no big deal. However, if the next major version does not aim for API compatibility in general I don't see the rationale for having or keeping deprecations forever in the current series.2016-11-10 18:01 GMT+01:00 Martin Davis <mtnclimb@xxxxxxxxx>:You mean everything with the @deprecated annotation? Classes and/or methods?Is this to simplify the JSTS transpilation?On Thu, Nov 10, 2016 at 2:40 AM, Björn Harrtell <bjorn.harrtell@xxxxxxxxx> wrote:______________________________Hi devs,I was wondering, how do the maintainers feel about removing deprecations for the next release of JTS?/Björn_________________
jts-dev mailing list
jts-dev@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.locationtech.org/mailman/listinfo/jts-dev