I want to ask your opinion on something.

Currently in groovymud (0.2) you need to use the attendant to load groovy objects.

Currenly you can do this:

…

    def obj = attendant.load("my.package.Something")
…

"load" calls the GroovyScriptEngine to load the object, and configures the instance by using the "configure" method of the MudObjectAttendant. The "configure" method adds the dependencies and registers the bean with the mud registry (effectively registering all the different names of the object in a TreeMap). It also initialises the object for the first time by calling the initialise method.

I've just figured out how to put spring to further use loading single instance objects from groovy. It was my intention just to keep spring for loading objects that require a single instance but were not mud objects. However, the presence of Spring in the groovy layer means I now have the opportunity to do something like this (if we put the mudspace on the runtime classpath):

(in a spring definition xml file)

<lang:groovy id="something" script-source="classpath:my/package/Something.groovy" customizer-ref="mudObjectAttendant" scope="prototype">
        <lang:property name="registry" ref="registry"></lang:property>
        <lang:property name="name"><value>old man</value></lang:property>    
</lang:groovy>

and then in the code…

…
def obj = registry.getApplicationContext().getBean("something")
..

Of course I'd have to make MudObjectAttendant more of a "Customizer" object now (which extends the spring groovy Customizer interface) which more tightly integrates the code with Spring.

The other issue I can forsee is that you will need an spring xml file for (at least) every domain there is, if not every package the mud has AND THAT I WOULD BE REQUIRED TO FORMALLY REGISTER EVERY OBJECT IN THE SPRING CONTEXT XML that required loading by the mud. (possible yuckyness)

The bonus is that we can also keep track of every object that requires loading by the mud in the xml files. We could also use more abstract classes (less actual class files) and define those in the spring xml as beans instead of formal objects (and customize them with other beans?) or in the initialiser of a room object. So (for example) we could have a generic human object and then use spring to define 15 slightly different human objects (old man, grandmother, woodsman etc) which can be loaded by the app context in whatever room we want. In effect I go from formally using objects to define every object in the mud to defining beans which determine every object in the mud. The same goes for rooms. I move from formal room class declaration to bean declaration with code in the "virtual area object" to handle the fact the room object is the same actual object as somewhere else the player moves to, just updating internal state instead.

My other worry is that the spring configuration becomes unwieldy and daunting to change, where as code is (reletively) easy. However I could circumvent this by designing a reasonable tool to provide an interface.

My other other worry is that I will have to change the name of the mud from groovymud to springmud… but thats another discussion!

What are your thoughts? What method would you prefer? Spring framework for Mud Objects or Mud Framework for Groovy objects?

I don't understand what this "Spring" thing is doing for you that you can't already do, nor do I understand where the distinction is being drawn between classes, instances of those classes, and how those instances relate to player-visible game entities. You said for example that one room object is instantiated for the entire MUD but as people move internal state changes, but that probably isn't what you actually meant given that several rooms can be occupied at once.

Also, it might be helpful to talk a little bit about what "Spring" is, in high-level terms. :wink:

What is the problem you are trying to solve here? I'd need to step away from all these details and figure out what you're trying to actually do before I could even start evaluating a particular technology.

OK

Spring is an IOC (inversion of control) container, and allows me to define and access objects that I will need in my application. Objects can be single instances, or prototypes (created every time i need them). Spring allows me to reference the object by a name (or an ID) so I can get an instance of the object from Spring by a bean name. It does a lot of object plumbing for me, so I don't have to set internal references all the time and waste large amounts of code setting things up, I just define beans and their dependencies instead. The downside is I have to define all the beans I need before hand in the xml files.

It also (amongst other things) helps me avoid nasty static single instance factories and static references. Instead of having a static reference to the Mud Engine, I can ask spring for the mud engine bean and it will return the same instance every time (unless i ask otherwise).

In my mud engine rooms are all defined as container objects, that contain players and other mud objects. Players have a Location object which describes which room they are in (and possibly other meta data too, depending on which subclass of Location they might be using). Objects (ALL MudObject objects) are loaded using an single instance object called "MudObjectAttendant". The attendant loads, initialises, and registers the MudObject with the muds registry and moves it to the correct Location by adding it as a content item to the correct Room (if it exists, otherwise it loads that too in a similar way).

Spring would replace most of this. Basically, the Registry and the MudObjectAttendant are a big IOC container in their own right, but only geared toward a specific object type, "MudObjects". The model would change to Spring being the IOC for EVERY mud object and the Registry and MudObjectAttendant would change to just being a list of MudObjects for the game to process and a Customizer respectively.

My "problem" is that I now have two IOC containers. And conceptually I can't really work out which one is for the best.

Should Spring replace the MudObjectAttendant as the IOC? ie, use one IOC for all objects? or should I keep the distinction between them? How comfortable would anyone be with defining spring beans over writing groovy code?

I'm not sure how it's different to ask for a class's singleton instance vs. asking some factory for an ID/xml file and getting back the same instance every time.


I think that's because you're thinking about this problem in terms of implementation details without having worked out (or explained here) the higher-level picture. When I asked you what the problem was, I wasn't expecting to hear something about "Spring vs. Groovy: which one?". I wanted to hear what the higher-level conceptual problem is here. It sounds like you are trying to organize your game objects somehow. But it's unclear to me if you're organizing prototypes, instances, classes, or what have you.


Can't answer that question as I have written neither Spring nor Groovy.
That said, the XML spec given above looks pretty darn annoying to write when the code equivalent is likely to be pretty simple. In fact, XML in general is annoying to write by hand. Of course, tools can address this.

Its not.. you just use the spring framework to do that for you rather than writing your own factory.



Ok I have a mud engine that can create and store mud objects. I also have a framework my mud uses to store single instance and prototype objects of all sorts. Both do similar jobs. What level of intrusion to my codebase should that framework acheive? Should I use the framework to instanciate and register mud objects (rooms, items and the like) rather than my mud doing it it's self.

Is that high level enough?



Almost hit it on the head there. The problem is that I am confused about how best to organise my game objects. I am confused because I have next to no experience about how people actually use code bases to write muds, and you lot hopefully do. Its not a problem in the sense that I cannot figure out how to do it, it is a design / implementation issue which is a subjective decision based on end user requirements.

(writing a tool obviously removes this problem either way and that may be the answer here, but i am not yet at that stage :D)


Spring config can look like poo and code can solve the same problems in a different way. I suppose it will come down to having 100 xml files with 10000 defined prototypes against 10000+ class files when things get really big.

I'm guessing that a blend of both will be enough to give me the flexibility I require.

Hmm. You said something that made me wonder if we're speaking the same language so let me focus on it for now:

Why would you ever have so many class files? Are you using "class" and "object" interchangeably or talking about something else? Does each instance get its own class, or are you creating one class per prototype? (if so, why?)

When I say object I mean class instance currently in memory, prototype i mean an available new pre-configured instance of a class that spring will create for me on demand and when I say class I mean class file (one that the classloader can instanciate, either groovy source or java bytecodes).

I suppose originally I had only thought of one instance, one class, with rooms being single instance objects defined by one or more classes. With a recent update I have added support for the Location object which can potentially hold location meta data (ie, a co-ordinate position or object id) that can be processed by the room instance and provide "virtual" locations.

I could forsee a circumstance where someone might create one class per room. I don't know if this is conceptually correct or not, and I guess not.

Should this kind of thing be encoraged or discoraged? What are your thoughts? You are certainly making me think anyway :)

A class is used to describe behavior, whereas an instance is used to represent the state of a particular object that has that behavior. If all rooms behave the same, and simply have different attributes (name, coordinate, etc.) you don't need (and you probably don't want) one class per room, because a single class captures the full description of a room's behavior, with the instance variables filling in the blanks.

Now this is all in the abstract sense, as rooms could appear to behave differently due to scripts or whatever, but really that's all just the same behavior in that a room can have scripts attached to it. The term 'behavior' is being used here to mean rather specifically code semantics behavior, not stuff that players see.

So far, I see no reason to have one class per room, and indeed, I see many reasons not to. I would very actively discourage anybody from creating thousands of classes: I find it extremely difficult to believe that an application would require thousands of behaviors without it being a sign of terrible application design. Just imagine the maintenance nightmare: what if you want to change how all rooms behave? How do you go fiddle with thousands of classes in any reasonable way?

Of course, I don't know exactly how Groovy "thinks" of these things. Maybe Groovy doesn't understand class in the way I do. But I'd be surprised if that were the case, given that basically all programming languages use 'class' more or less the same way.

I agree, the instance represents the current in memory state of a class. You're teaching grandmother to suck eggs i'm afraid but I appreciate the help all the same :D



ok i think i understand what you are saying. You are saying that because all rooms behave the same (with the same encapsulated behaviour attached to them) then there is no need to replicate this behaviour with other classes.

You leave out inheritance in this mix. I can still have a bunch of class files that represent different rooms even though I am using the same basic room behaviour. My object model allows for many class files that share a basic inherited room object. But that room object is "pulled up by it's boot straps": it initialises it's self (provides it's own prototype) and therefore, although it works, you end up with needing many class files (one for each prototype).

This was my mistake, I think, and one I am going to rectify. I think I require another abstraction layer over the top of this perhaps that defines an "area" but actually built in to the object model. This area object can declare prototype room objects and provide their instanciation (by whatever means required, whether spring instanciated or database or just declared as code). This solves innumerable issues, provides good practice and is now a complete solution. Prior to this conversation I had seen virtual areas as a superfluos requirement, one to be built by the mud builder and not provided by the model.

Thanks! You've helped me undestand a flaw in my software. Well done :wink: Its been bugging me for weeks but I just couldn't see the issue.



well you solve this with inheritance, but you still end up with lots of unwanted and uneeded class files.



groovy is java in disguise. there's nothing different. i think it's just you and me that speak slightly different language when it comes to oo.


thanks for your help!

Well, I guess you'll have to clarify what you mean then with your usage of the terms in order to really have a meaningful discussion. I'm glad that you've gotten something out of this but I'll freely admit that I still don't understand what your problem is or how you think you've solved it or what issues have been addressed. :smile:

Let me give an example of something you said that is rather odd per the traditional usage of terms.

This is not at all what instances represent. A class is just a description of behavior. Classes don't have "in memory state", barring static variables (which are another question). An instance is some object that has some state and implements/understands/responds to (etc.) the interface defined by its class. A class is just a specification of how to talk to the object and what you get out of it.

As I said, it makes no sense whatsoever to build different rooms by creating whole classes for each one even if you inherit from some shared room object. What will these new classes actually do? What is the point of creating new behavioral types, if only to exactly replicate the parent's behavior?

What does make sense is to have some kind of room class, and instantiate it once per room. You can still have prototypes from which instances copy their default values. But all this talk of one class per room is frankly extremely confusing to me because no matter how I look at it, it just sounds insane. :wink:

Anyhow, maybe other people will have better insight for you than I do, but still I'm glad that something I said was somehow helpful! :smile:

http://en.wikipedia.org/wiki/Object-orie...



hmm i was sure that I actually said that instance represents the current in memory state of a class … maybe you misunderstood or I assumed you understood by "current memory state" that i meant "at runtime"…





Yes I was confused too. And it was insane. But my oo model was blinding me. I was defining the state for the room objects I require within the same object model. This was because I was mistakenly thinking the inheritance was the way forward. I do only have one base room class that encapsulates default room behaviour, and all other rooms inherit this. But because rooms are single instance objects and because I had no object in the model in which to define room prototypes with, it meant I HAD to define one (inherited) class per room.
Until we had this conversation (you are the rubber duck I'm afraid :)) my model was blinding me so much (along with my disinterest in using a db) that I was convincing myself that the inheritance takes care of everything when in fact it leads to the madness of future problems and the dissemination of bad programming practices :(

The abstraction of an area layer solves my issues. I just have to work out how to integrate it into the object model now without rearranging everything :S

Call me picky, but Wikipedia is also not saying that classes have "in memory state" :wink: Especially when you use the word "the" in front of state, you're making it sound like the class has this one state.The object has state, the class is behavior and (again barring static variables) has no state. Class "state" is quite different from instance state – a class could keep track of how many instances were created for instance (using a static/class variable). Precision is key when discussing complex, abstract concepts.

sigh

are you really going to go into this? fine i'll bite some.

to be picky myself, when a java classloader (say) loads a class into memory it becomes an INSTANCE of the class. a class by definition is just a blueprint, ie the very binary that is produced by javac. Class never has state. ever. a class defines state or states, an interfaces for using the state. you said almost exactly thisbut then went on to say classes do have static state, which they do not: they just define state, period.

so no matter whether i say "the current memory state of a class" (current in memory state perhaps i should have said?) or "a current instances state" i at no time said "the state of the class" because classes cannot have state in that way.



let me put this very simply, as soon as you load the class into (or allocate) memory it is no longer a class, it is an instance. whether or not you use that instance is besides the point. That is how static variables work, the classloader object instance keeps track of variables that are marked static especially.

I do have 11 years Java development under my belt.. If i'd have said "please help me with my object oriented concepts, I don't understand what a class is" I could understand the lessons in oo :D

i was looking for a subjective viewpoint on what was methodology best but, thankfully, discovered a flaw in my object model (an unexpected and welcome outcome). Be assured that I do actually understand what I am talking about, even if it does not seem like it sometimes ;)

apart from that, thanks again! I do actually have to do quite a bit of refactoring to fit areas in. oh for real mud coding experience!

Err. Maybe in Groovy they don't, but in very many languages classes can have static state, which is memory state associated with the class and not its instances. You say you've worked in Java for 11 years, so how do static variables fit into this picture? In other languages like Python for example, there is an explicit notion of class vs. instance variables. (That the implementation details store the variable in one place or another is really kind of irrelevant.)

Just to be clear, my goal is to not waste our time talking past each other. As evidenced by my repeated questions, I really was not understanding the world you were working in for several posts (in fact I'm still not sure I do). If words are being used to mean wildly different things, intelligent dialogue is impossible. When discussing complex subjects, it's very important to be precise in our meanings. If you feel that I'm using terms strangely, by all means tell me so that I can clarify or perhaps correct my usage.

Hah

Totally changed my mind :)

To be honest, refactoring my code to include an area abstraction was a pain, and a waste of time. it was also totally inflexible.. what if i needed an abstraction above "area"? I'd be there sticking in new abstractions til the cows come home.

I'm going to use the grails bean builder to wire my world together. It lets you dynamically build prototype objects with groovy code and stores them with a bean id in a spring application context so they can be instanciated when you need them.

Instead of all that spring xml above all I do is:

// in an area.groovy file somewhere in my code

def bb = new BeanBuilder(parentContext)

bb.beans{
    townCenter(Room){
          name="Town Centre"
          description = "You are standing somewhere in the town centre"
          exits = [ centreNorth, centreSouth ]
  
    }
    centreNorth(Exit){
    …
    }
    ..etc..
}

this way, i can define and load a world grails bean def somewhere (which just "loads" all the area.groovy files in my codebase). When a player is loaded, their location is a bean id. this bean is instanciated by spring, recorded in my game object registry and the player is then added to that room.

the rest of it works the same way as before, so little code change is required, just additional grails.beanbuilder code that is entirely separate from the mud object model.

I just have to alter my object loader to get the objects from spring instead of loading them from the classloader and viola. instant areas :)

well. hopefully.

in theory, you can also define dynamic beans with undetermined bean names. so i could use a db to generate spring beans in one area, and hard code the prototypes in another. it feels good to finally have a solution i am totally happy with! :D

I stand corrected: you can call static variables class variables :redface:

http://java.sun.com/docs/books/tutorial/...

To be fair I never talk about "class variables", only static variables. Apologees for being unclear.