Cobra Forums

jaegs wrote:Similarly, why is the "of" keyword required in generics?

List<of int>

It seems obvious to me that whatever is inside the angle brackets is a type and no other decoration is necessary. Plus, I imagine really long generics could get messy (well, messier than they already are)

IEnumerable<of List<of Dictionary<of string, int>>>

What should the parser presume when it processes the following?

Is that the start of a generic or a comparison between B and C?

So "of" is to eliminate ambiguity with the less-than operation which is "<". Of course, we know this is not strictly necessary because C# does not take this approach. So I took a peek at someone's C# parser to see how they did it. There was something hackish in the parser to pull it off. The rest of the grammar was parsed in a straightforward manner, but then "B < C" required some major back bending. And maybe we could do the same, but the C# parser got me thinking: "it really is kind of ambiguous". Also, it may be more difficult for Cobra because types can be directly referenced:

But then maybe we could get into casing: Cobra requires types to be capped while params and locals must start lower cased. Throw in the fact that classes cannot be compared for ordering and we could have our disambiguation approach right here.

Although Cobra can't push the casing restrictions on .NET libs produced in other languages. On the other hand, it's rare to see a lower cased generic class in a library and "<of" could be the fallback for using such poorly styled libraries.

So there are possibilities that could be explored for implementing it in the Cobra parser.

How do people feel about "of"? Don't care? Like it? Dislike it?

Usually such questions are problematic as you'll mostly get answers from the discontents who may be outnumbered by the contents who aren't energized enough to speak up. In any case, it's open to discussion.

FWIW I'm in the don't-care to like band.

I think it reads/scans better, clearer and it disambiguates and simplifies the tokeniser/parser coding(as stated)
Personally I see it also as clarifying (with 'of' as a readable delimiter/separator)
the sea of punctuation ('<', '>') and typenames you get with complex
Java/C# Generic descriptions..

OTOH its a bit of a visual/recognition cognitive dissonance stepping from C# and Java code across to the cobra equivalent
(my own personal Imp of Perversity is now screaming at me, that along with so many cobra differences, this is a good thing.... )

But then again I've always felt the <TYPE> syntax for generics in Java/C# is an abomination......

Is it also possible to have


where the keyword "of" is shorthand for typeof()?

I like having "of" in there. It reads closer to the way I think about the types such as "What is this? Oh, it's a list of ints." or "Hmm, I should really declare this as a list of Nodes". Doesn't quite match the way I think about dictionaries but I can live with that.

Actually thinking with "of" works for me for Dictionaries too because I see them as a "set of key+value pairs".

In fact, in .NET, Dictionary<of TKey, TValue> implements ICollection<KeyValuePair<TKey, TValue>> and IEnumerable<KeyValuePair<TKey, TValue>>.

I think Smalltalk presented them in a similar fashion too.

In Cobra, you can loop through dictionaries like so:



For the record, you can also unpack the pair immediately:

Charles wrote:Actually thinking with "of" works for me for Dictionaries too because I see them as a "set of key+value pairs".

Okay, that makes sense. But I think of a Dictionary<of String, int> as a "set of ints keyed by Strings". However, I doubt many people besides me would like writing any of the following:


This is just the way I think of dictionaries/maps though. For a true pair I think Pair<of Foo, Bar> is just fine and dandy. So, if you think of dictionaries as a set of pairs, then SomeKindOfCollection<of KeyValuePair<of TKey, TValue>> makes perfect sense

Afair, in Scala and IronRuby this made somewhat better yet unusual:
Readable, compact, easy to parse.

And also there could be

When I was first designing the Cobra syntax, I considered the "List[int]" bracket syntax briefly, but brackets were already used for indexing objects and slicing:

Granted, if you block indexers from being declared as static/shared then you can use that syntax, but I didn't care for overloading square brackets in this way.

I came very close to using "List of int". Easy to type and read; looks nice in declarations:



But I disliked what it looked like with > 1 type args as in the Dictionary case and also when combined with further types:



The current syntax makes the type look more atomic/self-contained with the closing `>`. Of course, this is very subjective.

Thanks for commenting.

If i'm not mistaken, neither C# nor Java allows static indexers (not sure about indexers in Java actually).

I do think that this:

looks much cleaner and clearer than this (and yet has less brackets):

Also these both could be worked around with aliases (haven't found the syntax for aliases in Cobra):

Using of aliases in such cases is always a good solution anyway.

Still I do agree that any changes to the syntax should be done only if there is a huge demand for them and if the author of the language do agree with them (an author should like his language ). And these things really are more subjective than they matter. I dislike angle brackets still I use(d) them in C++, C# and VB.NET.

What would be much better is to have aliases like these in the language:

I miss them so much in C# .

Thanks for answering.