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.
Related
When I inherit from GTK widget, I want to override inherited property, so that the normal operation will not be affected.
However I could not find any material or tutorials describing it.
Since properties are inherited from parent classes, you normally don't have to do anything for them to continue to work.
I assume you want to somehow modify the getters / setters. If not, please clarify your question.
If you can modify the parent class:
Just create explicit virtual getter and/or setter methods that have (at least) protected visibility level.
With implicit getters and setters valac will create methods for you, but they won't be virtual.
You can then use normal method overriding and base class calling semantics to adjust the parents property.
If you can not modify the parent class:
One thing you can still do is to register a handler for the notify signal to react on the setter being called.
Or you may be in luck and the parent class comes with some facility to modify its behaviour.
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?
So I just joined this forum because I could not find an answer to my simple question.
I want to declare a read-only property, and it should read from a private members read-only property. It seems like that won't work. Can I work myself around that blockade?
Here is the code snippet:
property Mine: TMineType read mMine.MineType;
Edit: Maybe I should clarify. mMine is of class TMine, which has a property MineType. MineType is of type TMineType and is read-only.
A property getter can be one of two things:
A field, or
A function.
Your code attempts to implement the getter with a property, and that does not meet the requirement stated above.
The documentation contains all the details: http://docwiki.embarcadero.com/RADStudio/en/Properties
On a practical level, you could do something like this:
function GetMineType : TMineType;
begin
result := mMine.MineType;
end;
property Mine: TMineType read GetMineType;
If you declare the GetMineType function as inline it will not generate any code.
Based on your additional information that you provided in your comments (such information should be put into the original question itself right from the start) I believe I can provide an answer which would hopefully provide solution to the problem you are facing.
In the code bellow I'm showing of how you can make parent class property accessible through descendant class by using property forwarding or property publishing.
//Base class we use
TBaseClass = class(TObject)
//Private section. Methods, fields and properties declared here are only visible from within classes declared in same unit
//but not from classes or method declared in other units.
private
FPrivateField: Integer;
function GetPrivateField: Integer;
procedure SetPrivateField(AValue: Integer);
//This property is making use of getter and setter methods in order to access FPrivateField
property PrivateFieldProperty: Integer read GetPrivateField write SetPrivateField;
//Strict private section. Methods, fields and properties declared here are only visible from descendant classes and their
//methods but not from other classes and their methods even if they are declared in the same unit.
strict private
FStrictPrivateField: Integer;
function GetStrictPrivateField: Integer;
procedure SetStrictPrivateField(AValue: Integer);
//Public section. Methods, Field and properties declared here are visible from any other class or methods regardless of
//where they are declared
public
//This property is accessing its field directly
property DirectPrivateFieldProperty: Integer read FPrivateField write FPrivateField;
//This property is making use of getter and setter methods in order to access FStrictPrivateField
property StrictPrivateFieldProperty: Integer read GetStrictPrivateField write SetStrictPrivateField;
end;
//Sub class is actually a descendant class from our base class
TSubClass = class(TBaseClass)
public
//If your parent class already has declared certain property and you want to use that property in your descendant
//class you can use so called "property forwarding" approach where you only specify the parents property name that
//you want to make available to your descendant class. This approach only allows accessing fields that are declared
//in parents class.
//If you need to access field declared in descendant class then its property must directly access that field or use
//getter and/or setter methods declared in descendant class. Such approach is called property overloading.
property DirectPrivateFieldProperty;
property PrivateFieldProperty;
//If you want to limit the access level of a descendants class property (making it read only) you need to follow standard
//property declaration guideline where you declare property type and the field to which it is accessing either directly or
//by using getter or setter methods
property ReadOnlyPrivateFieldProperty1: Integer read FPrivateField;
property ReadOnlyPrivatefieldProperty2: Integer read GetPrivateField;
//You can also declare forwarded descendant class property with different visibility of the one declared in parent class.
//Such approach is usually referred as property publishing.
property StrictPrivateFieldProperty;
end;
Note the above approaches only work when accessing properties or fields of a parent class from a descendant class but not for accessing fields or properties of other classes.
The reason for this is that property may only directly access fields of its own class or any parent classes.
Also property can only use getter and setter methods that are declared either in its own class or in any of the parent classes.
I hope this answer of mine might give you better idea about working with properties.
Now at the moment I guess properties might look a bit confusing to you but believe me when you will learn to work with them you will realize of how powerful they can actually be. I must admit that I'm still finding out new ways to use them in my projects every now and then.
Let's say I have two classes in Unit1: TParent = class(TCustomControl) and TDescendant = class(TParent) and they both have a lot of methods, fields and properties.
In Unit2 I need to modify TParent. Let's say I only need to modify a single method, Method1, in a very simple way that doesn't really affect anything outside itself (say, print a text in red color instead of black). I also need TDescendant to be affected by this modification (so every time it calls Method1 the modified Method1 is executed).
Is there a way to do that in Delphi 7, without modifying Unit1 and without copying the entire TDescendant class into Unit2?
On top of that I really need the class names to remain the same (I'm simply trying to modify a method in a 3rd party control without creating a whole new control to do it).
I made an interceptor class of TParent in Unit2, but I don't know how (if at all possible) to "tell" TDescendant to become a descendant of the interceptor class instead of the original.
As far as I know this is not possible without some serious low level hacks (pointer/memory based). Therefor I would not suggest is at all... (also I don't know the actual answer to that solution).
When you only want to add some extra methods to the TParent class, you can use helper classes (Delphi XE+ - maybe even earlier versions).
Ex.
TParentHelper = class helper for TParent
public
procedure MyMethod(param: string);
end;
Now you can dos stuff like:
uses
MyParentHelperU;
Procedure test(D: TDescendant);
begin
D.MyMethod('test');
end;
Notes:
you need to include the unit in which the helper class in defined, in order to use this functionality.
You can only add methods to the class (and descendants), for which the helper class has been assigned. You cannot add properties or fields.
Protected properties can be accessed by the helperclass, but are not always shown by the IDE
I've read the official documentation and I understand what class references are but I fail to see when and why they are best solution compared to alternatives.
The example cited in the documentation is TCollection which can be instantiated with any descendant of TCollectionItem. The justification for using a class reference is that it allows you to invoke class methods whose type is unknown at compile time (I assume this is the compile time of TCollection). I'm just not seeing how using TCollectionItemClass as an argument is superior to using TCollectionItem. TCollection would still be able to hold any descendant of TCollectionItem and still be able to invoke any method declared in TCollectionItem. Wouldn't it?
Compare this with a generic collection. TObjectList appears to offer much the same functionality as TCollection with the added benefit of type safety. You are freed from the requirement to inherit from TCollectionItem in order to store your object type and you can make a collection as type specific as you want. And if you need to access item's members from within the collection you can use generic constraints. Other than the fact that class references are available to programmers prior to Delphi 2009 is there any other compelling reason to use them over generic containers?
The other example given in the documentation is passing a class reference to a function that acts as an object factory. In this case a factory for creating objects of type TControl. Its not really apparent but I'm assuming the TControl factory is invoking the constructor of the descendant type passed to it rather than the constructor of TControl. If this is the case then I'm starting to see at least some reason for using class references.
So I guess what I'm really trying to understand is when and where class references are most appropriate and what do they buy a developer?
MetaClasses and "class procedures"
MetaClasses are all about "class procedures". Starting with a basic class:
type
TAlgorithm = class
public
class procedure DoSomething;virtual;
end;
Because DoSomething is a class procedure we can call it without an instance of TAlgorithm (it behaves like any other global procedure). We can do this:
TAlgorithm.DoSomething; // this is perfectly valid and doesn't require an instance of TAlgorithm
Once we've got this setup we might create some alternative algorithms, all sharing some bits and pieces of the base algorithm. Like this:
type
TAlgorithm = class
protected
class procedure DoSomethingThatAllDescendentsNeedToDo;
public
class procedure DoSomething;virtual;
end;
TAlgorithmA = class(TAlgorithm)
public
class procedure DoSomething;override;
end;
TAlgorithmB = class(TAlgorithm)
public
class procedure DoSomething;override;
end;
We've now got one base class and two descendent classes. The following code is perfectly valid because we declared the methods as "class" methods:
TAlgorithm.DoSomething;
TAlgorithmA.DoSomething;
TAlgorithmB.DoSomething;
Let's introduce the class of type:
type
TAlgorithmClass = class of TAlgorithm;
procedure Test;
var X:TAlgorithmClass; // This holds a reference to the CLASS, not a instance of the CLASS!
begin
X := TAlgorithm; // Valid because TAlgorithmClass is supposed to be a "class of TAlgorithm"
X := TAlgorithmA; // Also valid because TAlgorithmA is an TAlgorithm!
X := TAlgorithmB;
end;
TAlgorithmClass is a data type that can be used like any other data type, it can be stored in a variable, passed as a parameter to a function. In other words we can do this:
procedure CrunchSomeData(Algo:TAlgorithmClass);
begin
Algo.DoSomething;
end;
CrunchSomeData(TAlgorithmA);
In this example the procedure CrunchSomeData can use any variation of the algorithm as long as it's an descendant of TAlgorithm.
Here's an example of how this behavior may be used in a real-world application: Imagine a payroll-type application, where some numbers need to be calculated according to an algorithm that's defined by Law. It's conceivable this algorithm will change in time, because the Law is some times changed. Our application needs to calculate salaries for both the current year (using the up-to-date calculator) and for other years, using older versions of the algorithm. Here's how things might look like:
// Algorithm definition
TTaxDeductionCalculator = class
public
class function ComputeTaxDeduction(Something, SomeOtherThing, ThisOtherThing):Currency;virtual;
end;
// Algorithm "factory"
function GetTaxDeductionCalculator(Year:Integer):TTaxDeductionCalculator;
begin
case Year of
2001: Result := TTaxDeductionCalculator_2001;
2006: Result := TTaxDeductionCalculator_2006;
else Result := TTaxDeductionCalculator_2010;
end;
end;
// And we'd use it from some other complex algorithm
procedure Compute;
begin
Taxes := (NetSalary - GetTaxDeductionCalculator(Year).ComputeTaxDeduction(...)) * 0.16;
end;
Virtual Constructors
A Delphi Constructor works just like a "class function"; If we have a metaclass, and the metaclass knows about an virtual constructor, we're able to create instances of descendant types. This is used by TCollection's IDE Editor to create new items when you hit the "Add" button. All TCollection needs to get this working is a MetaClass for a TCollectionItem.
Yes a Collection would still be able to hold any descendant of TCollectionItem and to invoke methods on it. BUT, it wouldn't be able to instantiate a new instance of any descendant of a TCollectionItem. Calling TCollectionItem.Create constructs an instance of TCollectionItem, whereas
private
FItemClass: TCollectionItemClass;
...
function AddItem: TCollectionItem;
begin
Result := FItemClass.Create;
end;
would construct an instance of whatever class of TCollectionItem descendant is held in FItemClass.
I haven't done much with generic containers, but I think that given a choice, I would opt for the generic container. But in either case I'd still have to use a metaclass if I wanted to have the list instantiate and do whatever else needs to be done when an item is added in the container and I do not know the exact class beforehand.
For example an observable TObjectList descendant (or generic container) could have something like:
function AddItem(aClass: TItemClass): TItem;
begin
Result := Add(aClass.Create);
FObservers.Notify(Result, cnNew);
...
end;
I guess in short the advantage/benefit of metaclasses is any method/class having only knowledge of
type
TMyThing = class(TObject)
end;
TMyThingClass = class of TMyThing;
is able to construct instances of any descendant of TMyThing whereever they may have been declared.
Generics are very useful, and I agree that TObjectList<T> is (usually) more useful than TCollection. But class references are more useful for different scenarios. They're really part of a different paradigm. For example, class references can be useful when you have a virtual method that needs to be overridden. Virtual method overrides have to have the same signature as the original, so the Generics paradigm doesn't apply here.
One place where class references are used heavily is in form streaming. View a DFM as text sometime, and you'll see that every object is referred to by name and class. (And the name is optional, actually.) When the form reader reads the first line of an object definition, it gets the name of the class. It looks it up in a lookup table and retrieves a class reference, and uses that class reference to call that class's override of TComponent.Create(AOwner: TComponent) so it can instantiate the right kind of object, and then it starts applying the properties described in the DFM. This is the sort of thing that class references buy you, and it can't be done with generics.
I also would use a metaclass whenever I need to be able to make a factory that can construct not only one hard-coded class, but any class that inherits from my base class.
Metaclasses are not the term I am familiar with in Delphi circles however. I believe we call them class references, which has a less "magic" sounding name, so it's great that you put both common monikers in your question.
A concrete example of a place I have seen this used well is in the JVCL JvDocking components where a "docking style" component provides metaclass information to the base docking component set, so that when a user drags their mouse and docks a client form to the docking host form, the "tab host" and "conjoin host" forms that show grabber bars (similar in appearance to the title bar of a regular undocked window) can be of a user-defined plug-in class, that provides a customized appearance and customized runtime functionality, on a plug-in basis.
In some of my applications I have a mechanism that connects classes to forms capable of editing instances of one or more of that classes. I have a central list where those pairs are stored: a class refernce and a form class reference. Thus when I have an instance of a class I can lookup the corresponding form class, create a form from it and let it edit the instance.
Of course this could also be implemented by having a class method returning the appropriate form class, but that would require the form class to be known by the class. My approach makes a more modular system. The form must be aware of the class, but not the other way round. This can be a key point when you cannot change the classes.