Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (523)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (591)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  More API Feedback  (Read 3105 times)
0 Members and 1 Guest are viewing this topic.
Offline gregorypierce

Senior Devvie




I come upon thee like the blue screen of death....


« Posted 2003-07-10 18:46:52 »

Please unprotect the methods in GLCanvas. We really don't need the GLCanvas to become more robust (in a manner of speaking), we need the access methods to just get out of the way so we can do what we need to do. Please please please do not put in finals or privates into core API methods because if we need to extend JOGL classes (and we will need to) we shouldn't need to hack the JOGL sources and rebuild in order to get things working (which is what we're all doing now).

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline Markus_Persson

JGO Wizard


Medals: 16
Projects: 19


Mojang Specifications


« Reply #1 - Posted 2003-07-10 21:09:54 »

I second that.

Play Minecraft!
Offline moorej

Senior Newbie




Mmmm Lasagna....


« Reply #2 - Posted 2003-07-10 22:28:21 »

I've already started a thread on extending GLCanvas and will continue to support removing of all unnecessary final declerations, particulary for the sake of "safety".  I can respect the motivations and if that is a concern, make a SafeGLCanvas that extends GLCanvas that restricts people from mucking where they shouldn't, if they do not understand the problems that are inherent.

-Jason
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #3 - Posted 2003-07-11 00:15:43 »

Yes, it seems that a list of best practices would be better overall than.. brick walls and handcuffs.

The problem with 'final' is that it's final.  You are making assumptions that no reason for it to not be final will be found in the future.

Wrapping with a 'Safe' class sounds like a good idea, if not just for the fact that the very existence of a 'safe' class will imply the need to be careful with the other.

Similar arguments have been made for other aspects of the JRE.. like synchronization in collection classes that could have been done with synchronized wrapper classes.

Offline gregorypierce

Senior Devvie




I come upon thee like the blue screen of death....


« Reply #4 - Posted 2003-07-11 15:53:27 »

I think that the idea of a SafeGLCanvas class (or similar) would be an EXCELLENT idea. You can finalize that to your hearts content and even write demos and the like with it so that newbies try to use it by default, but leave the door open for the rest of us who know what we're doing (and why) to do what needs to be done Smiley

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline Mojomonkey

Senior Devvie




ooh ooh eee eeee


« Reply #5 - Posted 2003-07-11 16:06:20 »

Quote
rest of us who know what we're doing (and why) to do what needs to be done


Like who?  Wink

Don't send a man to do a monkey's work.
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #6 - Posted 2003-07-12 04:10:27 »

Quote
Please unprotect the methods in GLCanvas. We really don't need the GLCanvas to become more robust (in a manner of speaking), we need the access methods to just get out of the way so we can do what we need to do. Please please please do not put in finals or privates into core API methods because if we need to extend JOGL classes (and we will need to) we shouldn't need to hack the JOGL sources and rebuild in order to get things working (which is what we're all doing now).


Please look at the implementation of GLCanvas; it is nearly trivial and can be completely reimplemented at the application level if this is necessary (i.e., for users who know what they are doing). Alban Cousine has already done this in his OpenMind engine and said that it worked like a charm. The only risk you run is that you will be using APIs in the jogl.impl package and these may change.

The issue with the final keyword in API design is that one can always make a final class non-final and still maintain binary compatibility, but one can not make a non-final class final. In other words, from an API evolution standpoint, it's better to keep it more restrictive at the beginning and loosen it as necessary later.

So far I've heard only one compelling argument for making GLCanvas non-final, and that is so that events can be passed off to the application maintaining the same source component. This can be done without throwing away all of the safety features of the current GLCanvas by making a few key methods, instead of the entire class, final. If you have a compelling technical reason or application example that requires overriding these methods, please post it.

There is a somewhat orthogonal issue that has an RFE filed for it which is to allow a GLDrawable to be "attached" to an arbitrary Canvas. This can be done without changing GLCanvas and, I think, without exposing any more GLDrawable implementations in the public API (though there may need to be a new GLDrawable subinterface like GLPbuffer).
Offline Markus_Persson

JGO Wizard


Medals: 16
Projects: 19


Mojang Specifications


« Reply #7 - Posted 2003-07-12 13:28:57 »

I really don't understand why you want to protect developers from themselves..  Huh

Polymorphism is a BIG part of Java, and it pretty much always leads to the same problems you're trying to stop here by making the classes and methods final.. abusing the API will break the code.
But that's up to the developer using the API, not the API-provider. Just state clearly in the javadocs how you're supposed to use the methods, and most people should manage fine.

And if they don't, just say "rtfm" and get on with your life.  Grin

Play Minecraft!
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #8 - Posted 2003-07-12 23:46:13 »

Quote
I really don't understand why you want to protect developers from themselves..  Huh


I suppose because that is what Java has been about from the beginning... GC, no pointers, bounds checking on arrays...  all of these things are about protecting programmers from themselves.  To a large extent it works...

If it is easy to write your own replacement for GLCanvas, then instead of arguing this point lets just make the alternative class to GLCanvas and keep it in the shared files section of the jogl project.

I don't know enough about OpenGL to comment on how much the current implementation might restrict the programmer for practical use in Java games.  Without examples maybe it is best to keep things final as long as nobody has a reason to extend them.

Offline gregorypierce

Senior Devvie




I come upon thee like the blue screen of death....


« Reply #9 - Posted 2003-07-13 01:20:19 »

Well.... one simple thing that I know a couple of people have pinged me on is recreating GLAnimatedCanvas from GL4Java. While it is true that you can simply create your own GLDrawable to accomplish this, it would have been a heck of a lot cleaner from an API perspective to extend GLCanvas and integrate the animator into that class.

I would personally argue that there is a difference between what garbage collection does and what final does (for example). Its really a difference between giving the user the ability to do evil bad things to the JVM and being able to create a potentially dangerous API construct. Personally I don't see the point of it being final since there are no true native bits in GLCanvas that shouldn't be extended. The only real reason to use final IMO is if you have something that HAS to work a particular way or it will break things - like making native methods final.

Nevertheless, I would rather not see JOGL fragment so early in the tree with everyone creating their own versions of GLCanvas and such because that will make it all the more difficult to share code later on because people are changing core classes. But to each their own - there is a workaround, but from an engineering perspective I just don't like the ramifications of it.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Markus_Persson

JGO Wizard


Medals: 16
Projects: 19


Mojang Specifications


« Reply #10 - Posted 2003-07-13 10:48:08 »

Quote
I suppose because that is what Java has been about from the beginning... GC, no pointers, bounds checking on arrays...  all of these things are about protecting programmers from themselves.  To a large extent it works...


Good point, but that is different. Being able to extend classes to customise their behavior for your own need is ALSO what java has been abour from the beginning.  Wink

But it doesn't matter, really. I've managed to adapt without having to implement my own classes, but it WOULD be nice to have a direct swapBuffer() call.
(something that would not be possible even by writing your own GLCanvas, iirc)

Play Minecraft!
Offline TheBohemian

Junior Devvie




Java will rule them all!


« Reply #11 - Posted 2003-07-17 22:49:16 »

What about the other way round?
Instead of creating a separate SafeGLCanvas there should be a final GLCanvas and an AbstractGLCanvas. The first subclasses AbstractGLCanvas and is final. The AbstractGLCanvas is implemented as minimally as needed and has exhaustive javadoc added to every critical method.

I read an argument on this board that sublassing of a GLCanvas-like class caused much trouble in GL4J. The Javadoc of AbstractGLCanvas should inform the developer about the difficulties that may arise.

How about that?

cya

TheBohemian

---------------------------------------
my favorite OS: http://jnode.sf.net
Java 1.5 -> 1.4 converter: http://retroweaver.sf.net
Offline gregorypierce

Senior Devvie




I come upon thee like the blue screen of death....


« Reply #12 - Posted 2003-07-17 23:37:30 »

Same difference  Grin It all comes down to building a base class that could be extended for any purpose and leaving documentation to warn people what their behavior should be but not put in any implicit constructs to prohibit a behavior just because someone *might* mess up.

Mistakes happen, that's how people learn. Trying to make it impossible to make mistakes is only going to create the following impressions:

* you're limiting my abilities
* you believe you have all the answers to MY problems
* you're letting your personal experience dictate my development
* you don't value my input

These things I get from my management courses. And interestingly note how these impressions are already starting to come out.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline josgood

Senior Newbie




Nudge reality.


« Reply #13 - Posted 2003-07-20 16:47:20 »

Quote

Trying to make it impossible to make mistakes is only going to create the following impressions:

* you're limiting my abilities
* you believe you have all the answers to MY problems
* you're letting your personal experience dictate my development
* you don't value my input

...


And your point is?

Haha, I'm just pulling your leg.

I have to comment on this one.  Be careful of what you wish for.  JOGL's (nee Jungle) GLComponent, Animator, et al are complicated, tightly coupled, and the desired (proper) behavior isn't explicit.  I spent quite a while figuring out how it worked, and I already knew what was supposed to happen.

Philosophy aside, I just don't think it's practicle to extend (subclass) JOGL's GLComponent.  I think Ken Russell mentioned that OpenMind just did their own GLComponent.  Sounds about right.


Cheers, Jason
Offline Markus_Persson

JGO Wizard


Medals: 16
Projects: 19


Mojang Specifications


« Reply #14 - Posted 2003-07-20 16:56:13 »

He also said that to do that you have to use classes from the impl package, and that package might change without notice.  Wink

Play Minecraft!
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Gibbo3771 (5 views)
2014-11-24 19:59:16

trollwarrior1 (35 views)
2014-11-22 12:13:56

xFryIx (73 views)
2014-11-13 12:34:49

digdugdiggy (52 views)
2014-11-12 21:11:50

digdugdiggy (46 views)
2014-11-12 21:10:15

digdugdiggy (40 views)
2014-11-12 21:09:33

kovacsa (66 views)
2014-11-07 19:57:14

TehJavaDev (70 views)
2014-11-03 22:04:50

BurntPizza (68 views)
2014-11-03 18:54:52

moogie (83 views)
2014-11-03 06:22:04
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!