Foreach For Skills

[Pure Insanity]

This is a rather minor suggestion, and won't effect anything that's already out there. It would simply allow other developers to use a foreach loop on the Skills class. The edits needed for this are indeed minimal.

Files effected: Skills.cs

Find this

[PropertyObject]
public class Skills

Change it to this.

[PropertyObject]
public class Skills : IEnumerable<Skill>

And within the same class (directly under the OnSkillChange() method will works fine) add this.

        public IEnumerator<Skill> GetEnumerator()
        {
            foreach (Skill skill in m_Skills)
            {
                yield return skill;
            }
        }
 
        IEnumerator IEnumerable.GetEnumerator()
        {
            return GetEnumerator();
        }

This makes it possible for you to use a loop such as this.

foreach (Skill skill in from.Skills)
{
        // Set skill to 42
}

Nothing major, just something that sorta drives me crazy. It's a mod that I've been using for a while now, don't see why everyone else shouldn't be able to do the same. =D

Note: If anyone decides to do this themselves, this does require that you build a new core.

 

[Vorspire]

Obviously lazy developer is obviously lazy.

for (int i = 0; i < _User.Skills.Length; i++)
{
      Skill skill = player.Skills;
}
 
foreach(SkillName skillName in (SkillName[])Enum.GetValues(typeof(SkillName)))
{
      Skill skill = player.Skills[skillName];
}

But I do agree, I always go for the minimal amount of code needed to achieve a goal but this is grasping at straws

Just a note though, no need to loop an already existing IEnumerable to return an enumerator, the code below is all you need and it is also compatible with all versions of RunUO (compensating for those who might still run 1.0)

[PropertyObject]
public class Skills : IEnumerable

public IEnumerator GetEnumerator()
{ return m_Skills.GetEnumerator(); }

There is no need for the Generic IEnumerable<T> interface because there is no Type conversion needed and the m_Skills member is an Enumerable collection of the Skills class.

 

[Peoharen]

Unless Microsoft revamped For/Foreach, For > Foreach.

That is all.

 

[Vorspire]

Unless Microsoft revamped For/Foreach, For > Foreach.

That is all.

They probably have considering the page you linked is from 2004 :/
Also, the guy who wrote that article can't spell "Integer" properly and is listed as a web-developer, not a programmer and he even goes on to say he took a long time to understand the basic concepts of how the code works, IMHO, a useless reference for 2012.

 

[Peoharen]

They probably have considering the page you linked is from 2004 :/

Still pretty accurate. This 2009 cites assembly as well.

If I wasn't using the free version Express I'd pull the assembly code my self...
I don't suppose you have a good suggestion for viewing C# in Assembly? That would be pretty cool to tinker with.

 

[Vorspire]

Still pretty accurate. This 2009 cites assembly as well.

If I wasn't using the free version Express I'd pull the assembly code my self...
I don't suppose you have a good suggestion for viewing C# in Assembly? That would be pretty cool to tinker with.

I use PE Explorer, it's pretty good at disassembling compiled applications.
http://www.heaventools.com/overview.htm

On further testing it does seem that ForEach is optimized and is about 10ms faster that For on each iteration :/

 

[Peoharen]

I use PE Explorer, it's pretty good at disassembling compiled applications.
http://www.heaventools.com/overview.htm

On further testing it does seem that ForEach is optimized and is about 10ms faster that For on each iteration :/

Tool has a limited trial mode, if it's # of days I'm screwed, I'm so busy it's not even funny.

As for the second part, I find that shocking. This site even lists LINQ/Foreach 10ms slower. Really there's dozens of these types of findings as you can expect. None of which using 4.5 of course, so make an account at stackoverflow or bytes (or w/e) and report your findings.

 

[Vorspire]

Tool has a limited trial mode, if it's # of days I'm screwed, I'm so busy it's not even funny.

As for the second part, I find that shocking. This site even lists LINQ/Foreach 10ms slower. Really there's dozens of these types of findings as you can expect. None of which using 4.5 of course, so make an account at stackoverflow or bytes (or w/e) and report your findings.

I can guarantee I'm a hundred times more busy than you are, so why don't you scoot over to there and submit your own findings....

Googling buzz words and posting the first result, lol.

 

[Peoharen]

Hey if you're to busy to submit your findings before real programmers all well. gl.

 

[Vorspire]

Hey if you're to busy to submit your findings before real programmers all well. gl.

You're missing the point, no one cares about the performance between the two.
I've seen your code before, script kiddie Good luck.

 

[Pure Insanity]

I think everyone that replied to this thread, missed my actual point.

I don't give a shit if one or the other is slower. Computers have fast enough processors and tons of memory these days, if you're worried about resources when working on your copy of RunUO...then you better have a few hundred regular players, or just shut up and read another thread.

This was simply a suggestion, an addition. It won't break anything, screw with existing/new developers, ect.

I know very well I could use a normal loop for it over a foreach loop. But it's simply a matter of preference in my opinion. Besides...the Skills class was MADE so that we could easily use it with a normal loop (hence the Length property, or else we'd all be doing silly looking crap like Mobile.Skills.Skills.Length to get the Length.) So I don't see a reason to not add support for a foreach. I rarely use a foreach to be honest, it usually comes down to the situation...and I believe a foreach is not only easier to use for Skills...but it simply looks better.

This would simply give all developers another choice in the matter, which I see nothing wrong with that. As for the yield keyword...RunUO has been on .net 2.0 for a long while now, so I don't see any issue at all with using the yield keyword. Feel free to wrap it with _Framework_2.0_ if you really feel the need...

Sorry for bothering with this thread, I shall continue to keep my ideas to myself.

 

[Vorspire]

As for the yield keyword...RunUO has been on .net 2.0 for a long while now, so I don't see any issue at all with using the yield keyword. Feel free to wrap it with _Framework_2.0_ if you really feel the need...

Sorry for bothering with this thread, I shall continue to keep my ideas to myself.

No one said anything about the yield keyword?
Don't be mad just because Peoharen posts stupid things like that all the time, at least my input was valid 'till he butted in.

 

[ASayre]

Fixed returning the internal array's Enumerator. Vorspire had the correct fix.