Issue with cyclic Import statements

BlitzMax Forums/BlitzMax Programming/Issue with cyclic Import statements

The forum is locked. These are the original blitzbasic.com forums, kept so they can still be read. No new topics, replies or edits can be made here. To join in, head over to the Blitz3D+ forums.

Dreamora,

An interface is a formal way of declaring that a class provides a certain set of properties and methods. Instances of the class can then be passed to a method or function that expect something that supports the interface.

This is in addition to the class being able to inherit from a different class. One way to think of it is that it solves the problem of not having multiple inheritance by instead allowing a class to give a contract that it can do certain things. The concept of an interface is not supported in all OO languages but it is extremely useful.

In BM the syntax could be something like:
Interface I_Mappable
	...
End Interface

Type T_Place Implements I_Mappable
	...
End Type


Your example does show a constructor like approach with inheritance. Try adding parameters to the constructor and allowing for say TEST_IMP to have parameters that TEST does not.

Separate issue about constructors:

Here is an example of what I'd like to do:
Strict

Public

Type T_Place

	Field Name:String

	Function Create:T_Place (name:String)
		Local obj:T_Place = New T_Place
		
		obj.Name = name
		
		Return obj
	End Function

End Type

Private

Type T_City Extends T_Place

	Field Population:Int
	
	Function Create:T_City (name:String, population:Int)
		Local obj:T_City = New T_City
		
		obj.Name = name
		obj.population = population
		
		Return obj
	End Function
	
End Type

But you cannot have a method with the same same but different parameters and return type. So you end up changing the T_City constructor to be called say CreateCity. This gets ugly and unwieldy with a deep object hierarchy.

Also the derived type is having to initialise fields that belong to the base type. This again is more work and an opportunity for mistakes to happen.

Better would be something like:

Strict

Public

Type T_Place

	Field Name:String

	Function T_Place (name:String)
		
		this.Name = name
		
	End Function

End Type

Private

Type T_City Extends T_Place

	Field Population:Int
	
	Function T_City (name:String, population:Int) : base (name)
		
		this.population = population
		
	End Function
	
End Type

Here the constructors are just methods with the same name as the type. The object is implicity created and returned. Note also that the T_City constructor invokes its parent type constructor ': base(name)' passing the parameter that it requires. The derived type then does not need to set that field itself.

You could still have a different function that creates and returns a type if you want. Constructors are a special case.