No you don't need a constructor but if it's going to be a class field (instead of object field) you'd kinda need the constructor. Yes, you can have object fields because in Lua a class/object is really just a table and there is no "privacy" or rules regarding what you can and can't do with the table just becuase you are using it as an object.
No, not only. You can create new class field also in other class methods as also outside the class.
--our custom class
MyClass = Core.class(Sprite)--you can set up property in constructorfunction MyClass:init()
self.property1 =1end--or in any other methodfunction MyClass:otherMethod()
self.property2 =2end--or even when you already created a class instancelocal myclass = MyClass.new()
myclass.property3 =3
In your third example, you created a new instance and added a field to it. Will that field be available to other newly created instances of the same class as well?
noup, it will not. properties in constructors will be available to all instances. properties in otherMethods, will be available to instances which call these methods properties set to instance will be available only to current instance
With example 2 above - you need to remember that property2 will only "EXIST" once :otherMethod() has been called, if any other class function tries to access that method you'll most likely get a runtime error trying to access something that's "nil".
I would "strongly" advise that you initialise any and ALL class fields that you want in the :init() method and use the constructor the way it was intended
Another thing to note - is that there is no concept of "privacy" or access rights to methods / fields that exist in a table, a way round this is to place the class in a file on it's own and then use local functions which won't be visible outside of the file - however unless they take a "self" parameter, they (and any other data / tables or variables) should be considered "static" in the C++ sense of the word.
eg
-- ---------------------------------------------------- Basic template for a class-- --------------------------------------------------
MyClass = Core.class(Sprite)-- ---------------------------------------------------- Local (private data for this screen can go here...local value =42-- "static" value, visible only to all "instances" of this class function doSomething(self, param1)-- static function (takes ref to self so it can access "instance" fields)
self.myValue = param1
end-- -------------------------------------------------- Public interface to this screen class...-- Called when the scene is first created.function MyClass:init( data )
self.myValue = value
endfunction MyClass:PublicDoSomething( data )
doSomething(self,data)-- note how you pass "self" as the first param.-- it's done explicitly as the class methods are called with : instead of . end
WhiteTree Games - Home, home on the web, where the bits and bytes they do play! #MakeABetterGame! "Never give up, Never NEVER give up!" - Winston Churchill
Your welcome - remember my .sig If you have any more questions or need anything clarifying then get in touch!
WhiteTree Games - Home, home on the web, where the bits and bytes they do play! #MakeABetterGame! "Never give up, Never NEVER give up!" - Winston Churchill
Comments
http://www.lua.org/pil/16.html
Gideros' class docs:
https://docs.google.com/document/pub?id=149g_P1YlE4_6v_hHbFx3YAaYpdU0HoM70XJSLTE38ww#h.gmn9gbu2mq98
http://www.giderosmobile.com/documentation/reference_manual.html#EventDispatcher
Here is a sample of my code adding a class field.
My apps: http://www.yummyyellow.com
I took a look at the documents and your code and if I understand this right, class fields can only be declared within the constructor in Gideros?
properties in constructors will be available to all instances.
properties in otherMethods, will be available to instances which call these methods
properties set to instance will be available only to current instance
I would "strongly" advise that you initialise any and ALL class fields that you want in the :init() method and use the constructor the way it was intended
Another thing to note - is that there is no concept of "privacy" or access rights to methods / fields that exist in a table, a way round this is to place the class in a file on it's own and then use local functions which won't be visible outside of the file - however unless they take a "self" parameter, they (and any other data / tables or variables) should be considered "static" in the C++ sense of the word.
eg
#MakeABetterGame! "Never give up, Never NEVER give up!" - Winston Churchill
If you have any more questions or need anything clarifying then get in touch!
#MakeABetterGame! "Never give up, Never NEVER give up!" - Winston Churchill