Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion

Global namespace - maybe this might help?

BortelsBortels Mod
edited May 2012 in Suggestions Posts: 1,557

So - I'm not one to pick at things, but my brain has been spinning on this, and will continue to do so until I spit it out; there was a big discussion (and the thread seems to have mercifully been submerged) about to what extent Codea the app can or should "pollute" the global namespace with useful commands.

One side says - correctly - it's a bad thing to clutter up the global namespace with new de-facto keywords; it makes the language evolve away from compatability with the base language, and it can cause namespace conflicts with libraries. We've seen that to some extent, in that lovecodify rots quickly as we introduce new base features to Codea.

The other side says - correctly - that Codea as an application was targeted at self-hosting, and that de-globalizing commonly-used functions (like "sprite") would make the language more verbose (bad on the ipad keyboard), and perhaps harder for beginners to pick up (which is important for growing the community), and would break compatability with existing code (which is important for me!).

Both sides are correct, and the correct place to draw the line there is fuzzy at best. But - maybe I have an idea where we could have our cake and eat it too?

The new Codea "keywords" (like "sprite") aren't actually keywords - they're global functions, that's all. It occurs to me it would be tedious but straightforward to have a module that has the following code:


codea.sprite = sprite sprite = nil -- and so on

Effectively renaming all of the keywords. I've done this before to replace print() with something that doesn't go nuts if you do a lot of it (if you print many times inside a tight loop - you'll basically hang codea - it's not sophisticated enough to throw away anything that would have scrolled into the bitbucket anyway).

The problem is - I suspect that if this was done without care, it would break the codea libraries - but I'll bet it could be done with semi-minor modifications to them (ie. making the libraries be global-friendly, then exposing the function calls globally if desired).

Presumably the end of this process would be a pragma - probably on by default - to import the common codea functions into the global namespace. But those who had an issue - library authors, or people who run into conflicts - could turn it off and not have to worry. We could presumably have our cake and eat it too.

I don't want to open up a more-than-thoroughly debated issue (so I'm not asking for comment so much as pointing out a possible workaround for future consideration) - I just wanted to suggest that perhaps we can make everyone happy at the same time. It seems to me that the two points of view that exist are NOT mutually exclusive...

Comments

  • Posts: 141

    Back in the mammoth tedious thread I discussed a solution like this. As you say it is very easy to implement.

Sign In or Register to comment.