GdkGraphics extending Graphics2D?

[S. Meslin-Weber]

Hi Everyone,

Following a very brief discussion on irc with Michael we thought that
broader input would help resolve:

https://savannah.gnu.org/bugs/?func=detailitem&item_id=12211

Namely, should GdkGraphics extend Graphics (as it does now) or
Graphics2D?

The argument against (corrections please) is that Graphics2D implies
more functionality than is currently available either in our AWT/Swing
or in the underlying native layer.

The argument for is Sun's (and IBM's) doing unfortunately. Since 1.2(?)
JComponent.paint() gets passed a Graphics2D object in the majority of
cases[1] and people are writing production code such as the following
example habitually.

  public void paint(Graphics g) {
    Graphics2D g2 = (Graphics2D) g;
    g2.draw(new Rectangle());
  }

Worse is that publications teaching usage of Swing encourage this usage.

I propose that GdkGraphics be made to extend Graphics2D with dreaded
stub methods to make it behave like a standard Graphics instance.

I realise that subbed classes hide incomplete implementations at
compilation time[2] (heaven knows this has been discussed heavily in the
past) but what concerns me now is making this work at runtime.

Comments welcome! :)

Best regards

Steph

[1] The degenerate case in this instance is the use of DebugGraphics
[2] Stubbed methods can be caught reasonably easily by static analysis
either by an IDE or other command line tools.

-- 
================================================================
Stephane Meslin-Weber         Email: address@hidden
Software Engineer             Web: http://odonata.tangency.co.uk
================================================================

signature.asc
Description: Digital signature