I ran into a situation when using some SOAP services that is a bit annoying. There are two services, both of which use a lot of the same help classes as part of their methods. Each of these classes might have some properties that point to instances of other classes. I wrote some functions that need to be able to take those same classes but they can’t because of the nested helper classes.
This is probably confusing, but here’s an abstract example:
Foo1 = public class
public
property Prop: String := '1';
end;
Class1 = public class
public
property Obj: Foo1;
end;
Foo2 = public class
public
property Prop: String := '2';
end;
Class2 = public class
public
property Obj: Foo2;
end;
So I have a function that I want to have take either a Class1 or a Class2, since they’re really the same class (from a human’s point of view). I tried duck typing, but the problem is that it seems duck typing only works at the most surface level. It got all ducked up when I had to confront their being a Foo1 and a Foo2.
I tried
IFoo = interface
property Prop: String read write;
end;
IClass = interface
property Obj: IFoo read write;
end;
but that was no good. When I tried to do
var c := new Class1;
var ci: IClass := duck<IClass>(c);
it just did not like it at all, since the classes do NOT use IFoo. I’d need the compiler to have a deeper understanding of ducks.
Anyway, I think I’m just going to have to maul this generated service code myself, as I can’t do anything to fix it upstream. I just thought I’d throw it out there for comments.
