Is there a way to override a property getter or setter?

Is there any way to override the GET / SET accessor of a parent property in a

sub-class?

No. The only case where this is true is if the property is defined as ABSTRACT.

-- peter

Thanks.  I just saw that this question has also already been answered in another post.

If anyone is interested, I created enhancement request 0000004079.

Note that the property getter/setter can reference another method and that method could be overridable.

Indeed, but that method - if it exists (like events published when this property change: sometimes there are, but most of the time, there aren't) - is hard to find when you don't have the source code of the control you are sub-classing and when 4GLTrace doesn't log pure .NET to .NET method invocations (contrarily, for example, as what we had with ADM2 where you could either look directly at the ADM2 source code to see what this "setQueryWhere" procedure was in turn calling or simply by turning on 4GLTrace logging just prior to your "setQueryWhere", turn logging off right after your call and see all that is called when "setQueryWhere" is called.  You could then try to figure out an appropriate place to put your customization.).

Obviously, this approach does you no good at all unless you have the source for the parent.  I was just pointing out that, if you are the one writng the parent, this is a way to make the behavoir overridable.

If one steps back from the "can I" to the "should I", it seems like the idea of overriding a non-abstract property is a bit questionable to start with.  Properties are fundamental knowledge attributes of an object.  The fact that they have getter and setter aspects derives from:

1. It is a shortcut for writing explicit getter and setter methods, particularly in the trivial case where a value is simply returned or set.

2. It provides the needed controls for read only and write only attributes.

3. It provides a simple mechanism for derived attributes.

Really, only in this last case is there any code to be overriden and if that code is changing what the meaning of the property is, then I would question the object decomposition.

Even simpler than calling than having the property call a protected method would be to use a private variable and define your own getter and setter methods, which, of course, would be overrideable.

But, if you are not the author of the parent and you have no source, then I guess one could say that the author didn't intend to let you override that property.  So, better would be to expose a new property, i.e., an attribute with a different meaning and put your variant code under that.

The problem is that properties are sometimes objects and not just plain data, so they become more than "fundamental knowledge attributes" as they are used to provide functionality to the parent object, functionality that we'd like to customize.  The logic of these objects could very well reside directly in the parent (where we could customize the methods as much as we like in a sub-class), but due to good application modeling and all those good principles, their logic has been factored and encapsulated in a different class to which the parent delegates some tasks, but then, if the parent is the instanciator of the object property, we can no longer customize / enhance / specialize the logic.

From my enhancement request:

"E.g. you inherit control A, control A has an  property B of object type C that it instantiates at run time.  You would  like to sub-class type C to customize its behavior so that it becomes  type C+.  Although you can very well do this sub-classing, there is  currently no way that you can override the setting of property B so that  it becomes an object of type C+.

Infragistics controls expose  directly only a low percentage of all the methods that affect the  behavior of these controls, the other methods are on internal objects,  many of which are instantiated by the control itself.  In order to  override many of these other methods so that they will be used by the  inherited control, we'd need the current enhancement request."

Point being, though, that if you have control of the parent object, there ae multiple ways to accomplish what you want.  Your problem is that you are trying to do this with an object which you do not control.

So, one question I would ask is, can one do what you want in other OO languages?  Specifically, if you were writing in .NET, could you override that same property in the Infragystics control that you are wanting to override?

If the answer is no, then I would think it would actually be wrong for PSC to allow you to do so because they would then be allowing you to violate the design of the author.

If the answer is yes, then I would think you had a reasonable request because PSC was not allowing you to do something which a ..NET developer would be able to do with the same control.

I just looked and here is what I found: The following page shows that you can do it in .NET:

http://msdn.microsoft.com/en-us/library/818x9db9%28VS.80%29.aspx

It's interresting to see that they see the same usage that I would like :

"Use the Overrides keyword to shadow the member by redefining  it in the derived class. This is useful when you cannot use the member  "as is."

In practice, overridden members are often used to  implement polymorphism."

This one is an example for Infragistics controls:

http://forums.infragistics.com/forums/p/12376/46365.aspx

The .NET property needs to be defined as Overridable and looking at the  Infragistics documentation, I see that some properties are indeed overridable (for some objects, many are), the only sad thing is that they aren't all (Microsoft documentation says that the default is "NotOverridable", so a developer has to explicitely turn on this option).

Based on the fact that you can do it in .NET, I would say that you have some justification for thinking that you should be able to do it in ABL ... I only wish that they would see this point relative to implementing multi-threading!

But, let's also look at this with some caution.  That MSDN entry says:

The following rules apply to overriding methods.

• You can only override members that are marked with the Overridable keyword in their base class.

• Properties and methods are NotOverridable by default.

• Overridden members must have the same arguments as the inherited members from the base class.

• The new implementation of a member can call the original implementation in the parent class by specifying MyBase before the method name.

So, first question.  Is the property you are interested in overriding, the one that stimulated this post, marked as overridable?  If not, you are out of luck.

I think that it is worth noting that the default is NotOverridable and the author of the superclass has to have explicitly given you "permission" to do the override.

Your Infragystics example seemed to me to be a sideways solution, not directly overriding the original property.

The override can't change the signature, so if, in your example, the signature was to return C, could you actually modify it to return C+?

Note that there is a school of thought which thinks that overriding methods of superclasses is anathema.  That might seem strange, but if you think about each class having its own clear responsiblity, shouldn't a responsibility in a subclass be a different responsibility rather than a change to the responsiblity of the parent?

The override can't change the signature, so if, in your example, the signature was to return C, could you actually modify it to return C+?

I would still return it as an object of type C because C+ inherits from C.

It's just that by polymorphism, although all existing logic points to variable of type C, it's the custom logic of the overridden methods in C+ that will be called.

e.g.

Class C, Method  SayHello, Message "Hello"

Class C+, Override Method SayHello, Message "Hi there"

Existing classes calling method SayHello on the object attribute of type C (which is of type C+) would in fact now be displaying "Hi there" (of course, I guess that most of the time, you would call the super method and just add logic before or after it).

It's like calling Dispose() on a variable defined as System.Object but that can be of any derived type (let's say an UltraGrid): it's the Dipose() method of the most derived class (UltraGrid) that will be invoked.