views:

215

answers:

2

I need to implement a function which returns a TDictionary, without specifying the exact types. The returned value could be a TDictionary<string,Integer>, TDictionary<string,string> or TDictionary<string,Boolean>

Could I declare the function with TDictionary as result parameter:

function GetMap: TDictionary;

and then cast the return value:

type
  TMyMapType: TDictionary<string,Integer>;
var
  MyMap: TMyMapType:
begin
...
  MyMap := GetMap as TMyMapType;
...
end;

Edit: found that there seems to be no way to declare a 'generic' result parameter type which would be type compatible with my three dictionary types.

It looks like I need something like

type
      TMyMapType: TDictionary<string, ?>;

which is not (yet?) possible in the Object Pascal language. In Java it would be something like this:

static Map<String, Integer>getIntegerMap() {
    Map<String, Integer> result = new TreeMap<String, Integer>() {};
    result.put("foo", Integer.valueOf(42));
    return result;        
}

static Map<String, ?> getMap() {
  return getIntegerMap();
}

public static void main(String[] args) {
    System.out.println(getMap().get("foo"));
}
A: 

When calling GetMap, you already know that the result will be a TDictionary. Why not creating an Generic function GetMap of T and U that returns an TDictionary of T and U ?

Like this:

function GetMap<T, U>: TDictionary<T, U>;

Then you could do this without casting:

var
  MyMap: TMyMapType;
begin
  MyMap := GetMap<string, integer>();
Sebastian P.R. Gingter
function GetMap<T, U>: TDictionary<T, U>; does not compile - and function GetMap: TDictionary; does not compile too. I am now in tutorial reading mode again :)
mjustin
This should IMHO work just fine if `GetMap` is a member method.
Smasher
+2  A: 

No, there's no "base TDictionary class that all TDictionary versions descend from". The parameter types are part of the class type. The parent class of TDictionary<T, U> is TEnumerable<TPair<T, U>>, and the parent class of that is TObject.

This is a bit annoying, but it's necessary to preserve type safety. Lets say you had a TDictionary<string, TMyObject>, and you passed it to a function that's expecting a TDictionary<string, TObject>. You might expect this to work, since you can pass a TMyObject to a TObject parameter. But it doesn't, and there's a good reason.

The compiler can't check the actual type inside the receiving function at compile-time, so there's nothing stopping the routine from taking your dictionary and calling .Add(Self.Name, Self), where Self is a TForm (or anything else) and not a TMyObject. Since all object references are sizeof(pointer) in size, this would seem to work just fine, but when you get it back in your code that knows what the second parameter is supposed to be, you've got a big problem.

There are ways to make Generics work as you'd expect without trashing type safety, by placing constraints on the receiving function, but Delphi doesn't currently implement it. Delphi Prism does, and I've been trying to get the Delphi team to implement it in the next release, but we'll have to see...

Mason Wheeler
Thank you for this answer, after reading it and http://www.ibm.com/developerworks/java/library/j-jtp04298.html (which shows a possible solution using 'capture helpers') I understand the problem. In my simple case, a TDictionary<string, TObject> with primitive wrapper objects might be a workaround because I need it only for return types.
mjustin