Oxygene Dictionary literal

Elements Oxygene
1

This is probably a feature request.

Would it be possible to add similar Dictionary literal as is already in Swift? It would make even more sense with new RTL, that could house underlying dictionary type for all supported platforms.

In Oxygene the syntax could be - the same as in Swift:

var myDictionary1 := ["SampleKey1" : "SampleValue1", "SampleKey2" : "SampleValue2"]; { Dictionary<String, String> }
var myDictionary2 := ["SampleArrayKey1" : [1, 2, 3], "SampleArrayKey2" : [1, 1, 2, 3, 5, 8]]; { Dictionary<String, array of Integer> }

At this time, creating such construct is inelegant, I use this way:

var myDictionary1 := InitializeDictionary1;
method InitializeDictionary1: Dictionary<String, String>;
begin
  result := new Dictionary <String, String>;
  result.Add ("SampleKey1", "SampleValue1");
  result.Add ("SampleKey2", "SampleValue2");
end;
2

Yeah we have bugreports for this already, the biggest problem is the syntax here. None of the combis we’ve tried work/don’t conflict.

3

You may have tried/considered this already, but what about a more general syntax to allow calling a given method multiple times with different parameters by providing a comma separated list of parenthesised parameter clauses, along the lines of:

result := new Dictionary<string, string>;
result.Add("Key1", "Value1"), ("Key2", "Value2");

And while I’m at it, something that bugs me from time to time is when I want to new up some object and do some fluent initialisation on it (or just a one-off init method call) but where the fluent chain doesn’t return the object reference itself at the end. This is more often a problem where I’m making a one-off init method call, rather than part of a “proper” fluent initialisation Api (which typically does return the object of interest).

This example of adding some initial value(s) to a dictionary is a good example since the Add() method is not designed to be fluent.

In these cases it would be very cool to have a syntax which would allow methods to be called on some object but to have the expression return the object itself, not the return value of any called method. The with reserved word could potentially be used to achieve this, separating the new-up of an object (to be returned) from an initial method call to that object, something like:

result := new Dictionary<string, string> with Add("Key1", "Value1");

Then, combining that with comma separated multiple method calls:

result := new Dictionary<string, string> with Add("Key1", "Value1"), ("Key2", "Value2");

Which would be procedurally equivalent to:

result := new Dictionary<string, string>;
result.Add("Key1", "Value1");
result.Add("Key2", "Value2");
4

Does that really add clarity though?

5

Well, that’s a fairly subjective question. :slight_smile:

For me I find it an interruption in thought process because instead of coding what I am thinking I have to break it up into what the compiler needs:

I want a reference to a new object with some simple/trivial initialisation applied.STOP
So that I can use that initialised object ...

vs

I want a reference to a new object.STOP
Then I need to initialise the object.STOP
So that I can use the initialised object ...

In terms of clarity, it perhaps isn’t as clear as some syntactic sugar for literals might be, but has the advantage of being very adaptable and not limited to only being useful for literals, which a literal syntax might end up being. :slight_smile:

e.g. a literal syntax for an underlying Dictionary<> type has to be built with the compiler assuming that the required initialisation method to be called is Add(K, V) into which to pass the literally specified values. There might be some provision for a range of candidate methods or simply a parameter type matching rule by which the compiler might determine some method to use when initialising the literal, but this has obvious pitfalls if there are multiple such candidate methods.

To so avoid that problem, the compiler specification might instead simply impose a condition that literal initialisation of some specific form can only ever be used to initialise a Dictionary<K, V>, thereby always safely assuming the use of Add(K, V).

Making the mechanics of initialisation explicit, but more convenient than the “long-hand” procedural initialisation approach avoids these problems, provides utility beyond the specific case of literal initialization, and provides almost all of the syntactic clarity that a literal syntax might achieve (but which has proved elusive thus far ;)).

imho. ymmv. :slight_smile: