On Mon, 21 Nov 2011 03:04:14 +1000 David Seikel <[email protected]> wrote:
> On Mon, 21 Nov 2011 00:17:26 +1000 David Seikel <[email protected]> > wrote: > > > On Sun, 20 Nov 2011 01:21:48 +1000 David Seikel <[email protected]> > > wrote: > > > > > I'm not sure what you where thinking, perhaps that the user > > > could pass in a table to be filled in? Seems odd. > > > > > > There's a few of these, I'll just leave a FIXME comment for now, > > > but I'll probably remove the check before the release. > > > > On a related note, I'm not so sure about this business of reusing > > tables that are passed in as parameters for the results to be > > returned. I don't think that sort of thing is used anywhere else in > > lua, AND we are returning the result table anyway. > > > > It's quite nice that things like colour and coords can be passed > > back and forth as a table. Even better is that excess stuff in > > these tables is ignored if passed in as arguments. Better still > > that they can be passed in as separate values. > > > > map:lighting() accepts one set of 3D coords, and two sets of > > colours. > > > > map:rotate3d() accepts two sets of 3D coords. > > > > map:zoom() accepts two sets of 2D coords. > > > > The problem with these, if using the generic argument scanner I > > wrote, based on the several specialized argument scanners you > > wrote, is that it tries to reuse the table passed in to return > > results, but A) which table? B) it does a reset of the stack, that > > causes problems for the next scanner call that tries to get the > > next set of arguments. > > > > Well, OK, those three don't return any values, so A is moot. And B > > is moot for those three anyway, since the stack reset is bypassed. > > I still think it might be a problem for future API additions. > > > > I still think it would be much cleaner to NOT reuse passed in > > tables, and to not pass values back in optional passed in tables. > > This solves both problems mentioned in this thread, and makes > > things cleaner all around. > > > > So that would mean that we remove the bool that tells the argument > > scanner to reuse or create a table, and have the generic "return > > results in a table" function create it's own table. And remove that > > lua_istable check mentioned in the last email. > > > > I'll double check if the example is using that sort of thing, then > > make these changes and commit. You can revert if you disagree. > > > > Just as an example to make my point - > > colour_red = {255, 0, 0, 255} > colour_green = {0, 255, 0, 255} > > -- some time later > > if (some_bool) then > some_evas_object:color(colour_red) > else > some_evas_object:color(colour_green) > > And the scripter wonders why odd things happen to his colours. OK, so the example is silly and does not actually prove anything. lol My argument still stands though, C functions meddling with passed in tables is not the way lua does things. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d
_______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
