Lists, oh dear.

Monkey Forums/Monkey Programming/Lists, oh dear.

chimaera(Posted 2014) [#1]
I always tend to use lists as the main containers for objects that I have in my games since the good ol' BlitzMax days...But I seem to run into more problems with Lists in Monkey. So here comes a bunch of quesions that I hope that someone can shed some light on:

1) If I would like to populate a List with a class I declare the list like this:
myList:List<myBaseClass> = New List<myBaseClass>


I was wondering why I have to supply a container type to the list at all? Why do I have to tell it that it contains anything else than "a class"?

Also if I extend myBaseClass and choose to iterate through the List but only for objects that are of the extending like this...

For local myObject:myExtendedClass = EachIn myList
      myObject.doSomething()
Next


...I get an error stating that the compiler can't convert an object from the type myBaseClass to myExtendedClass, which I things sounds very illogical from a inheritance standpoint. Why do I get this error at all?

If I remember it correctly I could create a Tlist in BMax and put whatever object I wanted in there. When I then stepped through the list I could choose exactly what type/class I was looking for.

Am I not understanding the Lists in Monkey? I see more and more limitations in them, but I do not have another elegant options.

From my perspective I should be able to store all kinds of (for example) gui-types in a list called myGuiList, ranging from buttons to images to whatever, and I should also be able to look for whatever type/class from within that list without any issues. In a sense that is something that supports polymorphism which is a fundamental part of OOP. This is exactly what you could get through using vectors in c++.

But, I realize that I might not understand things correctly and I always seems to get great response from the people in these forums.

Oh! BTW: I hope that you are all enjoying Easter.


Gerry Quinn(Posted 2014) [#2]
All Monkey classes inherit from Object, so you can use that if you don't want to define a base class (I presume,it may not work on primitives such as String or Int).

To convert an object to an extended class, cast it.

Local obList:List< Object > = New List< Object >
obList.AddLast( New Point( 1, 1 ) )
Local pt:Point = Point( obList.First() )
Print pt.x + " " + pt.y



Arjailer(Posted 2014) [#3]
1 - you declare the type the list will contain so that you don't have to cast the instances when you retrieve them (as Gerry is doing in his example). If you're happy to cast them then see Gerry's suggestion.

2 - you get the "can't convert" error because the compiler cannot guarantee that everything in the collection (ie. that everything derived form myBaseClass) can be converted to myExtendedClass. You could have other classes derived from myBaseClass that are not compatible with myExtendedClass.

The behaviour you're seeing is exactly what you get with Java or C# generics - don't know C++ well enough to comment.