I'm a little bit frustrated :'( , I can't access to a Kotlin's companion object method for create a component that has not visible constructors. The binding library generates a Component.Companion with the Make() method for create the component, but the Component class has not a instance of it, the Companion has not a visible contructor too and the Make() method is not static.
So, what would be the correct solution for that specific problem? I will be eternally grateful if you find the answer that rescues my end-of-grade work. o:)
Related
In object-oriented languages like C++ you don't have to call the base constructor. I don't understand why I need to do it in a psuedo object-oriented language like javascript. My base constructor has virtual elements that need to be setup before I call it. Constructors worked fine in ES5, why ruin them with this restriction. This error is garbage, it should be removed.
In C++ the compiler creates code to call the base constructor for you before your derived class constructor is called. Your C++ derived class definition can specify which base constructor to call and what to pass it (if there is a choice).
That's how the C++ specification is written. See short explanation here.
Javascript ES6 classes do not work the exact same way. You have to insert a place in your code where the base constructor is called with super(...) and you can specify or compute the parameters to pass to the base constructor.
In both C++ and Javascript, you can't access your own instance methods or properties before the base constructor has been called.
FYI, Java is even more restrictive than Javascript. You must put a call to super() or this() as the first statement of your constructor. Javascript at least lets you put logic that doesn't use this before calling the constructor.
In your Javascript, you can't stop this error without rewriting your code to work a different way. It's not an error you can disable.
There are valid OOP reasons (whether you agree with them or not) to not allow references to an object until all base classes have been fully initialized. Or, you can go back to the pre-ES6 way of initializing objects where there are no controls on how you do things and you can do whatever you want.
If you show us your code and explain what you're trying to do, we can likely suggest a different design that solves your problem and does not have this issue.
In my Lazarus project, I use variables of
TPortableNetworkGraphic type, which is inherited from TRasterImage. Until now, I have released them with the Free method, but I have noticed that for these types also a FreeImage method exists.
What is the difference between these two? Which one should I use, or should they be called both?
If we investigate the methods we find the following:
Method Free originates from TObject. Calling it destroys your class instance.
Method FreeImage comes from TRasterImage and is equal to SetHandle(0) method from the same class. The latter technically deals mainly with FSharedImagevariable (TSharedRasterImage class instance) and its Handle property. In other words after calling FreeImage the instance of TPortableNetworkGraphic class instance will be still "alive".
Please don't close as duplicate. I know there are multiple threads on this topic but none of them answers my question.
I am still struggling to understand why do we need Cloneable interface in java. If we want to create copy of an object, we can simply override clone method from Object class and call super.clone().
Since clone method in Object class is native, we don't know if the native implementation checks for instanceOf Cloneable and then create a copy else throw CloneNotSupportedException.
I know it's not a good practice to override clone() method to create a copy and should go for copy constructor instead, but still I want to know is the existence of Cloneable marker interface justified.
Whether an object implements Cloneable or not only matters if the built-in Object.clone() method is called (probably by some method in your class that calls super.clone()). If the built-in Object.clone() method is called, and the object does not implement Cloneable, it throws a CloneNotSupportedException. You say "we don't know" whether the Object.clone() method does that -- we do -- the documentation for Object.clone() method in the Java class library explicitly promises it, and it describes in detail the cloning operation that the method performs.
If you implement a cloning method that does not call up to Object.clone(), then whether the object implements Cloneable or not has no effect.
I've looked through the other questions and am still struggling so if anybody could take the time to look at this, it would be much appreciated :).
I currently have my app working fine but I've been reading and have decided it doesn't fit the MVC design pattern. I am still learning lots about design and would like to edit it so that it is more sound.
I think I know what should go in to my model class, and I think that it should be instantiated in the app delegate. My questions are: why in that location? Is lazy instantiation the best/correct way to do this? And finally, once initiated, do I use a property to access the class or do you use special methods?
Sorry for the overload; I am also trying to get my reputation up enough to vote on other questions! :)
It's really hard to answer a general question like this, since there are so many ways one could implement any particular project. In general, I don't think that instantiating a model class in your app delegate is necessarily the way to go. Since a controller class mediates between the model and the view, it's often better to instantiate your model in a controller class -- for instance, I have a program that keeps track of the plants in my garden, and my controller class is a subclass of NSArrayController. It seems to make sense to create new plant objects in the controller and then just add them to its arrangedObjects. I try to have as few connections (via properties or ivars) between classes as I can, the thought being that each class should take care of its own business as much as possible. Often, you don't need to have a reference to the class, because you are calling class methods to create new objects, and then those objects can access any instance methods of that class without any explicit reference to the class.
I got answer about Foundation magic for this question: What's the most *simple* way to implement a plain data object which conforms key-value-observing?
What's the magic? How it work internally? Because it's dangerous using framework which I can't understand its internal behavior, I want to know its behavior. Currently, I cannot understand how it work without any method definitions.
Apple's documentation describes how KVO is implemented internally.
The gist of it is that when you register an observer on an object, the framework dynamically creates a subclass of the object's original class, and adjusts the object to appear as an instance of this new dynamic class. You can see this if you inspect an object in the debugger after it has had an observer registered.
This new class intercepts messages to the object and inspects them for those matching certain patterns (such as the getters, setters, and collection access).
In a nutshell: Objective-C 2.0's #property declaration creates accessor methods for the named property, so there are method definitions. #property is just a shorthand way to define them which avoids a lot of repetitious boilerplate code.
When you observe a property, a private subclass is created which implements accessors that call the appropriate notification methods before and after changing the property value. A technique known as "isa swizzling" is then used to change the class of the observed object.