Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jts-dev] JTS deprecations
2016-11-11 7:38 GMT+01:00 Martin Davis <mtnclimb@xxxxxxxxx>:


On Thu, Nov 10, 2016 at 10:24 PM, Björn Harrtell <bjorn.harrtell@xxxxxxxxx> wrote:
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.

If the array is empty it doesn't matter what the type is - it is an empty MultiPoint.  Realize that it might be a pain to check type for non-null - but overloading is too useful for Java APIs to want to eliminate it.  (As I understand JS, usually overloading is done by runtime type checking?) 

I do not mean to advocate eliminating the use of overloading in Java. I do have a generic logic that emulates overloading in the transpilation by runtime type checking in the resulting _javascript_, including checks for null, which works in many cases and can perhaps be improved further to handle createMultiPoint. But there are some cases when I think runtime resolution is impossible because the information is lost. For example if you overload on a single parameter, in the first signature the parameter is of type Object and the second it is of type String (which inherits from Object). If you call this overload with null as the value, the Java compiler will choose the overload that takes a String because of a rule in Java that the "most specific" candidate is to be chosen.


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.

Providing a no-arg method makes very good sense, so +1 for this. 

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örn

2016-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







Back to the top