What happens to a procedure when it is declared with the keyword dynamic?
And what is the effect of declaring it with the keyword static?
This question can be answered by reading the documentation.
The dynamic keyword introduces a method that can be overridden polymorphically. Semantically it is interchangeable with virtual, but the is implemented in a different manner. Read about it here: http://docwiki.embarcadero.com/RADStudio/en/Methods#Virtual_and_Dynamic_Methods
To make a method virtual or dynamic, include the virtual or dynamic
directive in its declaration. Virtual and dynamic methods, unlike
static methods, can be overridden in descendent classes. When an
overridden method is called, the actual (run-time) type of the class
or object used in the method call--not the declared type of the
variable--determines which implementation to activate.
To override a method, redeclare it with the override directive. An
override declaration must match the ancestor declaration in the order
and type of its parameters and in its result type (if any).
...
In Delphi for Win32, virtual and dynamic methods are semantically
equivalent. However, they differ in the implementation of method-call
dispatching at run time: virtual methods optimize for speed, while
dynamic methods optimize for code size.
In general, virtual methods are the most efficient way to implement
polymorphic behavior. Dynamic methods are useful when a base class
declares many overridable methods that are inherited by many
descendent classes in an application, but only occasionally
overridden.
Class static methods are like class methods in that they are invoked on the class rather than an instance. The difference between class static and class methods is that class methods are passed a Self pointer that contains the class, and class static methods are not. This means that class methods can be polymorphic and class static methods cannot. Read about it here: http://docwiki.embarcadero.com/RADStudio/en/Methods#Class_Static_Methods
Like class methods, class static methods can be accessed without an object reference. Unlike ordinary class methods, class static methods have no Self parameter at all. They also cannot access any instance members. (They still have access to class fields, class properties, and class methods.) Also unlike class methods, class static methods cannot be declared virtual.
With all due respect, I refer you to this question: How can I search for Delphi documentation?
Related
I couldn't understand the difference between these two keywords.
By using extends we can get features from parent class. I think implements does that too.
First I thought the difference is overriding methods but with extends I can do that.(I might be wrong)
Is the difference of these two keywords about overriding methods or what? Thank you
extends means we get the implementation of a given class and we can then override members if we want our own implementation for certain variables or methods. You can also add new variables and methods.
implements means you get nothing from the class you implement from. But you promise that your class will be compatible with the interface of the class you are implementing. So no, you are not getting any implementation from the super class and you need to implement everything or declare your class abstract.
I was learning dart but it was still an error when I entered into the mixin, I don't know the fault where it is always an error when:
Abstract classes cannot be instantiated
I want to implement a mixin for Cat, Elang and Hiu with a subclass of Mamalia, Burung, Ikan
This is the Github code:
The error are rather clear. You cannot make an instance of an abstract class since an abstract class per definition is a class which can define methods and fields which are yet to be implemented and the class is therefore not complete.
The purpose of abstract classes is to let other classes extend from them and implement the missing methods.
I don't know why all your classes are marked as abstract but you can just remove the abstract keyword from the classes: Mamalia, Ikan and Burung and it should work since all of these classes are not needed to be abstract.
Abstract Class -
Use the abstract modifier to define an abstract class—a class that can’t be instantiated. Abstract classes are useful for defining interfaces, often with some implementation.
Don't instantiate Mamalia, Burung or Ikan classes. Instead instantiate Cat, Elang and Hiu.
Mamlia mamal = Cat(); // Will allow accessing methods defined only in Mamal class
Cat cat = Cat() // Will allow accessing all the methods defined in Cat class
When a class that contains code is instantiated, is the code is the class shared automatically by other instantiations of that same class? Eg. The data in the class that is instantiated may be minimal; however the code could be very significant. If the code is not "automatically" shared, is there a way to achieve that other than separating the code from the class data?
Sure.
Classes have the state and the behavior.
The state is encoded in member variables of the class. Each instance has its own copy of variables, thus its own state.
The behavior is specified by the methods implemented in the class ('methods' here stand for all static, non-static methods, setters and getters). Implementation is shared by all instances of the class, so all instances behave the same, but actual results and side-effects depend on instance state, obviously.
At my workplace, we have some code where class functions refer to Self, effectively creating a potential access violation, should the object not be initialised. Does the meaning of Self change in a class method as to refer the class rather than the object?
I assume the only reason this is working is because the Self refers to another class function and not a regular method.
I created the following test class:
constructor TTest.Create;
begin
FTest := 'Hej';
end;
procedure TTest.GoTest;
begin
ShowMessage(FTest);
end;
class procedure TTest.Test;
begin
Self.GoTest;
end;
However, compiling this throws an error:
[dcc32 Error] Unit1.pas(51): E2076 This form of method call only allowed for class methods or constructor
I also testing referring to FTest directly, which gave another error:
[dcc32 Error] Unit1.pas(51): E2124 Instance member 'FTest' inaccessible here
But I wonder, however, whether it is possible to have a case where Self is potentially dangerous in class methods.
I know, that referring to global objects and assume they are there is always bad.
Does the meaning of Self change in a class method as to refer the class rather than the object?
In a class method Self refers to the class. The documentation says:
In the defining declaration of a class method, the identifier Self represents the class where the method is called (which can be a descendant of the class in which it is defined.) If the method is called in the class C, then Self is of the type class of C. Thus you cannot use Self to access instance fields, instance properties, and normal (object) methods. You can use Self to call constructors and other class methods, or to access class properties and class fields.
A class method can be called through a class reference or an object reference. When it is called through an object reference, the class of the object becomes the value of Self.
The compiler won't object to you using Self since it is a legal and supported thing to do. It just complains when you try to use instance members, instance methods etc.
Self has this meaning in class methods for exactly the same reason it exists in instance methods. It allows you to fully specify a symbol and thus avoid scoping ambiguity. What's more it allows you to access the actual class on which the method is called. This may be a descendant of the class in which the method is defined.
I wonder, however, whether it is possible to have a case where Self is potentially dangerous in class methods.
I don't see any particular danger inherent in this part of the language. In fact the use of Self reduces scope and so reduces the danger of inadvertently referring to a local variable rather than a class member.
I played with attributes and assumed that they are inherited but it doesn't seem so:
type
[MyAttribute]
TClass1 = class
end;
TClass2 = class(TClass1)
end;
TClass2 doesn't have the Attribute "MyAttribute" although it inherits from Class1. Is there any possibility to make an attribute inheritable? Or do I have to go up the class hierarchy and search for attributes?
An attribute is a decoration for a class or other symbol, such as a method. An attribute decorates the declaration, but is not a feature of the class. As a result, an attribute is not inherited.
Yes, you could go up the class hierarchy to look for the attribute, but there is a better solution. Use an empty interface ( IMyInterface = Interface) as a "marker" interface. All descendants of an interface-implementing class will also be implementers of that interface. All you need to ensure is that your base class implements IInterface, which will already be the case if your base class descends from TInterfacedObject or TComponent.
Once you've done this, you can use the Supports function to test if the class, or one of its ancestors, implements the interface.
I never used attributes in Delphi - so this answer is kind of speculation. But I know about annotations in Java which is basically the same thing.
But it makes sense if they are not inherited: a subclass might require other attributes, or contradict attributes from a super class. Also, if attributes are not inherited you have a chance to follow the hierarchy if "your" attribute usecase needs that. If they were inherited you would have trouble to detect whether an attribute is actually on a particular class as opposed to any of its superclasses.
If you need inheritance and don't want to look at super classes it might make more sense to use a class function, or class property, or even a tag interface (declares no methods) instead. Those are inherited.