I've been using dart for quite a while now. If I want to implement dynamic getters, setters and functions for objects of a class, I can make use of the noSuchMethod-method. But what if I now want to have such a dynamic getter, setter of method on class layer? In Ruby, for example, if one wants to implement a dynamic class method, one would define the method_missing-method on the class object, like for example:
class Test
def self.method_missing
//Do some matching, return result or error
end
end
How would I achieve this in Dart?
I don't think you can do this in Dart without mirrors/reflection.
I also don't think this is very useful.
You can't call a static method on a 'dynamic' type and therefore you can't mock static methods.
If you need this you should just make it a normal method instead of a static one.
You can just override noSuchMethod as noticed here
how should the member of a QWidget-Class normally designed private or public?
class MyWidget : public QWidget {
public:
MyWidget( QWidget *parent = 0);
QLineEdit *myLine;
}
or
class MyWidget : public QWidget {
public:
MyWidget( QWidget *parent = 0);
private:
QLineEdit *myLine;
}
I prefer the second definition with the private member, but this version is bad to test because I have no access to the member with the findChild( QString ).
Other part is should a QWidget class nested other widgets? Problem is there is no direct access to the nested widgets and this isn't really usefull for automated gui tests where the mouse click should mabyee push a button or something else..
The second choice is generally regarded as the "best programming practice", and if you need to access the private members via code from somewhere else (including your test suite), then you need to implement getters and setters.
Generally, test frameworks should also be using APIs to access objects rather than directly accessing members, for it is that API that you typically want to test within unit tests. If you really can't give up the notion that the test framework should directly access the private members, then you can look into using C++ friend classes. But you didn't hear that from me.
If you need to access something generically (like by a string name), that's exactly what Qt Properties was designed to do for you. So declare your items as a property and list the getters/setters/signals/etc that way too.
Aside: Unfortunately, implementing getters and setters is somewhat boring work, which is why I ended up implementing a QtCreator plugin tool that implements getters, setters and creates signal definitions and emits the signal. If you ever need to actually do something more complex in the future, then simply remove the and replace the auto-getter/setter with your more complex definitions.
I'm trying to write a class with two basic characteristics:
It needs to be scriptable - the class contains a number of properties and methods decorated with Q_INVOKABLE that are exposed to scripts.
It needs to be serializable so that it can be registered with qRegisterMetaTypeStreamOperators() for storing in QVariants.
As far as I can tell, I need to derive from QObject in order to make the class scriptable. However, in order to register the class with qRegisterMetaTypeStreamOperators(), it seems like the class needs to have a default copy constructor - something a QObject-derived class cannot have.
Is there any way to achieve both goals?
You can have scriptable objects not derived from QObject but it's more work. It's discussed here
I've got a class called ArtificialIntelligenceBase from which you can create your own artificial intelligence configuration sending some variables to the constructor or you can make a class that inherits from ArtificialIntelligenceBase and in the constructor of this new class just call the function super() with the parameters of the configurations.
I've also created some examples of artificial intelligences in classes, AIPassive, AIAgressive and AIDefensive. Obviously all of them inherits from ArtificialIntelligenceBase.
The point is that there're only few public functions in the base class. The variables in the base class are read only and the non public functions are protected in case you need to apply some modifications on them when created another pre-defined AI.
You can also create another AI just calling the base class sending some parameters in the constructor like this: new ArtificialIntelligenceBase(param1, param2, param3, param4);
I've tought about make the classes as a singleton because the classes can never change and once setted, their variables never change.
The question is: Is the singleton the best pattern to do this? Because I'm not sure.
PD: You don't need to explain any patter, just mention the name and I'll search for how it works
PPD: I'm developing in AS3. Just in case it helps
Thanks
In general, singletons are evil. I don't see any reason in your case to use a singleton, either. It sounds like you're using your own version of a factory method pattern (using a constructor somehow?) or maybe a prototype (I don't know AS3 one bit), but if you're looking for other patterns a couple of other ones are abstract factory and builder.
You don't need to use the singleton pattern to limit yourself to using only one instance per type of class, though. It doesn't help avoid redundancy.
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);