Base classes...

[Joeku]

Okay, this is really starting to tick me off. Any time I have a great idea that would require a modification to all classes (either item or mobile), I have to ditch it because it would require a core modification. I think it would be nice to have "empty" classes; so:

-BaseItem is in the core
-Item (containing no functions, just a blank class) which is a sub-class of BaseItem, is in the regular scripts
-Everything branches off of Item

That way, if I want to add a property to all items, it doesn't require a core modification. The same thing goes for mobiles. This would make things easier to add stuff to everything in a class.

Comments please.

[Courageous]

That's a fine idea.

C//

[Greystar]

yah i had done that at one point but eventually went away from it (mostly cause i was too lazy to go back through and change all Mobile references to BaseMobile and all Item references to BaseItem. It was usefull the first time i added the personal bless deed to my shard. also when i was adding my global level system that I wanted to affect players and creatures alike. but anywho, it's doable but i dont ever see it happening officially.

[TheOutkastDev]

The only problem with this is making it backward compatible for shards with items already in existence.

How would you handle converting these items?

[Greystar]

Originally Posted by TheOutkastDev

The only problem with this is making it backward compatible for shards with items already in existence.

How would you handle converting these items?

heh to my knowledge you couldn't I ended up wiping my Entire shard the first time I did it (Including my playermobiles, which pissed off my players to no end), but I gave em some extra pscrolls and boosted their stats and some of there base "profession" skills to a little higher and they stopped whining, but from that point i had a warning popup when they logged one. But you are entirely right and that is one of the other reasones why I tossed the base stuff out.

[Ray]

Originally Posted by TheOutkastDev

The only problem with this is making it backward compatible for shards with items already in existence.

How would you handle converting these items?

They do not need to be converted in any complex manner. In a very short-mulled way: All that is needed to change is the deserialize function of this class, by adding a one time job to it. And the core, of course.

public override void Deserialize( GenericReader reader )
{
	base.Deserialize( reader );
	if(OldVersion) // only to call if the save has items with 'my' data
	{
		int version = reader.ReadInt();
	}
}

else, the reader would make no reading at this point, thus the filepointer (in a binary save) stays at the current position, allowing the subclass to continue.

That works for all inherited classes.
Now the core code; core-Item is a directly constructable class, thus, the mentioned subclass would be surpassable. This could be avoided by making the item class non-constructable and abstract. Of course with a rename to BaseItem and all references to it withing the core, otherwise most bundled scripts with a new Item() call would stop working. If the core containes a new-call to this abstract class, it would stop to work as well.
That would be all, i think. Correct me if not

Now what can 'OldVersion' be...
a simple bool for the scripter who needs the convert?
a startup-parameter?
a configure variable?
an automatic value fetched out of the save-format?


Comments...
This would make many things easier, especially own functionality. But i dont see a real need to do that.
The above mentioned way inflicts a lot more than only the things listed. Once the Item class gets abstract, the next step would logically be to make as much functions as possible virtual or abstact too. That would raise expenses in safety, maintainability, and speed.
Oh, forgot, i'm an optimist

[XxSP1DERxX]

If you want an empty class, you would want empty methods... such as

public override void Deserialize( GenericReader reader )
{
     base.Deserialize( reader );
}

[Jeff]

Ah interesting topic, I would like to see a good answer to this

[Joeku]

using System;
using Server;

namespace Server.Items
{
	public class Item : BaseItem
	{
		public Item( Serial serial ) : base( serial )
		{
		}

		public override void Serialize( GenericWriter writer )
		{
			base.Serialize( writer );

			writer.Write( (int) 0 ); // version
		}

		public override void Deserialize( GenericReader reader )
		{
			base.Deserialize( reader );

			int version = reader.ReadInt();
		}
	}
}

That's what I meant by a "blank class." If there really is a way to convert all existing items to the Item subclass of BaseItem, that would be really great. Either that or you could put a global control script in "Scripts/Misc" on whether or not to use the BaseItem/Item instead of just Item...

Again, this isn't really an issue of need, but rather an issue of want; it would be a lot easier to make global modifications to the item and mobile classes if this "method" was instituted, and I'm sure more people would be encouraged to make a wider variety of scripts.

[xir]

Doesn't C# let you define custom attributes that allow you to seperate crosscutting concerns i.e. Serialisation?

[XxSP1DERxX]

And Joeku, I just said that you can do that (with no problems), if you do

		public override void Serialize( GenericWriter writer )
		{
			base.Serialize( writer );
		}

		public override void Deserialize( GenericReader reader )
		{
			base.Deserialize( reader );
		}

Then once you have loaded it up and what not... if you wanted to add stuff to the serialization, you can version it in later just as you normally would.

[ASayre]

http://blogs.tedneward.com/2005/09/2...Explained.aspx

"Extension Methods"

[TheOutkastDev]

C# 3.0 is a ways away from release.

[xir]

Originally Posted by ASayre8

http://blogs.tedneward.com/2005/09/2...Explained.aspx

"Extension Methods"

If seperation of concerns isn't done at the requirements/design phase it is very difficult and tedious to disentangle the functionality from the rest of the system. (Of course it can be done with refactoring techniques.) Crosscutting concerns that are not handled properly are noticed by code scattering and tangling of a feature or service across multiple units of modularity. Dependancy and tightly coupled interfaces/classes as a result of improperly handled crosscutting concerns reduce adaptability and resuability (on which the whole ideas of OO are based). Is serialisation a crosscutting concern in RunUO? If the functionality of the serialisation service is scattered across multiple classes then perhaps it is.
These "Extension Methods" provide a very very limited AOP type feature to deal with these concerns. There are a couple of Aspect Weavers that I am aware of that allow one to deal with this issue elegantly using the AOP constructs/extensions to the C# language.
My previous question on whether custom attributes can provide a limited solution to this problem still stands, and would be interested to know how it works.

[TheOutkastDev]

Originally Posted by XxSP1DERxX

And Joeku, I just said that you can do that (with no problems), if you do

		public override void Serialize( GenericWriter writer )
		{
			base.Serialize( writer );
		}

		public override void Deserialize( GenericReader reader )
		{
			base.Deserialize( reader );
		}

Then once you have loaded it up and what not... if you wanted to add stuff to the serialization, you can version it in later just as you normally would.

You're still required to run the server once with the serialization code ONLY, then reboot the server with the deserialization code. How many people would you like to wager will screw this up?