On 7/11/07, Leslie Newell <[EMAIL PROTECTED]> wrote: > Hi John, > > > It was changed because every other function that returns multiple > > values all returned the return value of the function as the first > > parameter. I have been trying to reduce the number of "gotcha's" in > > wxLua to make it less annoying for some, but more annoying for others. > > :) > > I assume you are trying to model the wxLua functions on this version of > Read(): > bool Read(const wxString& key, wxString* str, const wxString& defaultVal) > Would it not make more sense to base it on this version: > wxString Read(const wxString& key, const wxString& defaultVal) > The wxPerl and wxPython implementations are all based on this second > version. > > Currently the wxLua implementation looks like the second version but
I agree and struggled with this when I made the changes. It's a tradeoff between being able to get more information or making things simpler. I decided that whenever two or more functions exist that conflict (both take same input params since we can't pass the value string by reference) I'd always choose the one that gives more information for greater flexibility. > acts like the first. This is pretty confusing for a wxLua newbie. Just > working with the Lua documentation I would never have figured out what > was going on. I only found out by looking at override.hpp. As wxLua > does not have detailed function-by-function documentation is it not best > to try to keep the functions looking as much like their C++ counterparts > as possible? By the way, that wasn't a dig at wxLua's documentation! Heh, if only the users read a little more they'd know that we DO have function-by-function documentation and every single %override is documented! Admittedly, it's in an overly large file, but better than nothing. :) http://wxlua.sourceforge.net/documentation.php http://wxlua.sourceforge.net/docs/wxluaref.html#wxConfigBase > To be honest, how often do you need to know if you are using the default > or not? I know I have never needed to. In the very rare event that you > do actually need to check if the value was in the config you can always > have a default that should never appear in the config. This is true too, maybe I'll change it... > > if 0 then print("Since when is 0 == true?") end > > Yup, been caught by that one a few times :-) On second thought, I will allow 0 to be false. Currently I'm just using the lua C function lua_toboolean() which does the above. > > myCheckBox:SetValue(select(cfg:Read("Foo",1), 2) ~= 0) > > Yes, I thought of that a few seconds after sending the mail. Do you know > a good way of going the other way? > this obviously won't work: > cfg:Write("Foo",myCheckBox:GetValue()) > > At the moment I have a small function that takes a bool and returns an > int but there must be a better way. Oh, I didn't realize that this is the case! print(tonumber(true), tonumber(false)) nil, nil Again, I will change that to map true, false to 1, 0. I am however wary of allowing nil since it is too easy to have a typo for a variable. Thanks, John Labenski ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ wxlua-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wxlua-users
