The diamond problem
- is an ambiguity that arises when two classes B and C inherit from A, and class D inherits from both B and C. If there is a method in A that B and C have overridden, and D does not override it, then which version of the method does D inherit: that of B, or that of C?
For example, in the context of GUI software development, a class Button may inherit from both classes Rectangle (for appearance) and Clickable (for functionality/input handling), and classes Rectangle and Clickable both inherit from the Object class. Now if the equals method is called for a Button object and there is no such method in the Button class but there is an overridden equals method in Rectangle or Clickable (or both), which method should be eventually called?
How different languages deal with it:
• Common #Lisp: by order "...in the order in which parent classes are named in the subclass definition"
• Curl: "and the secondary constructor will be invoked for all other subclasses."
• Eiffel: "Eiffel will automatically join features together, if they have the same name and implementation."
• Go: compile-time error
• #Java: compile-time error
• #OCaml: by order "...are inherited in the same order, with each newly inherited method overriding any existing methods."
• #Perl: by order "...from as an ordered list. The compiler uses the first method it finds..."
• #Python: by order
• #Ruby: by order "...as rightmost depth first resolution."
• #Scala: by order "allows multiple instantiation of traits, which allows for multiple inheritance by adding a distinction between the class hierarchy and the trait hierarchy. A class can only inherit from a single class, but can mix-in as many traits as desired." This approach is the most similar to #Nile's; traits being qualifications.
• Tcl: by order "the order of specification in the class declaration affects the name resolution for members..."
Languages that allow only single inheritance, where a class can only derive from one base class, do not have the diamond problem.
Moreover, languages such as #Ada, Objective-C, #CSharp, #Delphi/Free #Pascal, Java, #Swift and PHP allow multiple-inheritance of interfaces (called protocols in Objective-C and Swift). Interfaces are like abstract base classes that specify method signatures without implementing any behavior.
When several interfaces declare the same method signature, as soon as that method is implemented (defined) anywhere in the inheritance chain, it overrides any implementation of that method in the chain above it (in its superclasses). Hence, at any given level in the inheritance chain, there can be at most one implementation of any method. Thus, single-inheritance method implementation does not exhibit the Diamond Problem even with multiple-inheritance of interfaces.
- is an ambiguity that arises when two classes B and C inherit from A, and class D inherits from both B and C. If there is a method in A that B and C have overridden, and D does not override it, then which version of the method does D inherit: that of B, or that of C?
For example, in the context of GUI software development, a class Button may inherit from both classes Rectangle (for appearance) and Clickable (for functionality/input handling), and classes Rectangle and Clickable both inherit from the Object class. Now if the equals method is called for a Button object and there is no such method in the Button class but there is an overridden equals method in Rectangle or Clickable (or both), which method should be eventually called?
How different languages deal with it:
• Common #Lisp: by order "...in the order in which parent classes are named in the subclass definition"
• Curl: "and the secondary constructor will be invoked for all other subclasses."
• Eiffel: "Eiffel will automatically join features together, if they have the same name and implementation."
• Go: compile-time error
• #Java: compile-time error
• #OCaml: by order "...are inherited in the same order, with each newly inherited method overriding any existing methods."
• #Perl: by order "...from as an ordered list. The compiler uses the first method it finds..."
• #Python: by order
• #Ruby: by order "...as rightmost depth first resolution."
• #Scala: by order "allows multiple instantiation of traits, which allows for multiple inheritance by adding a distinction between the class hierarchy and the trait hierarchy. A class can only inherit from a single class, but can mix-in as many traits as desired." This approach is the most similar to #Nile's; traits being qualifications.
• Tcl: by order "the order of specification in the class declaration affects the name resolution for members..."
Languages that allow only single inheritance, where a class can only derive from one base class, do not have the diamond problem.
Moreover, languages such as #Ada, Objective-C, #CSharp, #Delphi/Free #Pascal, Java, #Swift and PHP allow multiple-inheritance of interfaces (called protocols in Objective-C and Swift). Interfaces are like abstract base classes that specify method signatures without implementing any behavior.
When several interfaces declare the same method signature, as soon as that method is implemented (defined) anywhere in the inheritance chain, it overrides any implementation of that method in the chain above it (in its superclasses). Hence, at any given level in the inheritance chain, there can be at most one implementation of any method. Thus, single-inheritance method implementation does not exhibit the Diamond Problem even with multiple-inheritance of interfaces.
History of GameMaker: "Game Maker"
1999, summer: The development of Animo, developed in #Delphi by Mark Overmars, a professor at the University of Utrecht, started.
1999, 15 November: V1.1, a simple 2D animation designing tool with a limited visual scripting language, was publicly released. V1.4 made it possible to generate executables. Subsequent releases changed the name to "Game Maker" and moved towards more general-purpose 2D game development.
2000, September: V2.0 was released, which first used #DirectX for sounds, but not graphics.
2001: V3.0 was released and now also used DirectX for graphics. It saved games as
2001, July: V4.0, rewritten from scratch, was released. The GUI was completely revised and took the form that was more or less preserved in later versions. The file extension was changed to
2003, April: V5.0 was released and had a completely new interpreter, making games considerably faster. Although it had been freeware up to v5.0, later versions introduced an optional registration fee.
2004, January: V5.3 introduced many features for registered users, including: particle systems, networking, and DLLs.
2004, October: V6.0 was released. The runtime's drawing pipeline migrated from VCL to Direct3D. This led to sprites, better fonts, primitives, and 3D graphics, but it also broke compatibility. The file extension was changed to .gm6. V6.1 added surfaces.
2007: Growing public interest led Overmars to seek help in expanding the program, which led to partnership with YoYo Games, and Overmars retained a position as one of company's directors.
2007, January: V7.0 was released under the partnership with YoYo Games. It introduced the use of extensions. The file extension was changed to
To create a "YouTube for games", the now archived YoYo Games Sandbox website was created a for uploading and playing Game Maker games, and became quite a success.
2009, December: V8.0 was released. Sprites and the built-in sprite editor were greatly improved, making it much easier to use alpha transparency.
2011, April: V8.1 changed the name to GameMaker (lacking a space) to avoid confusion with the 1991 software Game-Maker. The runtime was rewritten in #CPP to address performance concerns with previous versions. The file extension was changed to
Because of competing projects such as G-Java, G-Creator, LateralGM, etc., the editable game files were encrypted since v.7.0. However, it was not long before the encryptions were broken.
— Summary from game-maker.nl
1999, summer: The development of Animo, developed in #Delphi by Mark Overmars, a professor at the University of Utrecht, started.
1999, 15 November: V1.1, a simple 2D animation designing tool with a limited visual scripting language, was publicly released. V1.4 made it possible to generate executables. Subsequent releases changed the name to "Game Maker" and moved towards more general-purpose 2D game development.
2000, September: V2.0 was released, which first used #DirectX for sounds, but not graphics.
2001: V3.0 was released and now also used DirectX for graphics. It saved games as
.gmf files.2001, July: V4.0, rewritten from scratch, was released. The GUI was completely revised and took the form that was more or less preserved in later versions. The file extension was changed to
.gmd.2003, April: V5.0 was released and had a completely new interpreter, making games considerably faster. Although it had been freeware up to v5.0, later versions introduced an optional registration fee.
2004, January: V5.3 introduced many features for registered users, including: particle systems, networking, and DLLs.
2004, October: V6.0 was released. The runtime's drawing pipeline migrated from VCL to Direct3D. This led to sprites, better fonts, primitives, and 3D graphics, but it also broke compatibility. The file extension was changed to .gm6. V6.1 added surfaces.
2007: Growing public interest led Overmars to seek help in expanding the program, which led to partnership with YoYo Games, and Overmars retained a position as one of company's directors.
2007, January: V7.0 was released under the partnership with YoYo Games. It introduced the use of extensions. The file extension was changed to
.gmk.To create a "YouTube for games", the now archived YoYo Games Sandbox website was created a for uploading and playing Game Maker games, and became quite a success.
2009, December: V8.0 was released. Sprites and the built-in sprite editor were greatly improved, making it much easier to use alpha transparency.
2011, April: V8.1 changed the name to GameMaker (lacking a space) to avoid confusion with the 1991 software Game-Maker. The runtime was rewritten in #CPP to address performance concerns with previous versions. The file extension was changed to
.gm81.Because of competing projects such as G-Java, G-Creator, LateralGM, etc., the editable game files were encrypted since v.7.0. However, it was not long before the encryptions were broken.
— Summary from game-maker.nl