• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Extending a class, have a problem

 
Ranch Hand
Posts: 750
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, I have extended the Polygon class, in this class I have a method, which then calls contain(Point p)



And this works incorrectly, but still kinda works.

However instead of that last line, if I do...

Then it functions perfectly, but I don't see the difference,
I have set up the correct variables, or perhaps it is something to do with the bounds field of Polygon,
which I have not initialized in this subclass.

Any ideas, thanks
 
Bartender
Posts: 4116
72
Mac TypeScript Chrome Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Where is this code located? Without looking at your Polygon class & any other class(es) involved it's hard to see what's wrong.
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Colin,

What you're doing should work unless you've overridden one or more of the other methods in Polygon so that they return incorrect results. For example, have you overridden getBoundingBox() or getBounds()? If these are broken, then contains() will be broken too.
 
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I've checked the source of Polygon, and it first checks getBoundingBox. This method uses a cached version of the bounds, in field "bounds"; if that isn't set it will call calculateBounds. That method has default accessibility though so you can't call it. All that remains is to set "bounds" to null, and it will be recalculated.
 
colin shuker
Ranch Hand
Posts: 750
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks, I might try that.

I did put the code back to just using a Polygon instead of extending, but that might be more efficient,

I figured it had something to do with bounding box being set when object is instantiated, I will try the null thing, will let you know.

Thanks
 
Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

colin shuker wrote:Thanks, I might try that.



Don't do that. Looking at "the source" is bad advice. Never make your code dependent on the observed behaviour of a specific Java implementation. It breaks encapsulation which is potentially disastreous. Instead always write implementation independent code.

Only rely on what's explicitly stated in the Sun API definition for Polygon (it's as good as a standard).
 
Rob Spoor
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Ulrika Tingle wrote:

colin shuker wrote:Thanks, I might try that.



Don't do that. Looking at "the source" is bad advice. Never make your code dependent on the observed behaviour of a specific Java implementation. It breaks encapsulation which is potentially disastreous. Instead always write implementation independent code.

Only rely on what's explicitly stated in the Sun API definition for Polygon (it's as good as a standard).


While I agree with you in the general case, in this case these fields are part of the API and will not change in type, meaning or visibility. The Javadoc states that bounds can be null and that getBoundingBox and getBounds return the bounding box of the Polygon. Therefor, nulling this field is perfectly safe.
 
Ulrika Tingle
Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Rob Prime wrote:While I agree with you in the general case, in this case these fields are part of the API and will not change in type, meaning or visibility. The Javadoc states that bounds can be null and that getBoundingBox and getBounds return the bounding box of the Polygon. Therefor, nulling this field is perfectly safe.



Well, as long as you stick to information availble in the Sun API only there will be no problems, but then there should be no need for any looking at some "the source" really.
 
Rob Spoor
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You are right. In fact, there is a method I missed out that should be called instead: invalidate.

Invalidates or flushes any internally-cached data that depends on the vertex coordinates of this Polygon. This method should be called after any direct manipulation of the coordinates in the xpoints or ypoints arrays to avoid inconsistent results from methods such as getBounds or contains that might cache data from earlier computations relating to the vertex coordinates.


Of course the only thing this method does at the moment is set bounds to null, but it may do more so this method is preferred over nulling bounds directly.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic