If you're adding, removing or changing an attribute to your class, this is an incompatible API change. Consider if your class is a part of an software library already used by other developers (e.g. your co-workers, or if your library is open-source, anybody who downloaded it and started making their project using it), if you make an incompatible change like that, immediately other people's code might stop working or work incorrectly. This kind of API change should only be allowed to happen between major new releases (e.g. your library version was v1.X.Y and you release a v2.0.0).
When you serialized the instance of your SomeClass to a file, the class name is also stored in that file, so when reading that instance back from the file, Flash will know an instance of which class to create. However consider that if you change your API, it's no longer the same SomeClass, the name is the same but the class definition is different. There's no easy way around it.
If you really need to keep access to the data in that file. A simple solution would be to store version info in your data file as the first item. Every time you change the file format, you should increment the version. When writing the file, write the current version first. When reading the file, read the current version and store it as a public static property in a class that can be accessed from anywhere in your project (e.g. create a separate class DataLoaderInfo and a public static var formatVersion:String or uint). Then keep reading your file as you did before. In your class SomeClass, which you want to modify, would look like this:
function readExternal(input:IDataInput):void {
// Read format version 0 properties.
oldIntProperty1 = input.readInt();
oldIntProperty2 = input.readInt();
...
// Read format version 1 properties.
if (DataLoaderInfo.formatVersion >= 1) {
newIntProperty1 = input.readInt();
...
}
// Read format version 2 properties.
if (DataLoaderInfo.formatVersion >= 2) {
...
}
...
}
You can imagine, if you have many file format versions, the code might become quite complicated. It all depends what kind of application you're developing and how many versions might be deployed in the field at the same time. For example, if your app is a mobile app, storing it's settings or state in a binary file, each user might update at different intervals, therefore a user might upgrade to your latest version from different older versions, so your app should be able to gracefully load configs of all these versions. If all your data is stored on your own server, and the only access to this data is through the latest version of your app deployed on your server as well, you only need to support formats of the last deployed version and the current (new) version.
You might also consider making a separate utility app to convert your data file to the updated format.
1) Create a subclass ExtSomeClass of your original class SomeClass. Add your new API (e.g. properties) to the subclass. Override the IExternalizable methods of the class - call super's methods first, then read/write the added new properties.
2) Make a utility conversion app that reads your original file, containing instances of SomeClass. For every SomeClass that you read, you should create a new instance of ExtSomeClass, copying all SomeClass's properties and initializing ExtSomeClass properties with some reasonable defaults. So every instance of SomeClass gets replaced by ExtSomeClass. Write the converted data back to your file.
If you don't want to make a subclass, and want to indeed modify the original class SomeClass, you can also do that, but the conversion code will be more tricky, since you'll need access to both old and new versions of your class, obviously you can't have two classes with same name compiled in your project, you would have to compile your new (updated) class into a separate SWF, the conversion app should be compiled using the old version of SomeClass, then you can read your old-version file, every instance of SomeClass will be read correctly using the old version of your class. Load the SWF containing your new (updated) class using Loader, you can use loader.loaderInfo.applicationDomain.getDefinitionByName to get a reference to your new Class, you can create instances of the new class this way, and then copy all the properties from the instances you read from the file.
