[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Function at line ### has more than 60 upvalues
- From: "Mark Meijer" <meijer78@...>
- Date: Fri, 22 Aug 2008 02:48:22 +0200
I failed to realize that the factory function is meant to create an
"instance" of an "object". Doh... I just came home from work when I
wrote my first reply, guess I was still a bit fuzzy, sorry about that.
Anyway that was why I didn't understand the need for the shallow copy
(I do now @Eric :P ). Which is why my version omits the cloning, it
simply returns the exact same table on each call (obviously).
So, note to OP, don't forget about the clone code demonstrated by the others.
Also, creating the functions as locals is indeed not necessary. Forget
what I said about those functions calling eachother being more
efficient if they're locals. It's true, but most likely they will call
eachother via a reference to self anyway, e.g. self:methodN(). In
short, go for the more readable variants ;-) ...(provided you have
time for the extra changes to your existing code... or smart use of
search/replace). And if you're going to refactor your stuff, consider
what Matthew said about using the metatable approach, it might be a
better solution (depending on your needs).
2008/8/22 Eric Tetz <erictetz@gmail.com>:
> On Thu, Aug 21, 2008 at 2:02 PM, Mark Meijer <meijer78@gmail.com> wrote:
>> Eric's solution is a bit different because it doesn't use local
>> functions (don't know why).
>
> There's no need for the locals. You can just store the functions in
> your table directly. In other words, rather than doing this:
>
> local a = function(self) end
> local b = function(self) end
> local z = function(self) end
> local prototype = {
> a = a,
> b = b,
> z = z,
> }
>
> You can just do this thi:
>
> local prototype = {
> a = function(self) end,
> b = function(self) end,
> z = function(self) end,
> }
>
> Or, if you don't want to declare your functions in the table
> constructor (matter of taste), you can achieve the same result:
>
> local prototype = {}
> prototype.a = function(self) end,
> prototype.b = function(self) end,
> prototype.z = function(self) end,
>
> Which is exactly equivalent to (via syntax sugar):
>
> local prototype = {}
> function prototype:a() end,
> function prototype:b() end,
> function prototype:z() end,
>
> I just find the latter most readable.
>
>> this is equivalent to Eric Tetz's solution, I believe. Except
>> without the shallow copying (why was that in there?)
>
> If you have your methods in a table, you can copy them to the new
> object in a loop. I could have written the factory like this:
>
> factory = function()
> local new = {}
> for k,v in pairs(prototype) new[k] = v end
> return new
> end
>
> But the body of 'factory' is a commonly used routine (shallow copy of
> a table) that most Lua programmers already have it their library. I
> just happen to call mine 'clone'. I just assumed you would use such a
> function rather than repeating that same loop in every factory:
>
> factory = function()
> return clone(prototype)
> end
>
> By the way, my first post has a screwed up version of 'clone' (I was
> just typing off the top of my head). I forgot to actually return the
> table. :)
>
> Anyway, Mark Meijer's method is the way more people do it. I just
> wanted to show Alexander that creating a bunch of locals before
> assigning them to table fields is unnecessary; you can just assign
> them to table fields to begin with.
>
> Cheers,
> Eric
>