Ok, ObjectUtil.copy is a good technique for copying Objects. But after having a lot of problems using it to copy other classes, I guess it is not the solution I'm after.
How would you approach the copying/cloning of instances of a class that you've defined? Maybe defining a function withing the class to copy it?
It is cool that most variables are passed by reference in flex, but sometimes is annoying not having control over this (sorry, I'm too used to plain C).
Thanks!
UPDATE:
To be more precise, as I can't make the ObjectUtil.copy() work with a custom class is... is there a way to copy, by using serialization, a custom class? Did you use successfully a ByteArray copy with a custom class?
Thanks for all the replies.
If you determine that implementing a clone interface is not the correct approach in your situation, I suggest looking at the ByteArray object. I haven't used it myself, but it appears to give you all the control you should need over individual bytes. You can reading and writing from and to any object.
Senocular does a quick overview of it here.
function clone(source:Object):* {
var copier:ByteArray = new ByteArray();
copier.writeObject(source);
copier.position = 0;
return(copier.readObject());
}
Good luck!
ObjectUtil.copy uses ByteArray internally to create a copy. In order for the copy to be successful, ByteArray requires that the flash player will be aware of you custom class. You do that by registering your class using the global registerClassAlias method.
For example:
//one time globally to the application.
registerClassAlias(getQualifiedClassName(CustomClass), CustomClass);
//then
var c1:CustomClass = new CustomClass();
c1.name = "customClass";
var c2:CustomClass = ObjectUtil.copy(c1);
trace(ObjectUtil.toString(c1))
trace(ObjectUtil.toString(c2))
If you have control over the whole class hierarchy, I recommend implementing a clone() interface in every class. It's tedious, but will pay off as complexity increases.
(Forgive me if the syntax is a bit off, it's been a while)
// define a "cloneable" interface
public interface ICloneable {
function clone() : Object;
}
For every class, implement the method...
public class MyClass1 implements ICloneable {
...
public function clone() : Object {
var copy:MyClass1 = new MyClass1();
// copy member variables... if it is a user-defined object,
// make sure you call its clone() function as well.
return copy;
}
}
To create a copy of the object, simply invoke the clone() function.
var copy:MyClass1 = original.clone();
As a side note, both Java and .NET seem to have adopted the clone methods on their base Object classes. I know of no analogous method for ActionScript's Object class.
Two common idioms:
a clone method
a copy constructor
Both of these let you define what exactly making a copy means--you may want some things copied shallowly and others deeply.
Related
Best Practices recommend setting the new method as protected and using instead static new... methods to mitigate the lack of method overloading.
So I use this pattern as explained here
But static methods are not inherited.
So we have to define for each sub class the static construct and the static new... methods.
Therefore we lose some of inheritance's benefits.
I had a look on system classes hoping to find a better solution but what I saw did not really help me :
- some respect the static new pattern and declare the methods in the sub classes
- some just use the instance new without protecting it
- some use the mother class as a "class factory", like SalesFormLetter
static SalesFormLetter construct(DocumentStatus document,
boolean getParmId = true)
{
switch(document)
{
case DocumentStatus::Confirmation : return new SalesFormLetter_Confirm (getParmId);
case DocumentStatus::PickingList : return SalesFormLetter_PickingList::construct(getParmId);
case DocumentStatus::PackingSlip : return new SalesFormLetter_PackingSlip (getParmId);
case DocumentStatus::ProjectPackingSlip : return new SalesFormLetter_PackingSlipProject(getParmId);
case DocumentStatus::Invoice : return new SalesFormLetter_Invoice (getParmId);
case DocumentStatus::ProjectInvoice : return new SalesFormLetter_InvoiceProject (getParmId);
default : throw error(strfmt("#SYS19306",funcname()));
}
throw error(strfmt("#SYS19306",funcname()));
}
So I am wondering if there is a better solution, and if not what would be the best among these ?
A better solution to object construction?
Well, the new have to go somewhere, and putting a lot of new in the client code is fragile and inflexible. So go with the class "factories" especially for related classes.
Two options:
Make new protected. Make a construct for each sub-class, put the factory construct in the base class calling the sub-class constructors. But anyone can then call the sub-class construct method.
Make new public. Don't make a construct for each sub-class, put factory the construct in the base class, new'ing the sub-classes. The new can't be protected as the base class does not descend from the sub-class.
Whether or not you go with 1 or 2 is your choice, you end up with exposing the sub-class constructor. Personally I prefer option 2, as it is the least hassle.
Advice: make your object dependencies explicit using arguments to new. This will complicate your factories, but that is okay as it moves the complexity from your client code. Setter methods (parm methods) is evil, but is needed for RunBase because the it is required by the batch system.
Also go see what Uncle Bob writes.
If I have a class that takes in several constructor arguments including a string that can be null, I am currently using the following syntax for registering it:
container.RegisterType<ISomething, Something>(
new InjectionConstructor(new InjectionParameter<string>(aString), typeof(ISomethingHelper), typeof(ISomethingManager)))
I added InjectionParameter to cope with the case of a null aString which Unity complained about without this.
Is all this necessary or can I shorten it a bit?
Nulls are a bit of a special case, since we can't derive a type from a constant of type null (it just comes through the compiler as type object). So short of writing a small helper function / class, yeah, that's as short as it gets.
I could see writing something like this:
public static class NullParam
{
public InjectionParameter OfType<T>()
where T : class
{
return new InjectionParameter<T>(null);
}
}
Then you could write the above as:
container.RegisterType<ISomething, Something>(
new InjectionConstructor(
NullParam.OfType<string>, typeof(ISomethingHelper), typeof(ISomethingManager)));
I'm not sure that's shorter enough to be worth the introduction of the helper.
The Unity API is designed around regularity and extensibility, not brevity or convenience. This does make some things wordier than would be ideal. The nice thing is that it's pretty easy to write little wrappers and helpers to make the registration code look the way you want it to.
Is there any way, without having the creator of the object implement any special functions (no specific serialization functions) (however, they can use annotations), to have Flash serialize a generic, possibly deep (objects within objects within objects, etc, etc, etc) object?
If this makes no sense, comment as such and I'll try to elaborate.
AMF can be used for serialization of complex objects. Here's some good info:
http://tournasdimitrios1.wordpress.com/2010/07/23/the-abcs-of-amf-format/
There is a generic way to clone an object - however not a deep copy though:
public function clone():MyObject
{
var byteArr:ByteArray = new ByteArray();
byteArr.writeObject(this);
byteArr.position = 0;
return(byteArr.readObject());
}
Anyway a real deep copy is sometimes not really useful as there will often be a certain level, where you will want to stop. So in general I recommend to create an ICloneable interface that defines a clone method. Implement this object for all the objects you want to have cloned and call it recursively for all instances that implement this interface.
I want to extend the FileReference class of Flex to contain a custom property. I want to do this because AS3 doesn't let me pass arguments to functions through event listeners, which makes me feel sad, so I need this property to exist on the event target, so I can access it.
I also want to be able to cast extant FileReference objects to this class without any fuss. I have:
var fr:SmxFR = e.target as SmxFR
and I want that to work; right now it just returns null.
A blank, newly instantiated SmxFR object has the extended property in place, but all of its inherited properties and objects return Error: Error #2037: Functions called in incorrect sequence, or earlier call was unsuccessful.
This is the class I am using, SmxFR.as:
package
{
import flash.net.FileReference;
public class SmxFR extends FileReference
{
public var housenum:String = "";
public function SmxFR()
{
super();
}
}
}
Kept it as straightforward as I could, really. Can someone please help me figure this out? Thanks.
Edit:
Per request, this is the instantiation which results in the aforementioned error in all inherited objects:
var fr:SmxFR = new SmxFR();
I get living handle property from that, and all other (that is, inherited) properties throw Error #2037.
So, maybe what I want to do is going to require overriding FileReferenceList? If the original objects must be instantiated to SxmFR, that's what I'll have to do, since I'm using FRL to allow the user to select multiple files at once. Are you guys sure there is no way to fast from a FileReference to my class?
You can totally pass objects via event listeners, it's just done in a specific way. I'd learn to do it correctly, rather than trying to extend a core library which could cause you problems later if you make a small mistake.
My solution: instead of extending FileReference, extend Event and add your properties to that.
var myEvent:MyExtendedEvent = new MyExtendedEvent();
myEvent.myCustomProperty = myValue;
dispatchEvent(myEvent);
Then in your handler you just write:
function myEventHandler(e:MyExtendedEvent):void {
trace(e.myCustomProperty);
}
Much more painless to go down this road! The added benefit is that if any other Flash Developer anywhere ever looks at your code they're not going to get hit in the face with a non-standard customized FileReference. :)
When e.target is instantiate as FileReference you can't cast it to SmxFR because it's not in the line of inheritance. In the other way you can a SmxFR Object to FileRefernce.
Extending FileReferenceList is not going to be helpful. FileReferenceList.browse() method creates an array of FileReference object when user selects multiple files - that happens internally (may be in its private methods) and you cannot change that behavior and force it to create SxmFR objects instead. Use custom events as Myk suggested.
This article talks about Sound objects, but may be that's applicable to FileReference objects too. May be you cannot reuse them. Post the code where you use the SmxFr class and get the said error.
This question is meant to apply to interfaces in general, but I'll use AS3/Flex for my language. It should be [mostly] obvious how to apply it in different languages.
If I create a base class, and it extends an interface, there is an explicit contract defined: for every method in the interface, the base class must implement said method.
This is easy enough. But I don't understand why you have the capacity to cast an interfaced instance back to its original base class. Of course, I've had to do this a few times (the example below is very close to the situation I'm struggling with), but that doesn't mean I understand it :^)
Here's a sample interface:
public interface IFooable extends IUIComponent {
function runFoo():void;
}
Let's say I create a base class, which extends VBox and implements the interface:
public class Foo extends VBox implements IFooable {
public Foo() {
super();
//stuff here to create Foo..blah blah
}
public function runFoo():void {
// do something to run foo
}
}
Now, the reason I used the interface, is because I want to guarantee "runFoo" is always implemented. It is a common piece of functionality all of my classes should have, regardless of how they implement it. Thus, my parent class (an Application) will instantiate Foo via its interface:
public function init():void {
var foo:IFooable = new Foo();
foo.percentHeight = 100; //works because of IUIComponent
}
But, if I want to add Foo to the Application container, I now have to cast it back to the base class (or to a different base class):
public function init():void {
var foo:IFooable = new Foo();
foo.percentHeight = 100;
addChild(foo as DisplayObject); //_have_ to cast, because addChild takes a 'DisplayObject' class type
//could also do this:
//addChild(foo as VBox);
}
Wasn't the original intention to hide the implementation of Foo? There is still an assumption that Foo is a DisplayObject. Unfortunately, being able to add the custom object to a container seems impossible without casting.
Am I missing something entirely? Is this really just a phenomenon in Flex/AS3? If you have a container in the base API of a language, and it only allows you to add children of a certain class type, how do you then abstract out implementation?
For the record, this question appears to ask if this sort of operation is possible, but it doesn't really address why it might be bad design (and how to fix it).
2nd Thought:
Abstract Classes:
As Matthew pointed out, abstract classes helps solve some of this: I could create a base abstract class which inherits from the DisplayObject (or, in my case, the VBox, since it is a child of DisplayObject), and have the base class implement the interface. Thus, any class which extends the abstract class would then be required to implement the methods therein.
Great idea -- but AS3 doesn't have abstract classes (to my knowledge, anyway).
So, I could create a base class which implements interface and extends the VBox, and inherit from it, and I could insert code in those methods which need to be extended; such code would throw an error if the base class is the executor. Unfortunately, this is run-time checking as opposed to compile-time enforcement.
It's still a solution, though.
Context:
Some context might help:
I have an application which can have any number of sub-containers. Each of these sub-containers will have their own respective configuration options, parameters, etc. The application itself, however, has a global ApplicationControlBar which will contain the entry-point Menu for accessing these configuration options. Therefore, whenever I add a sub-component to the main Application (via "addChild"), it will also "register" its own configuration options with the ApplicationControlBar menu. This keeps the knowledge of configurability with the containers themselves, yet allows for a more unified means of accessing them.
Thus, when I create each container, I want to instantiate them via their interface so I can guarantee they can register with the ApplicationControlBar. But when I add them to the application, they need to be the base class.
#James Ward, That's definitely something I wish was in the language, probably a interface IDisplayObject. That would solve a lot of issues in OOP display programing in AS3.
In regards the the original question, something I've used in the past, and have seen mentioned on www.as3dp.com is to include a getDisplay():DisplayObject method in the interface, which would typically return "this" by its implementor. It's less than ideal, but works.
#Matthew Flaschen, While we don't have Abstarct Classes native to AS3, common practice is to name the class with the word Abstract ie: AbstarctMyObject, and then just treat it like the abstarct objects in Java and other languages. Our want for true abstarct classes is something the Flash player team is well aware of, and we'll likly see it in the next version of the ActionScript language.
Okay, I'm anaswering generally, because you said, "Is this really just a phenomenon in Flex/AS3?".
In your init method, obviously you're always calling addChild with foo. That means foo must always be an instance of DisplayObject. You also want it to be an instance of IFooable (though it's not clear here why). Since DisplayObject is a class, you would consider using a subclass of DisplayObject (e.g. FooableDisplayObject), that implemented IFooable. In Java, this would the below. I'm not familiar with AS, but I think this shows there's not any general flaw in interfaces here.
interface IFooable
{
public void runFoo();
}
class DisplayObject
{
}
abstract class FooableDisplayObject extends DisplayObject implements IFooable
{
}
class Foo extends FooableDisplayObject
{
public void runFoo()
{
}
}
public void init()
{
FooableDisplayObject foo = new Foo();
foo.percentHeight = 100;
addChild(foo);
}
I think this is a place where Flex's/Flash's API is not correct. I think that addChild should take an interface not a class. However since that is not the case you have to cast it. Another option would be to monkey patch UIComponent so that it takes an interface or maybe add another method like addIChild(IUIComponent). But that's messy. So I recommend you file a bug.
Situation here is that it should be just the other way around for optimal practice... you shouldn't look to cast your interface to a displayobject but to have your instance already as a displayobject and then cast that to your interface to apply specific methods.
Let's say I have a baseclass Page and other subclasses Homepage, Contactpage and so on. Now you don't apply stuff to the baseclass as it's kind of abstract but you desing interfaces for your subclasses.
Let's say sub-pages implement for example an interface to deal with init, addedtostage, loader and whatever, and another one that deals with logic, and have eventually the base req to be manageble as displayobjects.
Getting to design the implementation.. one should just use an interface for specialized stuff and extend the subclass from where it mainly belongs to.. now a page has a 'base' meaning to be displayed (design wise.. the 'base'-class is a displayobject) but may require some specialization for which one builds an interface to cover that.
public class Page extends Sprite{...}
public interface IPageLoader{ function loadPage():void{}; function initPage():void{}; }
public class Homepage extends Page implements IPageLoader
{ function loadPage():void{/*do stuff*/}; function initPage():void{/*do stuff*/}; }
var currentpage:Page;
var currentpageLoader:IPageLoader;
currentpage = new Homepage;
currentpageLoader = currentpage as IPageLoader;
currentpageLoader.loadPage();
currentpageLoader.initPage();
addChild(currentpage);
Tween(currentpage, x, CENTER);