Speaking of theory vs. the nuts & bolts of coding, are there any good, free resources that deal with the theory side of things?
Make thedailywtf.com one of your daily visits. I recommend avoiding the forums there, the posters read like they're all slashdot graduates, but having a code example a couple times a week with an explanation why it's bad can be quite valuable.
There's a number of neat essays on the site as well, detailing experiences of veteran programmers who have lived in the so-called trenches.
Also, you never know when the answer to a question might be bubble sort. Never hurts to know the absolute worst sort you could choose.
Sometimes you don't have access to a library (or the in built library is broken due to overflow errors - Actionscript/Flash Player I'm looking at you) and the array you need to sort is like 10 items long, and you don't have to do it that frequently. and you really want to understand the code when you read it again in 6 months time.
I'd totally use selection sort in that situation but for other Bubble sort is the algorithm they instinctively grok.
For something 10 items long, who cares if your in the worst case. Bubble sort works fine for small quick n dirty. Just, not elsewhere
You know, I've never been in a position where I couldn't use a pre-built sort function and also didn't need something scalable. I either use whatever sort is available or write my own quicksort. Of course, I haven't done a lot of mobile development yet, so maybe it's more prevalent there?
Who knows, I was just saying that assumung that you had no prebuilt sort. Any kind of prebuilt sort is going to be better than bubble sort. Especially Pythons sort.
If I need something quick, I'd go for insertion sort. It's still easy to write, and while the worst case is O(n^2), in reality it's usually much less than that. If the list is already sorted (or near sorted) the sort time is actually linear. Because of this, it can sometimes be a better option than quicksort even on non trivial cases.
Just wanted to pipe up and mention something based on this last page: sorting is an interesting topic. The theory is fascinating and sorting algorithims make for good practice projects.
But speaking as a senior dev who has been working in UI programming in many languages and platforms for a number of years now: I have never, ever had to implement a sorting algorithm for work.
It would be absolutely insane for a C# programmer (for example) to build their own sorting routine instead of using the built in sort (especially with lambda expressions) unless they had damn good evidence staring them in the face that the improved efficiency would:
1) make any difference in the overall perf of the program (usually: no)
2) be worth the time to create and (much more importantly) debug and support this custom code
Anyway, if you want suggestions for what to learn about (that is not platform / language specific) that is useful in a programming job my recomendation is learning about estimating (eg: figuring out how long it will take to complete a task and what resources are needed) and project management.
For a developer coding skills are important but are a distant second to estimating and staying on schedule. (a distant third to estimating, scheduling and people skills if you are a lead dev).
Knowing algorithm theory will let you actually figure out why your code is running like shit. Otherwise it's just black-box sort function calls or code that is so naive but you're oblivious.
Usually the standard sort library in a language is sufficient for me though, agreed. With comparers they can accommodate whatever and if the speed or function is not satisfactory, then I'll worry about custom coding up something.
But it is indeed rare for most developers.
Infidel on
0
Options
HalibutPassion FishSwimming in obscurity.Registered Userregular
Just wanted to pipe up and mention something based on this last page: sorting is an interesting topic. The theory is fascinating and sorting algorithims make for good practice projects.
But speaking as a senior dev who has been working in UI programming in many languages and platforms for a number of years now: I have never, ever had to implement a sorting algorithm for work.
It would be absolutely insane for a C# programmer (for example) to build their own sorting routine instead of using the built in sort (especially with lambda expressions) unless they had damn good evidence staring them in the face that the improved efficiency would:
1) make any difference in the overall perf of the program (usually: no)
2) be worth the time to create and (much more importantly) debug and support this custom code
Anyway, if you want suggestions for what to learn about (that is not platform / language specific) that is useful in a programming job my recomendation is learning about estimating (eg: figuring out how long it will take to complete a task and what resources are needed) and project management.
For a developer coding skills are important but are a distant second to estimating and staying on schedule. (a distant third to estimating, scheduling and people skills if you are a lead dev).
I 100% agree. In the professional world, you don't need to know how to implement just about any data structure or sorting algorithm.
However, knowing how they work, and the performance characteristics of each will take you a very long way down the path of being a good programmer.
Like I said earlier, knowing when and how to use one is far more important than knowing what's inside the black box (although knowing what's in that box will usually help with the when and the how).
Also, you never know when the answer to a question might be bubble sort. Never hurts to know the absolute worst sort you could choose.
Hey, now. Bubble sort is still a guaranteed O(n^2). Now, random sort (randomize the list, see if it's sorted, and repeat if not) is in the average case O(n!) and is in the worst case O(inf).
Of course, I guess it doesn't fit the "you could choose" part of that sentence.
Guys, how exactly would you structure an object oriented state machine for a game, and why would it be better than just using a simple switch statement for all your states?
Guys, how exactly would you structure an object oriented state machine for a game, and why would it be better than just using a simple switch statement for all your states?
There are so many questions embeded in this one.
The first and most important question you need to ask yourself (which should be asked whenever you use a design pattern) is why am I using a state machine? Does that really apply here? What am I trying to acomplish?
So, to even begin to answer your question we would need to know roughly what kind of game you are making. What different states you think it could take and how they relate to one another etc...
BTW: What do you mean by "object oriented state machine" and how would that relate to a "simple switch statement"?
But, it might be better to narrow down what exactly you are trying to learn; .Net covers two distinct desktop GUI libraries, COM automation interop, WCF, ASP, ADO, and about a dozen other technologies, and a whole load of languages, C# and VB.Net chief among them. A general .Net book isn't going to give you much more than a tour guide overview of all the different shit.
If you want a suggestion for increasing your marketability quickly, and you think you're in a Microsoft heavy area, I'd suggest two books: one on C# and one on ASP.NET.
Edit: Depending on what you've been doing in school, you could skip the C# book. It doesn't take much to figure it out if you already know some Java
Also very marketable right now (in Microsoft areas such as Seattle): Silverlight (the actual coding side of things) and WPF UI.
Both of which dovetail nicely with ASP.NET and SQL of course.
A switch statement where you do different things depending on the state is like a state machine
"Every game has a state machine..." is debatable. And only true if you have such a broad definition of "state machine" as to be pretty much pointless.
Certainly any game much more complicated than breakout has a single switch statement based on a single global state.
If you want to know (and I quote from your first question) "how exactly" to do something you need to provide a ton of detail about what you want to do.
BTW: What do you mean by "object oriented state machine" and how would that relate to a "simple switch statement"?
Does that mean "How would I implement a state machine in an object oriented manner?"
e.g.
class CGameState
{
public:
virtual CGameState *getNextState() = 0;
};
class CStartGame : CGameState {};
class CCalculateNextMove : CGameState {};
class CWaitForPlayerAction : CGameState {};
...
CGameState *pCurrentState = new CStartGame;
while(!bEndGame)
{
// TODO: Stop leaking memory like a sieve!
// getNextState() does things like get the user input, and decides what the next state should be?
pCurrentState = pCurrentState->getNextState();
...
}
And look Obs... oops I mean ಠ_ರೃ, I did not say a game would not have a state machine. I said that given a sufficiently broad interpretation of the word you can always find one somewhere. It is not a useful statement or a useful way of approaching the problem of starting a game (if that is indeed what you are doing).
For example, if you are coding in an event driven framework you would have a "state machine" of some kind (in that you have one or more goddamn variables, that is how vauge and useless the term is) but you might not have a "switch statement".
You asked about (and again I quote) "exactly how" to code something. What states does your game have? Any non-trivial game will have many hierarchially nested states. How do they relate to each other? What framework are you using? How does your game approach threading? These things matter.
I said how would you structure an object oriented game state machine.
Like, would you basically just have every state represented as an object, and then whenever you change states you just delete the old state object and initialize a new object for the state you want to use?
I said how would you structure an object oriented game state machine.
Like, would you basically just have every state represented as an object, and then whenever you change states you just delete the old state object and initialize a new object for the state you want to use?
This question is impossible to answer. Not enough information to make an informed decision about what approach would be "better" and why.
For example, its a really bad idea to be creating or deleting objects (or allocating / deallocating memory) frequently. Those operations are always expensive. But maybe in your game the state doesn't change often enough for that to be a problem? We have no way to know.
Main Menu
Settings
Achievements
Map Screen
Game Level
Paused Game
Game Over
And in each state the game has to be doing different stuff.
Now, ordinarily I could just make a global state variable and have a switch statement in my game loop and basically do different work for all the possible cases.
But some say that a better way to do this is through an object oriented approach.
I'm not really sure what the advantage is, except maybe more code reuse? Though it's not like I'm copying and pasting a lot of code across different states with my switch statement anyway. I'm also not exactly sure how this works. When I change state is that merely replacing some active state object with another state object? Does the original state get deleted when the new one replaces it? Kind of expensive.
Q: Are there any languages that allow interfaces to declare/specify variables, instead of just functions?
In AS3, you can only specify functions. Kinda annoying since a lot (a TON) of extend-able classes have ridiculously commonly used properties which... interferes and forces me to write a lot of unnecessary getter/setters.
Does the original state get deleted when the new one replaces it? Kind of expensive.
That, admittedly, was just a really quick and dirty example.
I'm sure there are better ways to do it.
I would say create an interface or abstract class (I don't remember what the equivalent is in C++) that has whatever common stuff you need when the program is at each state, and maybe 3 methods for setting up, running, and shutting down each state. Have each state implement this interface.
This will specify what each state should do when you switch to it, when it's running, and when you switch from it. A simple piece of code can then switch between two states in a common way. For states that can be instantiated/destroyed every time you switch them, you can put that code in the setup and shutdown methods. For states where that would be too expensive, write the logic accordingly.
The last step is to manage the states (the state machine). It's not really a state machine if you can get to any state from any other state.
Honestly, I don't think a traditional state machine is necessary for this situation. Just instantiate each state object with a reference to a common state manager. When the current running state notices that it should go to a different state (like for game over, or menu), have it tell the state manager what state it should switch to. The state manager should handle shutting down the current state and starting up the new state.
There are some cases where the current running state shouldn't make a call to change to a different state. An example would be where the escape button is pressed and the program needs to exit no matter what state you're in. You don't want to duplicate that logic in each state, so global state change events should be handled in the state manager. This kind of thing breaks the idea of what a state machine is, but I wouldn't get caught up in the semantics.
Halibut on
0
Options
HalibutPassion FishSwimming in obscurity.Registered Userregular
Interfaces, in the AS/Java/C# meaning of the word, just specify a contract, they aren't an implementation sharing mechanism.
So my answer would be (broadly) no, there are no languages that let you share implementation via a public method contract specification construct.
There are languages that let you do multiple inheritance which is sort of what you are asking for (unless I'm completely missing the question). C++ does it poorly. Scala does it pretty well.
Here is an example of how you do it in Scala (interfaces and abstract classes are both called traits in Scala):
trait CommonStuff{
var commonField:Int = 0;
def implementThisMethod();
}
trait AnotherCommonThing{
var commonThing:String = "1234"
def implementedMethod() { println("common method implementation") }
def implementThisMethodToo();
}
class Test extends CommonStuff with AnotherCommonThing{
def implementThisMethod(){println(commonString)}
def implementThisMethodToo(){println(commonField)}
}
If you try to extend 2 traits with the same method signature, you will get a compiler error.
Does the original state get deleted when the new one replaces it? Kind of expensive.
Basic logic algorithms and operations are very rarely 'expensive' when it comes to gaming, inevitably the main expenses you need to worry about are managing populous objects(like if your dwarf simulation gets 10,000 cats and you have to simulate setting them all on fire), pathfinding and graphics.
Does the original state get deleted when the new one replaces it? Kind of expensive.
Basic logic algorithms and operations are very rarely 'expensive' when it comes to gaming, inevitably the main expenses you need to worry about are managing populous objects(like if your dwarf simulation gets 10,000 cats and you have to simulate setting them all on fire), pathfinding and graphics.
Just put all the cats in boxes and market your game as a psychological thriller.
Interfaces, in the AS/Java/C# meaning of the word, just specify a contract, they aren't an implementation sharing mechanism.
So my answer would be (broadly) no, there are no languages that let you share implementation via a public method contract specification construct.
Random geek point scoring. It's been aaaaaages since I used the language but I think Ada95 would allow you to do so. It would spit in your face and call you rude names as you did so but I believe you could do so given what can go in a spec file.
Jasc, you could create a "fake" Abstract class from your interface and declare your variables and have the functions throw illegal operation errors. That's the cleanest way I know to do it. I'm pretty judicious in my use of Interfaces and Abstract classes while I work.
Starfuck on
jackfaces
"If you're going to play tiddly winks, play it with man hole covers."
- John McCallum
Interfaces, in the AS/Java/C# meaning of the word, just specify a contract, they aren't an implementation sharing mechanism.
So my answer would be (broadly) no, there are no languages that let you share implementation via a public method contract specification construct.
Random geek point scoring. It's been aaaaaages since I used the language but I think Ada95 would allow you to do so. It would spit in your face and call you rude names as you did so but I believe you could do so given what can go in a spec file.
Eh, I really think there's a lot of misunderstanding re: contracts vs implementation here.
Jasconious' question was essentially meaningless. AS3 "Interfaces" specify contracts; contracts, by definition, do not impose implementation.
So when I said, there are no languages with contract specification mechanisms that let you share implementation, it was kind of a joke answer. Any language feature which lets you share implementation is, by definition, not a contract mechanism.
Also, Ada95 packages are basically class analogues in most other OO languages. A package spec can be a package in-and-of-itself if it is complete enough, and can be inherited from.
Does the original state get deleted when the new one replaces it? Kind of expensive.
Basic logic algorithms and operations are very rarely 'expensive' when it comes to gaming, inevitably the main expenses you need to worry about are managing populous objects(like if your dwarf simulation gets 10,000 cats and you have to simulate setting them all on fire), pathfinding and graphics.
Just put all the cats in boxes and market your game as a psychological thriller.
Oddly enough that's usually exactly what happens in dwarf fortress.
Jasc, you could create a "fake" Abstract class from your interface and declare your variables and have the functions throw illegal operation errors. That's the cleanest way I know to do it. I'm pretty judicious in my use of Interfaces and Abstract classes while I work.
Yeah I see what you are saying, but in Flash, and AS3 in particular, you can have functionally different elements with different base classes that both have the need for an end-result set of methods.
In particular MovieClip and Sprite, which co-exist badly.
Both are used for displaying, but you couldn't make an Abstract class to subclass from for both, you'd have to make two abstract classes and maintain both, which would be silly.
Interfaces, in the AS/Java/C# meaning of the word, just specify a contract, they aren't an implementation sharing mechanism.
So my answer would be (broadly) no, there are no languages that let you share implementation via a public method contract specification construct.
Random geek point scoring. It's been aaaaaages since I used the language but I think Ada95 would allow you to do so. It would spit in your face and call you rude names as you did so but I believe you could do so given what can go in a spec file.
Eh, I really think there's a lot of misunderstanding re: contracts vs implementation here.
Jasconious' question was essentially meaningless. AS3 "Interfaces" specify contracts; contracts, by definition, do not impose implementation.
So when I said, there are no languages with contract specification mechanisms that let you share implementation, it was kind of a joke answer. Any language feature which lets you share implementation is, by definition, not a contract mechanism.
Also, Ada95 packages are basically class analogues in most other OO languages. A package spec can be a package in-and-of-itself if it is complete enough, and can be inherited from.
Maybe I am misunderstanding the purpose of interfaces. I am using interfaces as a means to cast objects of different origins in AS3 to a common interface so I can execute a particular set of methods.
So, instead of making every display object in my entire project a movieclip (which accepts dynamic method calls much like Obj-C objects accept messages even if there is no associated method), I can pass around more generic DisplayObjects, cast them as IInterfaceName, and execute the method I want.
This approach might be entirely born out of the weird ass sibling relationship between MovieClip and Sprite in AS3, and as such is unique to Flash. I don't know. My alternative would be doing try/catches trying to cast my argument to any of the possible custom types I created that end up getting passed to the function.
And I have websense at work so I won't be able to continue this discussion till I get home tonight!
Language: Java
Framework: JEE, Spring, Hibernate, Struts
Purpose: Web Development
Summary: I do J2EE web development for my job. It's pretty awesome and I get to work on a variety of interesting problems. I work on all tiers of these systems from the UI down to the database and integration with legacy systems.
If you want massively scalable enterprise web applications then Java is one of the best decisions you could possibly make. The only thing that would make me love my job more is if we switched to Scala instead of Java.
That said, if you want to create a small-medium sized webapp, then Java and all of its enterprise-centric design decisions will probably be overkill. You're probably better off sticking with Python or Ruby or PHP (unless you just prefer static typing, or still need things to perform fast, or whatever reason makes Java more appealing to you).
What is so good about it? It seems like I have to reinvent the wheel at every turn, and Java is like a language that forgot to have anything fun or cool. It's like someone took C++ and removed the insanity, but also half the features and all traces of personality. Granted, the project I am working on uses no libraries except an object-relational mapper written by my employer and I haven't been able to figure out any way to rig up a reasonable MVC system on my own, so that sucks.
Posts
Make thedailywtf.com one of your daily visits. I recommend avoiding the forums there, the posters read like they're all slashdot graduates, but having a code example a couple times a week with an explanation why it's bad can be quite valuable.
There's a number of neat essays on the site as well, detailing experiences of veteran programmers who have lived in the so-called trenches.
Sometimes you don't have access to a library (or the in built library is broken due to overflow errors - Actionscript/Flash Player I'm looking at you) and the array you need to sort is like 10 items long, and you don't have to do it that frequently. and you really want to understand the code when you read it again in 6 months time.
I'd totally use selection sort in that situation but for other Bubble sort is the algorithm they instinctively grok.
I made a game, it has penguins in it. It's pay what you like on Gumroad.
Currently Ebaying Nothing at all but I might do in the future.
See how many books I've read so far in 2010
You know, I've never been in a position where I couldn't use a pre-built sort function and also didn't need something scalable. I either use whatever sort is available or write my own quicksort. Of course, I haven't done a lot of mobile development yet, so maybe it's more prevalent there?
See how many books I've read so far in 2010
But speaking as a senior dev who has been working in UI programming in many languages and platforms for a number of years now: I have never, ever had to implement a sorting algorithm for work.
It would be absolutely insane for a C# programmer (for example) to build their own sorting routine instead of using the built in sort (especially with lambda expressions) unless they had damn good evidence staring them in the face that the improved efficiency would:
1) make any difference in the overall perf of the program (usually: no)
2) be worth the time to create and (much more importantly) debug and support this custom code
Anyway, if you want suggestions for what to learn about (that is not platform / language specific) that is useful in a programming job my recomendation is learning about estimating (eg: figuring out how long it will take to complete a task and what resources are needed) and project management.
For a developer coding skills are important but are a distant second to estimating and staying on schedule. (a distant third to estimating, scheduling and people skills if you are a lead dev).
Usually the standard sort library in a language is sufficient for me though, agreed. With comparers they can accommodate whatever and if the speed or function is not satisfactory, then I'll worry about custom coding up something.
But it is indeed rare for most developers.
However, knowing how they work, and the performance characteristics of each will take you a very long way down the path of being a good programmer.
Like I said earlier, knowing when and how to use one is far more important than knowing what's inside the black box (although knowing what's in that box will usually help with the when and the how).
Hey, now. Bubble sort is still a guaranteed O(n^2). Now, random sort (randomize the list, see if it's sorted, and repeat if not) is in the average case O(n!) and is in the worst case O(inf).
Of course, I guess it doesn't fit the "you could choose" part of that sentence.
I should really stop saying things like that. I tend to get answers like yours that I get hung up on and can't tell what you actually mean.
I presume you mean that yes, I should give myself the weekend off. Would I be correct?
There are so many questions embeded in this one.
The first and most important question you need to ask yourself (which should be asked whenever you use a design pattern) is why am I using a state machine? Does that really apply here? What am I trying to acomplish?
So, to even begin to answer your question we would need to know roughly what kind of game you are making. What different states you think it could take and how they relate to one another etc...
BTW: What do you mean by "object oriented state machine" and how would that relate to a "simple switch statement"?
A switch statement where you do different things depending on the state is like a state machine
Also very marketable right now (in Microsoft areas such as Seattle): Silverlight (the actual coding side of things) and WPF UI.
Both of which dovetail nicely with ASP.NET and SQL of course.
"Every game has a state machine..." is debatable. And only true if you have such a broad definition of "state machine" as to be pretty much pointless.
Certainly any game much more complicated than breakout has a single switch statement based on a single global state.
If you want to know (and I quote from your first question) "how exactly" to do something you need to provide a ton of detail about what you want to do.
Does that mean "How would I implement a state machine in an object oriented manner?"
e.g.
class CGameState { public: virtual CGameState *getNextState() = 0; }; class CStartGame : CGameState {}; class CCalculateNextMove : CGameState {}; class CWaitForPlayerAction : CGameState {}; ... CGameState *pCurrentState = new CStartGame; while(!bEndGame) { // TODO: Stop leaking memory like a sieve! // getNextState() does things like get the user input, and decides what the next state should be? pCurrentState = pCurrentState->getNextState(); ... }?
And look Obs... oops I mean ಠ_ರೃ, I did not say a game would not have a state machine. I said that given a sufficiently broad interpretation of the word you can always find one somewhere. It is not a useful statement or a useful way of approaching the problem of starting a game (if that is indeed what you are doing).
For example, if you are coding in an event driven framework you would have a "state machine" of some kind (in that you have one or more goddamn variables, that is how vauge and useless the term is) but you might not have a "switch statement".
You asked about (and again I quote) "exactly how" to code something. What states does your game have? Any non-trivial game will have many hierarchially nested states. How do they relate to each other? What framework are you using? How does your game approach threading? These things matter.
Like, would you basically just have every state represented as an object, and then whenever you change states you just delete the old state object and initialize a new object for the state you want to use?
This question is impossible to answer. Not enough information to make an informed decision about what approach would be "better" and why.
For example, its a really bad idea to be creating or deleting objects (or allocating / deallocating memory) frequently. Those operations are always expensive. But maybe in your game the state doesn't change often enough for that to be a problem? We have no way to know.
Yeah, that's my biggest fear right now.
Or something like this:
Or:
The first one could potentially be done as a state machine.
The last 2 are just maintaining state, but aren't really state machines.
Main Menu
Settings
Achievements
Map Screen
Game Level
Paused Game
Game Over
And in each state the game has to be doing different stuff.
Now, ordinarily I could just make a global state variable and have a switch statement in my game loop and basically do different work for all the possible cases.
But some say that a better way to do this is through an object oriented approach.
I'm not really sure what the advantage is, except maybe more code reuse? Though it's not like I'm copying and pasting a lot of code across different states with my switch statement anyway. I'm also not exactly sure how this works. When I change state is that merely replacing some active state object with another state object? Does the original state get deleted when the new one replaces it? Kind of expensive.
Well, sure. Create a few virtual functions so that stuff like user input/screen output gets redirected to the active state object's functions.
Basically, instead of using a big switch() statement, use virtual functions to accomplish the same thing.
That, admittedly, was just a really quick and dirty example.
I'm sure there are better ways to do it.
In AS3, you can only specify functions. Kinda annoying since a lot (a TON) of extend-able classes have ridiculously commonly used properties which... interferes and forces me to write a lot of unnecessary getter/setters.
So my answer would be (broadly) no, there are no languages that let you share implementation via a public method contract specification construct.
I would say create an interface or abstract class (I don't remember what the equivalent is in C++) that has whatever common stuff you need when the program is at each state, and maybe 3 methods for setting up, running, and shutting down each state. Have each state implement this interface.
This will specify what each state should do when you switch to it, when it's running, and when you switch from it. A simple piece of code can then switch between two states in a common way. For states that can be instantiated/destroyed every time you switch them, you can put that code in the setup and shutdown methods. For states where that would be too expensive, write the logic accordingly.
The last step is to manage the states (the state machine). It's not really a state machine if you can get to any state from any other state.
Honestly, I don't think a traditional state machine is necessary for this situation. Just instantiate each state object with a reference to a common state manager. When the current running state notices that it should go to a different state (like for game over, or menu), have it tell the state manager what state it should switch to. The state manager should handle shutting down the current state and starting up the new state.
There are some cases where the current running state shouldn't make a call to change to a different state. An example would be where the escape button is pressed and the program needs to exit no matter what state you're in. You don't want to duplicate that logic in each state, so global state change events should be handled in the state manager. This kind of thing breaks the idea of what a state machine is, but I wouldn't get caught up in the semantics.
There are languages that let you do multiple inheritance which is sort of what you are asking for (unless I'm completely missing the question). C++ does it poorly. Scala does it pretty well.
Here is an example of how you do it in Scala (interfaces and abstract classes are both called traits in Scala):
trait CommonStuff{ var commonField:Int = 0; def implementThisMethod(); } trait AnotherCommonThing{ var commonThing:String = "1234" def implementedMethod() { println("common method implementation") } def implementThisMethodToo(); } class Test extends CommonStuff with AnotherCommonThing{ def implementThisMethod(){println(commonString)} def implementThisMethodToo(){println(commonField)} }If you try to extend 2 traits with the same method signature, you will get a compiler error.
http://www.panda3d.org/wiki/index.php/FSM_Introduction
Basic logic algorithms and operations are very rarely 'expensive' when it comes to gaming, inevitably the main expenses you need to worry about are managing populous objects(like if your dwarf simulation gets 10,000 cats and you have to simulate setting them all on fire), pathfinding and graphics.
Just put all the cats in boxes and market your game as a psychological thriller.
Random geek point scoring. It's been aaaaaages since I used the language but I think Ada95 would allow you to do so. It would spit in your face and call you rude names as you did so but I believe you could do so given what can go in a spec file.
I made a game, it has penguins in it. It's pay what you like on Gumroad.
Currently Ebaying Nothing at all but I might do in the future.
"If you're going to play tiddly winks, play it with man hole covers."
- John McCallum
Eh, I really think there's a lot of misunderstanding re: contracts vs implementation here.
Jasconious' question was essentially meaningless. AS3 "Interfaces" specify contracts; contracts, by definition, do not impose implementation.
So when I said, there are no languages with contract specification mechanisms that let you share implementation, it was kind of a joke answer. Any language feature which lets you share implementation is, by definition, not a contract mechanism.
Also, Ada95 packages are basically class analogues in most other OO languages. A package spec can be a package in-and-of-itself if it is complete enough, and can be inherited from.
Oddly enough that's usually exactly what happens in dwarf fortress.
Yeah I see what you are saying, but in Flash, and AS3 in particular, you can have functionally different elements with different base classes that both have the need for an end-result set of methods.
In particular MovieClip and Sprite, which co-exist badly.
Both are used for displaying, but you couldn't make an Abstract class to subclass from for both, you'd have to make two abstract classes and maintain both, which would be silly.
Maybe I am misunderstanding the purpose of interfaces. I am using interfaces as a means to cast objects of different origins in AS3 to a common interface so I can execute a particular set of methods.
So, instead of making every display object in my entire project a movieclip (which accepts dynamic method calls much like Obj-C objects accept messages even if there is no associated method), I can pass around more generic DisplayObjects, cast them as IInterfaceName, and execute the method I want.
This approach might be entirely born out of the weird ass sibling relationship between MovieClip and Sprite in AS3, and as such is unique to Flash. I don't know. My alternative would be doing try/catches trying to cast my argument to any of the possible custom types I created that end up getting passed to the function.
And I have websense at work so I won't be able to continue this discussion till I get home tonight!
What is so good about it? It seems like I have to reinvent the wheel at every turn, and Java is like a language that forgot to have anything fun or cool. It's like someone took C++ and removed the insanity, but also half the features and all traces of personality. Granted, the project I am working on uses no libraries except an object-relational mapper written by my employer and I haven't been able to figure out any way to rig up a reasonable MVC system on my own, so that sucks.