Re: Forward declaration of a table and (closure) function

[Steve Litt <slitt@...>]

On Thursday, July 14, 2011 01:45:48 PM Lorenzo Donati wrote:
> On 14/07/2011 18.42, Steve Litt wrote:

> > local Columns = {}       -- THE CLASS
> > function Columns.new(property_names_a)
> > 
> > 	self={}
> > 	--local vars to keep state
> > 	--functions to act as methods
> > 	function self.newCol(name, properties)
> > 	
> > 		--set up all the stuff about this column
> > 	
> > 	end
> > 	return self
> > 
> > end
> 
> The only problem with this approach is the garbage it generates:
> every new "instance" of the "Class" has its own newCol method,
> i.e. the methods are not shared. If this is not a problem for you,
> then all is fine (it depends on how many instances you actually
> create: if they are many and long-lived, they may eat up too much
> memory; if they are short-lived, they will impact performance
> because for every instance that is garbage collected, there are as
> many closures as there are methods to be collected too ).

When I get some time I'll write a test program that tests how much RAM 
it wastes. If it's significant, I'll study your method and test that, 
and if the savings is significant I'll use that.

> But this could be premature optimization, anyway. :-)

I don't think it's premature optimization unless my method has 
advantages yours doesn't. I do my method out of habit -- I could just 
as easily do your method out of habit if it turns out to be better

Thanks

SteveT

Steve Litt
Author: The Key to Everyday Excellence
http://www.troubleshooters.com/bookstore/key_excellence.htm
Twitter: http://www.twitter.com/stevelitt