Lists of types?

Community Forums/Monkey Talk/Lists of types?

D4NM4N

(Posted 2011) [#1]

What is the format for a list<t> in monkey?

slenkar

(Posted 2011) [#2]

if you want to create a new list

class wizard
end class

local mylist:List<wizard>=new List<wizard>

monkey is ultra strict and case sensitive so it has to be List with a capital L

only one kind of class is allowed per list

Last edited 2011

Sledge

(Posted 2011) [#3]

only one kind of class is allowed per list

Although that would include any class that extends wizard.

D4NM4N

(Posted 2011) [#4]

argh it was that bloody local keyword again!

gets me every time. I dont understand why it is needed to be honest.

Sledge

(Posted 2011) [#5]

I dont understand why it is needed to be honest.

Simply for readability, I think. Let's say I decided to use a static iterator in a particular method, well six months on when I come back to the code and don't see the Local keyword in the For...EachIn loop I'll immediately realise what I did.

D4NM4N

(Posted 2011) [#6]

S'pose... but to be honest i have no idea why Mark chose:

Local a:int

over:

int a

I suppose it is to be maxlike but i always wondered that about max too to be honest.

in my world "more wordy != easier" :D

Sledge

(Posted 2011) [#7]

in my world "more wordy != easier"

Take that to its logical conclusion, though, and you end up with C! Hmmmm... BlitzC :D

Yasha

(Posted 2011) [#8]

C-like syntax has some problems with the grammar once you try to make it more complicated than C itself (C++ is famous for this). Don't know how much Mark is into the theoretical stuff but language designers don't usually like that sort of thing.

Also, am I imagining things or did I read somewhere that you could do this:

Local mylist := new List<wizard>

Once you've got types with multiple parameters nested three deep and suddenly realise you need to make a change, that could get useful.

degac

(Posted 2011) [#9]

only one kind of class is allowed per list

Well, that's not true.

Strict

Class Tmonkey
	Field name:String
End

Class Tdonkey
	Field name:String
End

Global list:List<Object>=New List<Object>

Function Main:Int()
	Local obj:Tmonkey
	Local obj2:Tdonkey
	
	For Local i:Int=1 To 10
		
			obj=New Tmonkey
			obj.name="Monkey-name-"+String(i)
			
			list.AddLast(obj)
	Next
	
	For Local i:Int=1 To 10
		
			obj2=New Tdonkey
			obj2.name="Donkey-name-"+String(i)
			
			list.AddLast(obj2)
	Next
			
	For Local unk:=Eachin list
			
			If Tmonkey(unk)	Print Tmonkey(unk).name
			If Tdonkey(unk)	Print Tdonkey(unk).name
			
	Next
		
	Return 0
End

You can always use a 'generic' Object class, but this is a question of design of your application/code.

therevills

(Posted 2011) [#10]

Also you can add child objects to a superclass's list:

Strict

import mojo

Global myGame:MyGame

Function Main:int()
	myGame = new MyGame
	return 0
End Function

Class MyGame extends App

	Method OnCreate:Int()
		SetUpdateRate 60
		
		Seed = Millisecs()
		
		For Local i% = 0 to 4
			New Alien(Rnd(0, DeviceWidth()), Rnd(0, DeviceHeight())
		Next
		
		For Local i% = 0 to 4
			New Player(Rnd(0, DeviceWidth()), Rnd(0, DeviceHeight())
		Next	
		
		return 0
	End Method
	
	Method OnLoading:Int()
		return 0
	End Method
	
	Method OnUpdate:Int()
		return 0
	End Method
	
	Method OnRender:Int()
		Cls
		Sprite.DrawAll()
		return 0
	End Method	
end class

Class Sprite
	Field x#, y#
	Global list:List<Sprite> = new List<Sprite>
	
	Function DrawAll:Void()
		For Local s:Sprite = Eachin list
			s.Draw()
		Next
	End Function
	
	Method Draw:Void() Abstract
End Class

Class Alien Extends Sprite
	Method New(x#, y#)
		self.x = x
		self.y = y
		Sprite.list.AddLast(self)
	End Method
	
	Method Draw:Void()
		SetColor 255, 0, 0
		DrawRect x, y, 10, 10
		SetColor 255, 255, 255
	End Method
End Class

Class Player Extends Sprite
	Method New(x#, y#)
		self.x = x
		self.y = y
		Sprite.list.AddLast(self)
	End Method
	
	Method Draw:Void()
		SetColor 0, 255, 0
		DrawOval x, y, 10, 10
		SetColor 255, 255, 255
	End Method
End Class

D4NM4N

(Posted 2011) [#11]

Thanks for the infos

although sledge/yasha i dont want -C-
...just standard declaration syntax. (BIG difference :D)

by the way, what is monkey's line separator, why does it crash when i stick a ; on the end (its an ingrained habbit for me from all the other langs i use. Max was good because it was treated as a separator so it could be there or not, the compiler did not care.

therevills

(Posted 2011) [#12]

Monkey's line separator is just <return>:

If Player.x > 100 And
Player.y < 100 Then
	Player.dead = true
EndIf

Yeah its a shame about the semi-colon - I would have liked if you needed to put it on every line.

Dabhand

(Posted 2011) [#13]

Monkey's line separator is just <return>:

About time, In C++ (notably) I liked spreading long parameter arguments down lines, as an example with a BlitzMax function:

ImagesCollide(	playerImage,
		player.x,
		player.y,
		player.frame,
		bulletImage,
		bullet.x,
		bullet.y,
		0)

I find that a lot betterer when wading across big lines of code.

I know the semi-colon is handy though, that should be kept in too for multiple statements on one line.

Dabz

Last edited 2011

Canardian

(Posted 2011) [#14]

Two dimensional adhoc formatting is even better to read than assembler-like one dimensional code:

ImagesCollide
(
	playerImage, player.x, player.y, player.frame,
	bulletImage, bullet.x, bullet.y,
	0
)

Last edited 2011

Dabhand

(Posted 2011) [#15]

Two dimensional adhoc formatting is even better to read than assembler-like one dimensional code

Nah, me no likely... Ultimately, its a horses for course thing!

Dabz

D4NM4N

(Posted 2011) [#16]

I prefer the vertical style too (unless they all fit reasonably on one line) it is easier to look at.
Not sure where "assembler-like" fits in though :D

Last edited 2011