Polygon.getHoles() missing about poly2tri HOT 5 CLOSED

p.s. I'm referring to Java version of Poly2tri library.

Well when adding holes what you actually do is add points and constraints for 
the triangulation. This data you should already have before using poly2tri to 
triangulate so I don't see why you need poly2tri to return these holes?

Outer hull, holes and steiner points are all just bunched up as a list of 
points and constraints when triangulating. What you get in return is the 
triangles that are considered to be inside of the polygon.

addHole is just a convenient way of adding points and edges to the 
triangulation context. There is really no holes to return after triangulation.

I know that getHoles() would return the same points that I gave it using 
addHole() method, and yes I could just save those points somewhere else in my 
program and use Hashtable to match it with any given Polygon object, but why 
are you forcing this inconvenience on us??

I need getHoles() for my own calculations. For example, I add holes in one part 
of my code and in a different part I need to read the holes and adjust them to 
ensure they don't collide with each other.

You already have a getPoints() method, why not add a getHoles() method too? 
It's standard practice that every setter would have a getter so that you don't 
lose access your own input data.

I'm not really happy with the API interface. I had plans to make a Polygon 
manipulation library and have the Polygon class be used by several different 
tools not just triangulation.

Since that didn't come to fruition I would rather have seen Polygon class just 
as a context for for passing data to the triangulator.

To solve your issue just do

package org.poly2tri.geometry.polygon;

public class MyPolygon implements Polygon
{
    public List<Polygon> getHoles()
    {
        return _holes;
    }
}

and use that instead of Polygon

Your solution is actually what I had already implemented. But still, I think 
many of your non-pro users wouldn't recognize that _holes is protected and can 
be access this way. Also is add one more class to project that was otherwise 
unnecessary.

Furthermore, it's inconsistent with the current API. You have getPoints() 
methods but not getHoles(). If you decided to make Polygon just a context for 
passing data, are you going to remove getPoints() as well? That'd be even more 
inconvenient but at least consistent with not having any getters.

My thoughts is that the majority of the users of your library expect getters 
and are surprised that there is a missing getter. A simple shortcoming like 
that could deprive you of thousands of potential users because most would 
assume that missing basic getters is a sign that library is not complete and/or 
reliable. Whereas in reality I think it's a fantastic library.