Cobra Forums

I'll be adding this extension method to Object:
You'll still be free to write VM-specific code such as obj.getType on .NET and obj.getClass on JVM. But .typeOf will be available for making code more portable and you'll see it in samples, how-to's and tests.

I chose the name because other names like "type" and "getType" are too common on one platform or the other. "typeOf" is hardly used. I determined this using Google Code Search with lang:C# and lang:Java.

In the rare event that you had a library class with a .typeOf method, saying "foo.typeOf" would invoke that specific method since it would be found before the extension on Object. If you needed to get to the Object one, you could typecast with "(foo to Object).typeOf". Of course, if the library's .typeOf method took arguments then method overloading would kick in and you wouldn't need any typecasts at all.

Feedback and questions are welcome.

Hi,
.typeOf is good.I like it better than .getType and .getClass.
Regards
Csaba

Chuck wrote:But .typeOf will be available for making code more portable and you'll see it in samples, how-to's and tests.

I like the idea of cross-backend compatibility but I fails to see how it can be achieved. If I'm correct, typeOf will be a synonym for getType in .NET, and for getClass in JVM. So far so good, I can do foo.typeOf from Cobra and it will translate to the correct backend method. But then what can I do, in a portable manner, with the object returned by typeOf? If I'm on JVM then it will be an instance of "Class", and if I'm on .NET it will be an instance of System.Type, and these two classes have quite different interfaces.

The only solution I see for true portability would be to have Cobra define it's own version of Type, which contains all the functionality that's common across backends (i.e., that's both in JVM's Class and in .NET's Type). But then it could not be called "Type", because that would clash with .NET's System.Type, and for the same reason it could not be called Class. Besides, it could be tricky to implement this common functionality, because it could lead to a "recursive" problem: each method we want to add uses itself other types which are backend-specific, so we must create backend-independent wrappers for them as well, and so on...


I think cross-backend compatibility might be one of Cobra's main strengths, so it is important to solve this kind of issues in a satisfactory manner. Other examples where it might be tricky to achieve: class String, class Object. Even such basic classes are quite different across backends (and I'm considering JVM/.NET only). Maybe it's time to start adding a "backend abstraction layer" (BAL) class library to Cobra?

Your comments are correct. I should have been more clear on what I was trying to achieve. In the long term, yes we'll need a cross platform library that covers strings, collections, reflection, file I/O, etc. And for whatever bits we don't cover at a particular point in time, the programmer will have to write up in his own little portability library for his project. (Or he can write VM specific code and not worry about such issues and not use the portable library.)

In the short term, we need a few key methods so that the How To's and Samples can be cross platform even if there is no real cross platform library yet. I'm thinking about things like:

Code: Select all

951 ~/Projects/Cobra/Workspace-JVM/HowTo $  gco getType
./200-MakeAClassHierarchy.cobra:103:                    sb.append('[.getType.name]([_serialNum]')  # example: 'Foo(1001)'
./300-ImplementIEnumerable1.cobra:47:           return '[.getType.name]([_serialNum], [_name])'
./301-ImplementIEnumerable2.cobra:37:           return '[.getType.name]([_serialNum], [_name])'
./310-IterateThroughRecursiveDataWithYield.cobra:34:            return '[.getType.name](item=[.item])'


This will be accomplished through extension methods implemented on both platforms.

Also, I don't think we can start the cross platform library until we actually have Cobra/JVM working. Otherwise, the development would be entirely on the .NET side at first which would no doubt lead to oversights and serious mistakes.

Chuck wrote:This will be accomplished through extension methods implemented on both platforms.

Sounds good, that's the part I had missed.

Chuck wrote:Also, I don't think we can start the cross platform library until we actually have Cobra/JVM working. Otherwise, the development would be entirely on the .NET side at first which would no doubt lead to oversights and serious mistakes.

You're right, it's probably too early for that.