I tried kdevelop and committed the project files for it, but I haven't been particularly happy with it, so I'm just using emacs with flymake.
As for legitimacy, you make a good point, though I might just decide to name it something other than "MOO" if it gets that drastically incompatible. Anyway, it's hardly all that relevant to development -- I just happen to be making a MUD codebase that starts from MOO as a base.
And I certainly don't want to replace the prototype-based system with class/object, far from it. What I want to do is unify waifs into the prototype system and lose the distinction that is starting to emerge. I think a consequence of this is that objects would have to become reference counted, which would result in a performance hit. I don't think the performance hit would be that bad anyway: MOO already throws strings and lists all over the place and those are refcounted.
Now that I have more time to put a post together, here's some other wild ideas I've had, not all of which are necessarily *good* ideas I might add:
- Use berkeley db for the database format. Flush "idle" objects to the db to compact the heap. From a performance POV, it's probably a wash; while MOO's memory use is unlikely to strain any modern machine, some MOO workloads do fragment the hell out of the heap, so being able to move objects around on the heap as would be needed for such a system would be a bonus.
- Use something even more exotic for the db format, like Cassandra. I can't think of an immediate use for this, since MOO data tends to be much more intertangled and coupled than most MUDs with generic and limited area/mob formats.
- Verb calls on non-objects, ala ruby and to some lesser degree python. Could get rid of most $list_utils/$string_utils stuff. However, I don't want them hardwired and becoming a junk-drawer of one-off functions, so it would still dispatch to softcode. The question is, what do I assign as the handler? A server option comes to mind. It also really cuts into type-safety if everything can have verbs.
- Generators. Would probably not even be all that hard, since MOO already has coroutines. One problem though is that they would introduce implicit suspends, and most MOO code tends to rely on the need for explicit suspend to have proper concurrency behavior. I don't want to complicate the concurrency picture that much, but I am going to have to come up with something, like maybe critical sections where suspends are disallowed.
- Some kind of list comprehension syntax. Python's syntax is appealing because it wouldn't introduce any new keywords. I'm also considering something more like LINQ, which would allow people to expand it in softcode (just implement the "SelectMany" equivalent)
- A mapping type. This isn't even controversial, I want the damn things. If I can make objects lightweight enough, I could use them for mappings (given some kind of "expando" property allowing one to add properties on the fly). Main problem there is objects have pass-by-reference semantics, and I really prefer keeping the pass-by-value semantics of MOO's "primitive" types -- it's something that really sets it apart. Then again I could also consider copy-on-write objects!
- First-class verbs as a type. "foo:bar" would create a verbref type, that you could pass around and call with function syntax. Not actually too hard, since internally they're pretty well encapsulated already. It makes security somewhat trickier to reason about though, since neither the receiver nor the verb name are obvious anymore when your code gets handed an arbitrary verbref. It's not inherently dangerous, but it does limit their generality a little bit.
|