NewsForumsCodeLogsGallerySpecsSearch

Create Multiple Classes

Monkey Forums/Monkey Programming/Create Multiple Classes

Monking(Posted 2013) [#1]
I faced some problem while creating multiple classes.
For example there are 2 files, Game.Monkey and Player.Monkey

Import Player

Class Game Extends App	
	
	Field player:Player
	
	Method OnCreate:Int()
	
		'Set the UpdateRate to 60 frames per second
		SetUpdateRate(60)
		
		player = new Player(0,0)
		
		Return True
		
	End Method
	
	...
	
End Class



Class Player
	Field x#, y#
	
	Method New(x#, y#)
		self.x = x
		Self.y = y
	End Method
	
End Class


I have the error of : Duplicated identifier 'Player' found in module 'Player'..
However, if I put these 2 classes into same file, there is no error..
So I was thinking..what's going on here..
Thank You


Shinkiro1(Posted 2013) [#2]
Use lower case file names.


MikeHart(Posted 2013) [#3]
Never name a file like the class it contains.


Gerry Quinn(Posted 2013) [#4]
But lower-case filename and capitalised class name is fine (probably standard, even).


dawlane(Posted 2013) [#5]
Best bet it to always start your class names with a letter like so CPlayer. 'C' meaning class. Then normal variables in lower case. You could use Hungarian notation to further distinguish your variables.


Gerry Quinn(Posted 2013) [#6]
I dislike the CName convention, for two reasons.

To my way of thinking, classes are easily distinguishable from functions and methods, so they can all happily use the same convention, which for me is PlayerName. Variables are also camelCase, but starting with a lower letter.

The second reason is that classes should be ubiquitous, and I don't like looking at code where everything starts with C.

Actually there's a third reason - I used to use MSVC and its automatic naming of class files when the classname started with C drove me mad! I'd create a class called ClassName, and MSVC would write the files lassname.h and lassname.cpp...

I don't mind a bit of Hungarian convention, though it's somewhat unfashionable these days. I use it for things like buttons and similar UI elements, and global variables get a 'the' or 'g' prefix. And in main application classes (not so much reusable helper classes) I use a '_' prefix for non-const methods and parameters.


skid(Posted 2013) [#7]
Wow, are posts #2 and #3 correct? Is this documented somewhere?

Arrgh, why is there no search page option in Ted for monkey docs, even an open page (language docs in this case) in real browser would be nice.

I always name my files after the class they contain and assumed monkey always lowered the case of the filename when using file scope rules.


Shagwana(Posted 2013) [#8]
This is something I am bumping into at the moment, looks like you can't use a folder for your includes called 'include' either?.

Import include.Data causes 'Error : Syntax error - expecting identifier.'

I guess that because 'include' is a reserved keyword.

And while we are on the subject..

Import "path\path\file.monkey" will compile but you can not access the classes in the file?


AdamRedwoods(Posted 2013) [#9]
Wow, are posts #2 and #3 correct? Is this documented somewhere?

Ted->help->language reference->modules


dawlane(Posted 2013) [#10]
You'll also find flash ( if I remember ) can't handle a hyphen (-) in then file name and the glfw has problems with apostrophes (')


Paul - Taiphoz(Posted 2013) [#11]
I use the cName convention as well, I find it much easier at a glance to spot a class as a result so for me its way better than switching between camal and pascal case which my brain simply would not pick up on.

My file names tend to be thing.monkey and my class inside will be cThing which avoids the conflicts.

I have thought about moving all my source files into a source dir and keeping only the main build file in the main dir root, but iv not tried that yet, not sure any benefit is worth the hassle.


Gerry Quinn(Posted 2013) [#12]
Monkey is case sensitive for file names. Always making them 100% lower-case is the best way to avoid any pain from this. [And, indeed, avoid special characters in case some targets don't like them.]

If you have a large enough project, subfolders can be useful, e.g. your classes related to dungeon generation could be in one folder and your classes related to creature interaction could be in another. It's not worth bothering with until you get to twenty or so .monkey files.