To Firaxis: We need an isolation layer.

[padillah]

I hope someone from Firaxis reads this: We modders need an isolation layer.

dsplaisted hit close to it when he posted on how to make mods more pluggable, but we need an actual isolation layer, supported by the game.

It shouldn't be that hard and could probably make it into the patch before release.

Please, help with this.

Thank you,
Tom P.

[Kidinnu]

What do you mean "isolation layer"?

[padillah]

It's a methodology used in Object Oriented programming (most specifically frameworks which is basically what the exposed py files are to us).

You create layers in between classes and at the ends, this allows others to use the classes without being hindered by upgrades and such to the framework.

For example: I have three classes Person->BallPlayer->Pitcher If you want to make a change to Pitcher, it's kind of easy - inherit and extend. That's one of the big coolnesses of OO. But what if you want to make a change to BallPlayer?

If you inherit from it that's fine but your changes will not make it to Pitcher. They will be in a different class hierarchy.

So what? Let's just change BallPlayer. We know what we're doing, it's not that big a deal. And that would be fine in almost any other circumstance: except a framework. Being a framework, what happens when the person that wrote it upgrades it? Or fixes a bug?

Then you have to go in, find your changes, copy them to a safe place, go into the new files, find the same place you made the changes (always assuming it's still there. It may have been "upgraded out"), put your changes back in, test them to see that they still do what you thought, debug them... etc.

It's not a pretty picture. So, how do you fix this? The owner has to be able to upgrade and bug fix his product. But If it's not extensible what good is a framework to me? The answer is Isolation Layers.

When you make the class heigerarchy add empty layers in between to isolate the classes from each other, like so: FullPerson->EmptyPerson->FullBallPlayer->EmptyBallPlayer->FullPitcher->EmptyPitcher

Now, when you want to add code you add it in the "Empty" layer. And when the owner wants to fix his code they only fix the "Full" layer. That way no ones code has to touch and nothing gets mixed-up.

Any inheriting is done from the empty layer that way your code is the one used, and so forth.

That'll be $595 for the class.

Tom P.

[James M]

There are some other pythonic options, such as wrapping BallPlayer or metaclass hackery. I'd prefer using these, as you can keep logically related code together rather than forcing someone to play hunt the thimble in an overengineered class structure.

And I'd argue that extending to add functionality is mostly a mistake in the first place, but that's OT.

[padillah]

Originally posted by James M
There are some other pythonic options, such as wrapping BallPlayer or metaclass hackery. I'd prefer using these, as you can keep logically related code together rather than forcing someone to play hunt the thimble in an overengineered class structure.

How is a layer specifically set aside for extensability "playing hunt the thimble"? Or, least wise, any more "hunt the thimble" than the nominal solution we have now, overriding extensable codebase in two disparate directories.

And I'd argue that extending to add functionality is mostly a mistake in the first place, but that's OT.

How would you suggest we add functionality? Adding functionality through extensibility is what OO IS. I'm not sure I understand.

Are you suggesting that we not use an OO language? Are you suggesting that we rewrite the codebase itself?

Please elaborate.

Tom P.

[James M]

Originally posted by padillah
How is a layer specifically set aside for extensability "playing hunt the thimble"? Or, least wise, any more "hunt the thimble" than the nominal solution we have now, overriding extensable codebase in two disparate directories.

I'm thinking of applications which have a class structure

A -> B -> C -> D

with a bit more functionality added at each stage. When someone calls foo() or alters bar -- how do you know where foo or bar are defined, overridden, etc. I usually end up grepping foo and grovelling through each line trying to work it out. If the design doesn't maintain encapsulation between layers of inheritance then you have a nightmare scenario.

This is pretty common. ANTLR is designed this way, for example. I once had to activate an unfinished feature in it, and said feature turned out to be scattered through 5 levels of heirarchy. Took me 2 days to make a one-line fix.

How would you suggest we add functionality? Adding functionality through extensibility is what OO IS. I'm not sure I understand.

Are you suggesting that we not use an OO language? Are you suggesting that we rewrite the codebase itself?

Please elaborate.

OO is a lot of things... don't get me started

- A way of maintaining an invariant on all operations on a piece of data via encapsulation <- really important one. This alone is the reason OO is important IMO. Of course Python doesn't support encapsulation.

- A concrete method for cleanly modularizing code, related to the first point

- A way of implementing run-time polmorphism using interfaces/pure virtuals, obviously this is irrelevant in Python

- A package management system in some languages

- A way of reusing code through inheritance: now this is the one that I find screws things up in practise. You get code reuse, polymorphism and breaking of encapsulation all in one package, which is kind of powerful but encourages people to mess up code with dependancies and leap to overengineered solutions.

- Other stuff

I don't know how much programming you've done in Python, but I will say: Pythons take on OO is unusual, takes a bit of getting used to and is vastly more powerful than anything you will find in an OOP textbook. The particular pattern you were refering to can be constructed in alternate ways, without the original creator worrying about it.

I'm not saying inheriting functionality is inherently wrong (there is a school of thought that says this, though. It's pretty influential right now as so many projects have turned into unmanagable cluster****s because of brainless use of the feature) or (especially) that we shouldn't use it if we have been handed it. But it's something to be done thoughtfully and deliberately rather than leaping to it because one is doing 'OO programming.' That's not to criticise what you were saying, it was merely a general observation.

/end rant

[padillah]

@ James M

I think you have more salient points than I do. Mostly because my experience has jaded me to whats out there in the "programming community".

I have been programming profesionally for several years. When we take on an application we go into design meetings and hash through every little nuance that the application can encounter.

We know what we are doing and we know why we felt this was the best way to handle the particular issue. The people I work with are here because they are very good, intelligent, hard working, dedicated, specialists in their fields.

This is not the case with CivIV's "target audience". There is no guarentee of how a coding practice would be handled by some random person writting a mod. There is no telling what level of competance, how dedicated the person is (are they going to do the right thing or the quick thing?).

In the wrong hands this has every opportunity of turning into a nightmare, yes. I was not thinking along those lines because, thus far, I've managed to keep myself isolated from some of the worse elements in our industry.

This is one reason my favorite CIV quote is:
"A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away."
-- Antoine de Saint-Exupry


Tom P.

[James M]

Originally posted by padillah

This is one reason my favorite CIV quote is:
"A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away."
-- Antoine de Saint-Exupry

Tom P.

You are lucky, I think. If I approach everything from a viewpoint of 'how is some idiot going to break this', it's because I've seen so much of the dark side. My work, professional and otherwise, has mostly consisted of trying to fix mistakes.

But I can't stand board meetings, either, so I'm shuffling myself off into academia. Glad you like the environment.