Multiple object types on a list?


Active member
3rd Party Module Dev
Tutorial Author
Jul 3, 2017
That is basically my question. Let me explain what I want to do...

I want to create a "virtual bag" where I can drop all sorts of things: weapons, potions, armor, scrolls... whatever. Then I just do a "grab" and take a random item from it.

Is there a way a "List" can hold multiple classes instead of a single one?
So far, this is what I have, but I don't think it will work.

Class Bag<T>
    Field list:List<T>
    Method New()
        list = New List<T>
    End Method
    Method add(value:T)
    End Method
    Method remove(value:T)
    End Method
    Method clear()
    End Method
    Method get:T()
        Local c:Int = list.Count()-1
        If c<=0 Then Return Null
        Local item:T
        Local r:Int = Rand(0, c)
        Local i:Int = 0
        For item = Eachin list
            If i = r Then Return item
        Return Null ' error?
    End Method
End Class

But I don't think this will work. I know, I can always make all classes 'extend' from a single one and use *that* in the list. But I want an "all purpose" solution, that I could drop on any project and use it, without this 'caveat'.

Is there a way to do this in Cerberus? Maybe if I replace T with "Object", would it work?
Last edited:
Yup, using "Object" works :)
(I can't add primitives like Int, String, etc - but that's fine!)
With type casting, it works:


Class temp
    Field type:Int = 0

Class one Extends temp

    Field name:String

    Method New()

    Method Output:Void()
        Print "name="+name
    Method out1:Void()
        Print "This is class one"

Class two Extends temp
    Field value:Int=-1
    Method New()
    Method Output:Void()
        Print "value="+value
    Method xxx:Void()
        Print "This is a dummy call"
    Method out2:Void()
        Print "This is class two"

Function Main:Int()
    Local myList:List<Object> = New List<Object>
    Local myOne:one = New one"Michael"
    Local myTwo:two = New two
    For Local li:= Eachin myList
        Select temp(li).type
            Case 1
            Case 2
    Return 0
Yup, using "Object" works :)
(I can't add primitives like Int, String, etc - but that's fine!)
How about using BoxString, BoxInt, etc.
Yeah, that should work for ints, strings and all - But what I needed was just a way to store different classes :)
(Think if you kill a monster, I just take something out of the 'bag' to give to the player)
Hmm, this sounds like the collections you have in Python. Could you explain what you want to use it for.
At the moment I don't see the use of different classes as they are all behaving as items you collect in your bag and not with the behaviour of their class type, right? If there was a collection of different types (classes), the moment you want to use its methods you would have to check what class it is to cast it properly. At this stage you could also just create an instance of that class or get one from a pool to have that type at hand.
Don't take this as a critique, I just want to understand the concept of your implementation.
The only way your going to store different classes is to derive your items from a base class, wrap one of the map containers using the base class into your own custom class to deal with adding and removing items. Then when you need to retrieve that data, you have to locate and retrieve the item back as a base class object where you then test for the correct type identifier to cast back. Personally I'd just use the classes in the Json module. You can create a Json object and add any Json value to it and communicate between Json object using Json strings. Any other no Json class then just needs to convert it's items into a Json object.
Last edited:
Instead of deriving all classes from a base class, you could have them implement an interface. If it has no methods then I guess you just have to say Class MagicWand Implements IBaggable, and then MagicWand instances can be added to List<IBaggable>. The advantages of that over just using Object are probably only theoretical, though.

I'd have thought an Item base class would be a natural option in most cases where you are doing this kind of thing, though.
Top Bottom