Fun with casting and inheritance

Question

NOTE: This question is written in a C# like pseudo code, but I am really going to ask which languages have a solution. Please don't get hung up on syntax.

Say I have two classes:

 class AngleLabel: CustomLabel
 {
     public bool Bold;  // Just upping the visibility to public
     // code to allow the label to be on an angle
 }

 class Label: CustomLabel
 {
     public bool Bold;  // Just upping the visibility to public
     // Code for a normal label
     // Maybe has code not in an AngleLabel (align for example).
 }

They both decend from this class:

 class CustomLabel
 {
     protected bool Bold;
 }

The bold field is exposed as public in the descended classes.

No interfaces are available on the classes.

Now, I have a method that I want to beable to pass in a CustomLabel and set the Bold property. Can this be done without having to 1) find out what the real class of the object is and 2) cast to that object and then 3) make seperate code for each variable of each label type to set bold. Kind of like this:

 public void SetBold(customLabel: CustomLabel)
 {
     AngleLabel angleLabel;
     NormalLabel normalLabel;


     if (angleLabel is AngleLabel )
     {
        angleLabel= customLabel as AngleLabel 
        angleLabel.Bold = true;
     }

     if (label is Label)
     {
        normalLabel = customLabel as Label
        normalLabel .Bold = true;
     }
 }

It would be nice to maybe make one cast and and then set bold on one variable.

What I was musing about was to make a fourth class that just exposes the bold variable and cast my custom label to that class.

Would that work?

If so, which languages would it work for? (This example is drawn from an old version of Delphi (Delphi 5)). I don't know if it would work for that language, (I still need to try it out) but I am curious if it would work for C++, C# or Java.

If not, any ideas on what would work? (Remember no interfaces are provided and I can not modify the classes.)

Any one have a guess?

Answer 1

What you can do is add a mid class (named for example CCC) between CustomLabel and the other two classes.

public class CCC : CustomLabel

This class should has a function named SetBold(bool bold) that will set the protected field.

public void SetBold(bool bold)
{
    base.Bold = bold;
}

AngleLabel and Label will both inherit CCC

and the parameter for SetBold(...) will be of type CCC

Answer 2

Since the parent is protected the answer is that it should not work in any language without additional work, unless the code in question is performed in a descendant of the custom version.

Delphi has an option to use a protected hack to make it work. C# and Java could use reflection. C++ friends could be used to make it work.

But if you had declared Bold as Public in the CustomLabel, then the functionality would work in all of the languages you have specified. Delphi, C++, C#, and Java with out having to do anything special.

Answer 3

C++ would solve this with a template (assuming SetBold is the equivalent of Bold in your sample):

template<typename T> void SetBold(T t) {
    t.SetBold();
}

Answer 4

It would work in Delphi. Code in the same unit as the classes it uses have implicit access to protected (but not strict protected) members, even those members declared in another unit. You'de declare the property protected in CustomLabel:

type
  CustomLabel = class
  private
    FBold: Boolean;
  protected
    property Bold: Boolean read FBold write FBold;
  end;

The bold-setting procedure, in another unit, would have its own CustomLabel descendant:

type
  TAccessCustomLabel = class(CustomLabel);

procedure SetBold(customLabel: CustomLabel)
begin
  TAccessCustomLabel(customLabel).Bold := True;
end;

You can't use an as cast on that because the actual parameter will never be an instance of TAccessLabel. It will be an instance of AngleLabel or NormalLabel, but since the portions inherited from CustomLabel by all three classes are common, the Bold property is the same in all of them. That remains true even after the property has been publicized or published in a descendant:

type
  AngleLabel = class(CustomLabel)
  public
    property Bold;
  end;

You can change the visibility of properties, but not fields. If you try the same thing with a field, you'll be declaring a new field with the same name that hides the inherited field.

---

You can do something similar in C++, but it's not as commonly done as it is in Delphi, so it's likely to draw some ire, especially if you intend to write portable code.

Declare a fourth class, like in Delphi. C++ isn't as loose with member access as Delphi is, but it has the concept of friendship, which works just as well in this case.

class AccessCustomLabel: public CustomLabel
{
  friend void SetLabel(CustomLabel* customLabel);
};

That function now has full access to the class's members:

void SetLabel(CustomLabel* customLabel)
{
  // Not allowed:
  // customLabel->bold = true

  // Not ordinarily allowed; requires friendship
  reinterpret_cast<AccessCustomLabel*>(customLabel)->bold = true;
}

That's technically undefined behavior because we've type-casted an object to a type that it doesn't really have. We're relying on all descendants of CustomLabel to have the same layout, in particular for the bold member of an AccessCustomLabel to reside at the same relative position as the bold member of any other CustomLabel descendant.

---

The type casting in the Delphi and C++ code performs type punning. You're not going to get away with that in C# or Java; they check the results of their casts, so if customLabel doesn't really hold an instance of AccessCustomLabel, you'll get an exception. You'll have to use reflection to access the protected members of unrelated classes in those languages. Demonstrating that is beyond my depth.

Answer 5

If you are using Delphi 2005 or later, you could use class helpers. Class helpers can access protected fields and methods of the "helped" class. Something similar may be possible with C# extension methods, but that isn't an area I'm that familiar with.

Note: I have been unable to test this as I don't have a compiler handy.

type
   TLabelHelper = class helper for CustomLabel
   public 
     procedure SetBolded(ABold : Boolean);
   end;

procedure TLabelHelper.SetBolded(ABold : Boolean);
begin
  Bold := ABold;
end;

...

Label.SetBolded(True);

Answer 6

In C# 3.0 and higher you can use extension methods; those are similar to the Delphi Class Helpers that Gerry mentioned.

It goes along these lines (watch the this keyword).

public static class CustomLabelExtensions // name here is not important, just make it readable
{
    public static void SetBolded(this CustomLabel customLabel, bool newValue)
    {
        customLabel.Bold = newValue;
    }
}   

Note I left out the namespace like you did in your pseudo code.
Make sure however that CustomLabelExtensions is visible to your code, either by using its' namespace or by explicitly specifying that namespace.

Also note that Extension Methods only allow you to add methods, not properties (coming from a Delphi background, that was odd to me).

You then use the above code like this:

AngleLabel angleLabel;
NormalLabel normalLabel;
// some code that assigns values to the variables
angleLabel.SetBolded(true);
normalLabel.SetBolded(true);

--jeroen