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.
Related
We have an app that makes fairly extensive use of TIniFile. In the past we created our own descendant class, let's call it TMyIniFile, that overrides WriteString. We create one instance of this that the entire app uses. That instance is passed all around through properties and parameters, but the type of all of these is still TIniFile, since that is what it was originally. This seems to work, calling our overridden method through polymorphism, even though all the variable types are still TIniFile. This seems to be proper since we descend from TIniFile.
Now we are making some changes where we want to switch TMyIniFile to descend from TMemIniFile instead of TIniFile. Those are both descendants of TCustomIniFile. We'll also probably be overriding some more methods. I'm inclined to leave all the declarations as TIniFile even though technically our class is no longer a descendant of it, just to avoid having to change a lot of source files if I don't need to.
In every tutorial example of polymorphism, the variable is declared as the base class, and an instance is created of the descendant class and assigned to the variable of the base class. So I assume this is the "right" way to do it. What I'm looking at doing now will end up having the variables declared as, what I guess you'd call a "sibling" class, so this "seems wrong". Is this a bad thing to do? Am I asking for trouble, or does polymorphism actually allow for this sort of thing?
TIniFile and TMemIniFile are distinct classes that do not derive from each other, so you simply cannot create a TMemIniFile object and assign it to a TIniFile variable, and vice versa. The compiler won't let you do that. And using a type-cast to force it will be dangerous.
You will just have to update the rest of your code to change all of the TIniFile declarations to TCustomIniFile instead, which is the common ancestor for both classes. That is the "correct" thing to do.
The compiler is your friend - why would you lie to it by using the wrong type ... and if you do lie to it why would you expect it to know what you want it to do?
You should use a base class that you derive from, like TCustomIniFile. I would expect compile issues if you are trying to make assignments which are known at compile time to be wrong.
The different classes have different signatures so the compiler needs to know which class it is using to call the correct method or access the correct property. With virtual methods the different classes setup their own implementation of those methods so that the correct one is called - so using a pointer to a base type when you call the virtual method it calls that method in the derived type because it is in the class vtable.
So if the code does compile, it's very likely that the compiler will not be doing the right thing ...
Suppose I want my class to do things on attribute access. I can of course do that in setters and getters:
class Foo {
set bar (v) {
// do stuff
}
}
However, if I want to attach the same behavior to multiple attributes, I'd have to explicitly define the same setters and getters for every one of them. (The use case I have in mind is an observable, i.e. a class that knows when its attributes are being changed).
What I'd like to do is something like:
class Foo {
var bar = new AttributeWithAccessBehavior();
}
Python does this with descriptors - what is the closest thing in Dart?
AFAIK there isn't anything with getter/setter syntax that you can reuse.
You could assign a function to a field, that you can access using call notation (), but you have to be careful to call the function instead of overriding the field assignment.
A similar but more powerful alternative are classes that can emulate functions (see https://www.dartlang.org/articles/emulating-functions/)
A class that has a call method can be used like a method.
This is similar to assigned functions mentioned above but in addition you can store state information.
If you implement actual getter/setter you can of course delegate to whatever you want, but that is obviously not what you are looking for.
For the use case you mentioned, there is the observe package.
I have no idea how exactly it solves the problem, but it works quite well.
Hi I'm developing a TControl descendant, lets name it THTMLBaseControl, at runtime that control only generates and output HTML code based on the settings of that control, so all the additional properties of the base TControl class and methods, including Windows Messaging system is really not used at runtime and causes memory overhead.
I need that control to be inherited from TControl so at design time I can use all the IDE designer stuff.
But at runtime almost all of those properties that at desingtime are needed i dont need them.
I also have all my controls inherited from that THTMLBaseControl, so creating a wrapper class per control class is not an option because it will duplicate the code a lot.
So what i need is something that at runtime, before the class is instantiated I can change the parent class so it will be instantiated based on another TControl-like class, maybe named TmyBaseControl inherited from "TComponent" as TControl Does, but that will not have all that TControl memory overhead and will only have the properties and methods needed by my THTMLBaseControl.
I really dont have a GUI at rutime is a web server that will serve only HTML, is some thing that intraweb and Raudus do, but always the issue is that all are based on TControl, so they have to be created at run time and generate a lot memory and process overhead that is not used. and maybe there could a solution so any THTMlBaseControl descendant instantiated at runtime will inherit the all properties and methods from TmyBaseControl and not from TControl.
I have seen there are ways to hack the VMT but maybe there are other solution and have not seen it. I already done changing the NewInstance, ClassParent and TnstanceSize class methods but i have to specify from which class and obviously i have to do the same steps per each inherited THTMLBaseControl class
And for the sake of all:
This is just a doubt, I need the components to be controls like TEdit, TPanel, visible and editable by the designer IDE I even could create my own TControl class but I was just thinking if I can reuse the code already existing.
Regards
You cannot change the class a run time. Once an object is instantiated, its class is fixed. You could hack the object to change its VMT pointer, making it refer to a different class, but that would still not address your main concern, which is memory usage — even if you change the VMT pointer, all the memory for the object has already been allocated; changing the VMT pointer doesn't magically make the object occupy less memory.
The first thing you could do is stop descending from TControl. As you've noted, you don't need any of the things it provides. All you want is something you can drop on a form at design time to set its properties. For that, all you need is TComponent, so make that your base class instead of TControl. Then you'll get something more like TTimer, which has no GUI. Once you've done that, you no longer need TForm, either. Instead, you can put your component on a TDataModule, which is specifically designed for managing non-visual components at design time.
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.
To avoid singletons and global variables I'd like to be able to pass parameters to a TFrame component. However since a TFrame normally is included on form at design time it is only possible to use the default constructor.
The parent form can of course set some properties in the OnCreate callback after the TFrame has been created. However this does not ensure that a property is not forgotten, and the dependencies are not as clear as using a constructor.
A nice way would be if it was possible to register a factory for creating components while the dfm file is being read. Then the required parameters could be passed to the TFrame constructor when created by the factory. Is there a way of accomplishing this?
Or does anyone have a better solution on how to pass parameters to a TFrame?
All components, including descendants of TFrame, need to be able to be constructed using the constructor inherited from TComponent. Otherwise, they can't be used properly at design time. If the restriction of design-time use is acceptable to you, then you could override that constructor and raise an exception. That would prevent the component from being placed on a form at design time. Simply provide some other constructor that requires other parameters.
Because of the design-time requirement, all components need to be able to exist with some or all of their properties still at their default values. That doesn't mean the components have to do useful things while they're in that state, but they do need to be able to stay in that state indefinitely. It should be OK, for example, to place a component on a form, save the form, and close Delphi, with the intention of resuming the form-designing at a later time. The component should allow itself to be saved and restored, even if all its properties haven't been set up for final use yet.
My preferred option is to enforce the component's rules only at run time. Check that all the properties are set to sensible values before you allow them to be used. You can use assertions to enforce the proper use of your components. Consumers of your classes will learn very quickly if they haven't finished setting up your components on their forms.
I would normally add a public, non-virtual "Initialise" or (Initialize to Americans) procedure which requires all parameters to be provided. This will then set the properties.
Make the properties protected or private if possible, so the only way they can be set is from calling Initialise(AFoo, ABar : integer).
Then in TFormXXX.FormCreate or TformXXX.Create, have:
inherited;
Initialise(foo, bar);
could you create/registercomponent your own tFrame component and
place that on the form - it's create could have anything passed to it.
If a factory could provide the parameters that you need, why don't you just override the default constructor for your frame, and ask the factory-class for parameters?
I usually make my own constructor. I don't like to create frames at designtime anyway.
a) a frame can be created dynamically when required and destroyed when not needed
b) give the frame a public property with either the parameter data type or a data structure and pass the values to the form through the property.
Example:
TAddress - a class to hold the usual elements of an address.
TAddressFra - a frame with the visual controls to display the address
populate an instance of TAddress with values
create an instance of TAddressFra
assign the TAddressFra.address property with the TAddress instance
use the procedure setAddress(o_address : TAddress) to assign the values of the TAddress attributes to the corresponding visual components on the TAddressFra