A proposal... (python)

[Derakon]

Curses is not a requirement. There's millions of ways to display text in a window. My favored approach would be OpenGL just because it keeps our options open with regards to alternate display modes.

[Sirridan]

I'm separating display code and 'core' code so that each doesn't have to care about the other. There is a display interface and that is all the display has to implement to work with pyAngband. Curses, SDL, a web browser even, it should be pretty easy.

I'd like to do C# though, so I might change it over, it's still all mostly design docs instead of actual code...

[Derakon]

The concern I have with C# is cross-platform compatibility. Python works no-muss no-fuss; IIRC C# isn't quite as versatile.

[Therem Harth]

Also, I hate to say it, but C# is Microsoft's language, and they cannot be expected to keep promises. Not even legally binding ones, given how wealthy they are.

[Pete Mack]

Also, I hate to say it, but C# is Microsoft's language, and they cannot be expected to keep promises. Not even legally binding ones, given how wealthy they are.

I don't think Microsoft has a real interest in keeping C# and .NET proprietary. There are already partial implementations by GNU (thru .NET 2.0) and Mono (thru .NET 4.0). They are more than enough for apps with minimal graphics like angband.

Like any big company, Microsoft wants to sell mass-market products, not specialty producst like languages.

[getter77]

Lua strikes me as the best candidate for a "safer C".

While I know it isn't done cooking yet, has anybody toyed with the notion of Angband in terms of T-Engine 4? While ToME 4 is a very different game, given Lua and whatnot, I'd reckon there's simply GOT to be some degree of legwork that'd at least be easier ground to trod upon...

[Atarlost]

It's not remotely the case at all.

Object orientation is a shorthand that does the following:
* gives you a hidden parameter for the object
* allows declaring object members as "don't access these from any old function", which can be used to convert many bugs into syntax errors.

For small-scale projects, it is particularly true that if the (lead) programmer doesn't have adequate procedural programming skills, then spotting where object orientation makes things easier is next to impossible.

E.g, the problem with converting terrain features to a struct/class in V, is simply that:
* there's nothing that naturally would want to take a terrain feature as a parameter.
* there's no internal structure to wrap (I suppose you could use bitfields but why bother).

The mess/disorganization manifests differently.

In Java, the general problem is Lines of Code. One time I was reviewing XML generation frameworks; the Java one was disqualified for taking 12 pages of printout to do what three other frameworks could set up in one page.

In C and C++, it's more that the language has a Programmer is God mentality and won't stop you from shooting yourself in the foot.

A lot of the problem with OOP is that almost everything you might want to use a method for is barred from doing so by the edit file mentality. It might make sense for quaff, zap, and read to be methods and individual potions, rods, and scrolls to inherit from generic potion, rod, and scroll classes, but the need to read from an edit file pretty much locks you into the nasty bulky switch statements that hold most of the code for item use. Abandon the edit files and useable items make much more sense as objects. Go to a noncompiled language and you can have your modability and still have useful objects. Of the languages under consideration I think only Python gives that benefit.

There may be a few other things that would benefit from inheritance. I would guess anything running through a big switch might.

[Sirridan]

I might switch over to C#, it's my preferred language after all. I'm still on the fence though, but damn, LINQ is nice.

I'd still keep edit files though. Potions could be easily represented with a python dictionary, such as this:

potions = {}
potions["Heal"] = {"name": "Healing", "desc": "Heals you for 300 etc.", "Effect": [(HEAL, 300), (CURE, ALL)]}

where each entry in potions has a dictionary containing an item with a name, a description, and a list of tuples (effects) each tuple containing the effect code and magnitude. The healing potions heals for 300 and cure's all statuses. It's pseudoish but still that's kinda what I was thinking of doing.

In any case, it's on paper still, if anyone is interested I'll make some UML diagrams or something of what i've got done so far, since actual code I've written is amounting to nil.

Also I was thinking of doing it as a client/server deal, where the main angband is just a server listening to a port, which sends relevant data to the client. That way the core of angband doesn't have to care about how the client displays anything, it just tells the client what is going on. No windows, no UI code, no display formatting, nothing like that to bother maintainers.

[Derakon]

I don't see why the edit files keep you from a proper OO system. You should be able to treat them as serializations of objects. Yes, you'll need some kind of mapping from e.g. CURE_CRITICAL to "restore X% of lost HP" at some point, but that point need not be in the final version of the OO Angband. It could be a conversion job that someone does as part of the porting process, with a new form chosen for the edit files thereafter that is more amenable to OO.

[cinereaste]

In any case, it's on paper still, if anyone is interested I'll make some UML diagrams or something of what i've got done so far, since actual code I've written is amounting to nil.

I'm interested.

[Atarlost]

You don't really get any benefit from going OO if you're not using polymorphism to replace the big switches though. You can serialize objects, but classes are compile time in compiled languages. You can't serialize those.

You can stick function pointers in your item structs, but that's something you can do in C as easily as C++.

[Derakon]

In Python you can have a module name as a string (e.g. loaded from a data file), import that module, query it for the name of the class you want to instantiate, and then instantiate that class, all without knowing directly what you're manipulating. It makes for somewhat ugly code -- you have to invoke __import__ and may need to also look at the module's __dict__ member, but it's far from "inflicts blindness on every programmer in 50 paces".

Or you could just have a module full of magical spell effects:

def cureLightWounds():
    ....
def cureSeriousWounds():
    ....

and another module (which would be the equivalent of an edit file) that imports the first module and defines objects based on it:

import spellEffects

droppableObjects = {
    '!': [ # Potion definitions
        'Cure Light Wounds': {
            invoke: spellEffects.cureLightWounds,
            rarity: 2,
            depths: [4, 15, 30]
        },
        ...
    ], # End potion definitions
    '?': [ # Scroll and book definitions
        'Word of Recall': {
            invoke: spellEffects.recall,
            rarity: 5,
            depths: [10, 20, 30, 40]
        }
    ] # End scroll/book definitions
}

This kind of format makes for much more verbose edit files; they'll be a bit longer to write, but much easier to read. Anyway, at runtime you have code that loads the "edit module" and instantiates objects based on the entries in the dictionary.

[camlost]

I'm going to guess that the language debate won't really ever coalesce into a single solution. Perhaps it's time to pony up with a (approval?) poll of developers who are interested and work from there? Or maybe form one or more small teams to work toward implementations in other languages?

Or continue to have fun discussing the merits

[Sirridan]

You don't really get any benefit from going OO if you're not using polymorphism to replace the big switches though. You can serialize objects, but classes are compile time in compiled languages. You can't serialize those.

You can stick function pointers in your item structs, but that's something you can do in C as easily as C++.

Well you can replace most, if not all, big switches with either lambdas or the fact that functions are first class in python.

def apply_heal(living_thing, heal_magnitude, cures):
     living_thing.mod_hp(heal_magnitude)
     living_thing.cure(cures)

...

potion["heal"] = {"name":"Heal", "desc":"Heal 300 and such", "effect":apply_heal}

This is perfectly valid in python

[Pete Mack]

You can stick function pointers in your item structs, but that's something you can do in C as easily as C++.

In C++ that's arguable, but in C, it's a huge hard-to-read pain. I spent several extra hours trying to do "O-O" style functions in C while writing the menu class. Yes, I did it, but it would have been a lot easier even in C++. And much, much easier in a language whose standard libraries already come with menus predefined!