@Red,
Basicly the type provides two types of fields. Those specific to each instance of the type, ie "Normal" fields, and those accociated with the type itself. (This is the same as the difference between Methods and Functions)
So anything you only want one of, you stick in a global. (Ie All my Aliens have one graphic, so the whole type just contains Global graphic:TImage for example. An alternative to this, is to have a field for each image, but point them all to the same one)
In this case, Ash wants one list of the type TGameObject. To not put it in the type/Class, whilst doable, is counter intuitive, because the list is intrinsic with the type.
On a simple nameing level, the global can be reffered to as "List", within any functions or methods of the type, because its full name is TGameObject.List. As it can in any other type that has a seperate list of instances, because each Type, is also a "namespace"
Now maybe this seems contrary to the whole purpose of encapsulating the properties of a TYPE or CLASS, but the List IS a property of the Type, so it also needs to be within the definition. Not to put it in the type, would infact decapsulate the type.
Are you moving over to Bmax, (and do you think decapsulate is a real word)?
Basicly the type provides two types of fields. Those specific to each instance of the type, ie "Normal" fields, and those accociated with the type itself. (This is the same as the difference between Methods and Functions)
So anything you only want one of, you stick in a global. (Ie All my Aliens have one graphic, so the whole type just contains Global graphic:TImage for example. An alternative to this, is to have a field for each image, but point them all to the same one)
In this case, Ash wants one list of the type TGameObject. To not put it in the type/Class, whilst doable, is counter intuitive, because the list is intrinsic with the type.
On a simple nameing level, the global can be reffered to as "List", within any functions or methods of the type, because its full name is TGameObject.List. As it can in any other type that has a seperate list of instances, because each Type, is also a "namespace"
Now maybe this seems contrary to the whole purpose of encapsulating the properties of a TYPE or CLASS, but the List IS a property of the Type, so it also needs to be within the definition. Not to put it in the type, would infact decapsulate the type.
Are you moving over to Bmax, (and do you think decapsulate is a real word)?