Dropping Legacy Code - CCObject about cocos2d-xna

[kjpou1]

This will be refactored in two phases.

First the serialization/deserialization code
Second implementing some type of interface that implements a Copy or CopyWithZone

[kjpou1]

Am thinking of creating another interface here:

ICopyable instead of IClonable to distinguish the difference between. Do not want to get into all the theoretical discussions of IClonable and deep or non deep copy.

public interface ICopyable
{
object Copy();
}

Thoughts are

Replace all classes that extend CCObject to implement iCopyable

public class Foo : ICopyable
{
public string Name;

object ICopyable.Copy()
{
return this.Copy();
}
public Foo Copy()
{
// we can do the following:
return ()this.MemberwiseClone();
// or we can keep the code in each object class right now that does
return this.CopyWithZone(null);
}
}

[migueldeicaza]

Do we actually need objects to be copyable? What depends on this?

Perhaps it is best to identify on a case-by-case basis what objects actually need the suport for this?

[totallyeviljake]

This is widely used during animation sequences where an animation is reversed. The reversed animation is copied instead of reset.

[kjpou1]

Miguel

As Jacob says above the animation sequences make heavy use of the copy and a lot of the objects depend on the Copy to be used in the animations. Thus a lot of classes that are bases on CCObject.

At first, I thought we could just rip the CCObject class out and get around the copy but truthfully found it to be a lot of trouble and not as straight forward as I was thinking.

I actually do not mind the CCObject class and the classes that extend it. It could stay in but the ICopyable is also a good compromise.

Of course the serialization should be refactored out into CCUtils (which is where I have it right now) or into a CCSerialization class. Although we could implement ISerializable as well.

Right now will continue with the ICopyable.

Edit:

As for identifying on a case by case basis what I have seen is that any class that extends CCObject is being used or has the potential of being used in the animation sequences.

@totallyeviljake can you confirm if the previous statement is correct.

[kjpou1]

Ok after a couple of half attempts here I am thinking if we want to get rid of CCObject then I will make this suggestion.

CCAction is made to implement ICopyable interface with the two virtual methods following.

internal interface ICopyable
{
    Object CopyWithZone(CCZone zone)
}

public class CCAction : ICopyable
{

    public virtual CCAction Copy()
    {
        return (CCAction)CopyWithZone(null);
    }

    public virtual CCObject CopyWithZone(CCZone zone)
    {
        CCZone tmpZone = zone;
        CCAction ret;
        if (tmpZone != null && tmpZone.m_pCopyObject != null)
        {
            ret = (CCAction) tmpZone.m_pCopyObject;
        }
        else
        {
            ret = new CCAction();
        }

        ret.m_nTag = m_nTag;
        return ret;
    }

}

public class FooAction : CCAction
{

    public override FooAction Copy()
    {
        return (FooAction)CopyWithZone(null);
    }

    public override Object CopyWithZone(CCZone zone)
    {

         // custom copy stuff here
        return base.CopyWithZone(zone);
    }

}

Any custom actions created should extend CCAction for base functionality instead of CCObject. That way we can show an Intent of Functionality <-- just made that phrase up as it sounded good -- and make the interface cleaner.

This also will provide our own type-safe Copy method.

[totallyeviljake]

So, CCObject is used by everything, even a lowly wapper for a color3b object deep in the CCB reader. It seems to be the analog of 'object' in the cocos2d world. The only place where I would be concerned about removing CCObject is in the CCB reader.

As far as classes that actually need to be CCObject, well, that's different. Since the selector (callback) protocols send CCObject, they would all need to be updated to send 'object' instead.

CCICopyable is better named than the CCCopying interface that exists today.

The serialization code in CCObject is something I put in there to do state management. That was all experimental code and should be pulled into its own helper classes. The serialization is half-baked and poorly designed, but it was just my experimenting with state recovery during the tombstone event on a windows phone. It mostly proved unnecessary.

[kjpou1]

Once the pull request above is approved and merged we can close this out.