@ruilov Oh I agree, and think Codea should put everything in a namespace. I just have never had much hope that they will be. Simeon and Dylan are the ones who get to make that call, and I doubt I can change their minds.
As to your question it is very easy:
for k,v in pairs(_G) do if type(v) == "function" then print(k .. " is a function") end end
If you wanted to see if any of them were changed you would make a table of all the functions and their names, and then compare the references at a later point (ie the v values).
I have a bit of JavaScript code I wrote to make a snapshot of every global variable name I am using, and then run it periodically to make sure I am not accidentally creating new ones (ie I forgot to type var somewhere). The exact same thing could be done in Lua.
Prototype languages are exceptionally powerful, because you can introspect the runtime environment at runtime. With a bit of code attached to the metatable it would be possible to prevent people from replacing any existing function (or just specific ones).
@toadkick there are a couple of ways Codea could accomodate backwards compatibility if they decided to use a prefix or a namespace:
They could wrap all legacy calls automatically, and then any new APIs would be only in the namespace or prefix. This would be fairly easy for Codea to implement and break the least amount of code
They could add a new API (call it codea.enableLegacy()) that would reflect the Codea namespace and then make wrappers in the global namespace, at runtime.
They could have a legacy.lua (or simple.lua) file that contained global namespace wrappers for all the legacy APIs
Option #3 would probably be the best compromise, especially once shared files have been implemented.
Yeah, something like #2 is what I had in mind. Actually I’m not sure I understand how #3 would work…would I just add the legacy.lua file to my project if I wanted legacy support? If so, how would I obtain that file? In that case, it doesn’t seem much different than #2…in fact legacy.lua could just be built into Codea, and all codea.enableLegacy() would do would just be to run that file. I would prefer #2 because it would generally be less maintenance for me. Although frankly a) I would never use it and b) I doubt TLL will change their minds about this anyway, so I guess it’s a moot point.
Cool, so depending on how the lib importing feature is implemented you might be able write your own defensive lib importing function, that makes sure that anything that the new lib creates in the global namespace gets assigned to another namespace of your own making. Something similar to “import as” or whatever the idiomatic construct is in other languages. Simeon this may be a good compromise which wouldnt affect anyone that doesnt care but not sure if it fits with what you have in mind for lib importing.
I’m actually fine with built-in codea apis being global. If a function is important enough to be built into the environment, then i’m ok giving it the special power of owning a global name. And i trust TLL to be thoughtful about the design of those apis a lot more than i’d trust a user library.
To complete this though this handy function would “unravel” a namespace (ie a table) and make global namespace versions of all the functions:
function makeGlobal(t) for k,v in pairs(t) do if type(v) == "function" then _G[k] = v; end end end
If you called makeGlobal(table) then you could then call insert(myTable, aValue) instead of table.insert(myTable, aValue)
With a bit of metatable mojo you could make global variables that worked this way as well.
I want to make it very very (very!) clear that I don’t encourage doing this (I’m looking at you @simeon ;), but just wanted to underscore just how easy it would be.
I also want to make it clear that I’m not trying to coerce @simeon into making these changes either. If nothing else I think this is a healthy discussion and a good thought exercise
@toadkick In the case of #3 the legacy.lua file would be included with Codea, and be added to your project via the code sharing feature @simeon has said he is planning. The point of it would be that you wouldn’t have to make a code change (just a project one) and it might be more obvious what is going on to novice users.
@ruilov That is great so long as nobody every puts anything in the global namespace. Consider my oval()example. I use a library that defines oval()and then in a later version of Codea implements oval(). I then add another library that expects to be using Codeas oval(). If the signatures (IE the parameters they take) do not match identically, and the functions do not behave identically then you have a hard to diagnose bug on your hands.
To my mind every bit of external code should be in a namespace. It is only the user’s code that (at their discretion) add to the global namespace.
@JockM regardless of the fact that Cargo-Bot was produced with Codea, my focus is still on creating a fast, visual prototyping language. Think of Codea as its own language with its own primitives. You wouldn’t store for loops, keywords and table in a “lua” namespace — that just wouldn’t make sense. Neither would you store the core graphics functions in a namespace.
I like that you are passionate about your argument. I want to assure you that we certainly don’t plan to throw everything into the global namespace — we spend a lot of time thinking about the names, placement, and design of Codea’s features.
One of the reasons I stopped using löve and started using Processing was precisely because I liked the “immediateness” of Processing’s API. There was no digging. I feel that setting the right emotional tone is important to being creative, and an API can hinder that if it is too formal, or buried in namespaces.
Emotion plays a big part in coding for me (just like in sketching or painting), so having a design that feels right is very important.
@simeon OK lets put aside any passion and arguments about best practices aside. I think you are wrong, but that is not the point.
It is no use crying over spilt milk, but based on your intent, you probably would have been better off using processing, or making your own language. Because Lua seems simple and direct but it is one of the more powerful languages out there, and contains a seemingly never-ending number of ways for users to get themselves into lots and lots of trouble.
I have outlined a very real scenario about global namespace collision:
Library A is written to Codea 1.?, implements function oval() and is included in all of the users projects
Codea 1.? introduces function oval() with a different signature from Library A
Library B is written to expect Codea 1.?'s oval() and is included in a new project with Library A
The result of this is code that is going to fail when Library B calls oval(). The failure might be the code crashing, or it could be that the ovals don’t look quite right, or look spectacularly wrong.
This will be hard and non-obvious to the use to diagnose and deal with.
So please, implement some kind of check to see if the code in a project redefines and of Codea’s APIs, and gives a warning. It has nothing to do with the rightness or wrongness of my or your arguments, it is simple and easy to do, and it is to the benefit of yourself and to your users.
If you want, I will write the Lua code for you and tell you the two points it should be run. Namespaces vs Globals can be seen as a matter of opinion. But this isn’t, if you are (in your own words) “polluting the global namespace” and (in effect) encouraging your users to do the same; then it is wrong not to at least catch this very real issue.
@JockM regardless of the fact that Cargo-Bot was produced with Codea,
my focus is still on creating a fast, visual prototyping language.
Then you have a bit of an impedance mismatch between how you are marketing Codea, and how you are describing it in the forums.
In iTunes you say “Codea lets you create games and simulations — or just about any visual idea you have. Turn your thoughts into interactive creations that make use of iPad features like Multi-Touch and the accelerometer.” And you (rightfully) brag about CargoBot and Open Sourcing the back end, and talking about your use of Lua.
That is a very different message than (paraphrasing) “Codea is a way to make prototypes everything else is secondary”, which is seemingly what you are saying here.
Neither is wrong, both are legitimate, but you need to get your message clear. If the primary purpose is prototypes then say that on iTunes and all your other messaging. I don’t care which, but right now you are giving off mixed messages.
Now that the backend is open sourced, and people can use Codea to publish apps on the app store, they will use Codea for that purpose. And once there is a method in place to share libraries, it is inevitable that the situation @JockM describes will occur.
Though it was intended for Codea to be a prototyping tool initially, more and more users are not perceiving that to be the case, and the mixed messaging certainly doesn’t help. I think at some point, if Codea becomes a runaway success, more and more people will be clamoring for things like a cleaner API because they are getting bitten by issues related to this. Or, they’ll simply stop using Codea.
On a different note, I must pick a nit now:
“Neither would you store the core graphics functions in a namespace” - actually, I would.
Graphics are not a part of the Lua language. Syntax and constructs such as for loops, tables, and keyword don’t belong in a namespace because they are the language. Everything else is libraries, even a lot of the functionality that comes with Lua (@JockM already mentioned several of the provided libraries in a post above). Arguably, most general-purpose languages do make a distinction between the language itself and the functionality afforded by the language. Take C++ for example, which provides stdio, and collection templates like vector or list, which are all kept in the “std” namespace. Or the iOS/Mac SDKs with Objective-C, that prefix every class and function with NS*. They are functionality commonly provided with the language, but they are arguably not language constructs.
@JockM
Your argument seems to stem from the use of libraries. Codea wasn’t intended to be used with libraries, though we are thinking about adding them in the form of imported projects.
Still, as I think was mentioned, the global namespace is reserved for Codea’s built in functions. If a “library” adds functions to the global namespace, that is a bug and the results are undefined.
Simeon did mention to me that you could write a function that essentially does
codea = copy(_G)
where copy is a function that does a shallow copy of all the functions from _G into a new table. If codea polluting the global namespace really irks you, you can always do this in your main file and just use the namespace yourself.
Neither would you store the core graphics functions in a namespace
To echo what @toadkicker, I would. And both Java and .Net put everything in a namespace. Now they happen to have a cleaner way of handling namespaces than Lua does, but the point remains.
@toadkick We have stated before that we consider Codea to be a dialect of Lua more than an extension of it. We are willing to modify the language parser/interpreter in the future if we have a good enough reason. This is the same reason why we consider the global namespace to be fine for Codea to pollute.
I guess to be fair we should either disallow, or produce a warning when a function of the same name as a Codea function is defined (similarly to how “local” is a reserved word in the language and you cant use it as a function name).
@Dylan I think polluting the global namespace is a bad idea, but I will call back to two points I keep making: I put all my own code in namespaces and I don’t expect the Codea API to change vis a vis namespaces. I just think you guys are making a mistake using the global namespace for your API. I am not advocating for it to change, nor do I need it to change.
However I am pointing out a very real risk that is going to happen sooner or later. I also provided a easy thing to implement to help people detect if they do trigger it. If you ignore this and do nothing, then I have no problem calling that decision foolish.
The other point is that it matters very little what your intentions are for your product. Once you release it into the wild, it is going to be used in lots of ways you never intend. Most of my friends who are engineers and iPad users own a copy of Codea. And none of us are using it in the highly disposable slap-dash way @Simeon describes. And we are sharing libraries with each other.
So you may not have intended people to use libraries, but they are.
And I want to reiterate that I hold the two of you in high esteem and love Codea.
@JockM I strongly believe that Codea would be far less attractive to use if we were to encapsulate its core graphics abilities within a namespace. It’s the same reason I stopped using löve. (Löve is an excellent library, but it inhibited my creativity more than Processing.)
Your example of Java and .NET is not realistic. Those are general purpose, all-encompassing libraries and use namespaces appropriate to their scope. In Codea, functions like sprite, ellipse, sound and so on, are primitives of the language. They are so fundamental that Codea does not really make sense without them.
Codea is modelled on the Processing API, which uses the global namespace for these things (to good effect, I think. It quickly became my favourite programming tool because of this.)
For my part, modifying the parser/interpreter would be an instant dealbreaker for me. Part of my attraction to Codea is that it provides a great playground for experimenting with Lua. If the work I did on Codea could not be transferred elsewhere, it becomes a lot less attractive. I find it interesting that you would consider doing that, but are adamant against doing something that the language provides out of the box, that would add value to many programmers who are using Codea.
Anyway, at the risk of making a liar out of myself and seeming like I am trying to coerce you guys into doing something you don’t want to do or taking Codea in a direction you don’t want it to go in, I’ll cease my arguments here. I think the finer points have been expressed sufficiently, and there’s not really much else to say.
So, I just want to conclude by saying that I love Codea and think it is a wonderful tool, and I’m really glad you guys have worked so hard to get it out there.
Ok. I agree that silently failing when someone overwrites a codea function is bad, and that eventually someone will shoot themselves in the foot with it. However I think putting codea in a namespace ultimately makes the tool less useful. I agree with you that in general its a good idea for code to be in namespaces.
Processing pollutes the “global” namespace freely (technically the functions are in a package, but it imports them into the file namespace automatically). Javascript has plenty of global APIs. I think its just inevitable that as you move toward domain specific languages, they will generally become “messier” in order to make what they intended to do easier at the expense of strong engineering principals.
