All about types

[todd.a]

So on IRC this has come up a few times (correction: I brought it up a few times to change the tide ), and it is possible that I am the only one that feels this way. With that said I am particular (slightly persnickety) about the way my types are named (probably Scala syndrome). Anyway, as you may know in C# the following both do the same thing...

Code: Select all

int a = 1;
Int32 a = 1;
// cobra can provide Int and Bool in place of Int32 and Boolean for conciseness

Console.WriteLine(a.GetType()); // produces System.Int32

Int32 is a member of the System namespace, fully qualified as System.Int32, and int is simply an alias to this structure. My point of view is that types are nouns-- we name user-defined types as nouns (the type of real world objects)--and as such should be named accordingly for consistency. I am in favor of Single, Double, Decimal, Dynamic, Int, Byte, etc. over float, decimal, int8, etc.

I like the pascal-cased versions for the following reasons:

• The common type system (CTS) types makes anyone familiar with .NET or Mono know immediately what a type truly stands for
• They are a type and are named like any other type users may define
• They are consistent with System.Type, so 5.getType will be Int32 and so on

In the more general sense there are multiple languages running on .NET/Mono (as they were designed to accommodate), and by keeping the "primitive" types in sync with the underlying types (provided by the CTS) makes libraries more "transferable". The word transferable is used here in the sense that Boo, C#, and VB users can look at Cobra code and implicitly absorb the types.

Just trying to get a feel for what the rest of the community feels regarding this. I'm possibly very off-base on the issue.

[Charles]

One problem with this post is that it assumes that Cobra is purely .NET centric. There is a JVM back-end in progress and I expect there will be an Obj-C back-end in the long term. The System.* types don't necessarily map to other platforms.

Also, I don't see the value in a situation where 90% of Cobra code uses "int" and 10% happens to use "Int32".

Re: other languages, VB.NET using "single" where C# uses "float" and then Delphi.NET uses "real" but off the top of my head I don't know if that's 32-bit or 64-bit. As you can see, when you use a language, you have to at least peek at the docs and see what's going on. Even past the single/float/real issue is the fact that for any language, you're going to have to find out:

-- What is the syntax for referencing generic types?
-- Is there a syntax for nullable types? Does it apply to all types or just some?
-- Is there a syntax for streams?

Btw these are covered at TypesOverview.

Re: other languages using libraries written in Cobra, both Visual Studio and .NET Reflector will show the coder the API in terms of his language, not the original language or the bytecode. This is part of .NET's multi-language approach which provides a common type system for compatibility and reuse, but has never required nor encouraged that syntactically the languages use the same name.

I'm not changing the names or the case of the Cobra primitive types like bool, int, char, etc.

[todd.a]

Not good to use "never" or "not" to users or customers. Keep the customer happy, always. It's ok to use those words if I'm the only one though.

[Charles]

It's also important for people to know what to expect and what is stable about Cobra. This is part of customer satisfaction as well. I don't want anyone to be bothered thinking that the type names or basic syntax are going to be switched up on them.

[hopscc]

I think the current setup is pretty optimal.
Its only an issue for platform equivalent types - cobra handles the translation for more complex typing ( generics, streams, iterables)

If you dont care ( or dont want to care) about the exact platform types and you want some level of portability between
possible platforms you use the (lower cased) cobra type names
If you want to be tied to a particular platform ( .Net/Mono) you can use the platform types

Cobra does the mapping to the platform types so exporting libs for use by other languages is available by using the
platform languages and tools.

[todd.a]

I'm not suggesting switching the types on users. IMO it would be nice to at least have the platform centric types for the users that are only going to program on .NET for example (C# does it), so maybe a way to turn off the warnings ?

[helium]

Anyway, I'd vote for starting all type names with an uppercase letter.

[todd.a]

So I was talking to a friend of mine that is inside Microsoft and we were discussing why C# is a good language but it's really shitty. There is no fun and art in it. So I mentioned that I wonder if the hardcore compiler guys really use the language in everyday applications. It turns out this is a huge problem with the compiler team at MS cuz the hardcore guys provide great language features but don't really care how it looks. Then the conversation went on to discussing the freedom that end users should have and this post came to mind.

Originally I was for changing the type names to being capitalized, but my opinion has been refined because I think warning about using Int32 is the same as giving a warning for using StringBuilder. Why? Because it is present in the .NET API and very much a part of it. So basically I think users should have the option of using the true name of the CTS type or the Cobra names for portability. I think forcing to use Cobra names here crosses the line. I understand the reasons for keeping all our code looking the same but the fact of the matter is some users will develop for strictly .NET/Mono or strictly Java, Obj-C, etc.

What I propose is having both with maybe an option for portability warnings. I'm still tempted to edit the source to turn those warnings off cuz I really don't think I should be warned about them. And I really don't want to be warned about then cuz I'm not doing anything wrong. I think this one deserves to give users the option. If you don't feel that way Chuck then it's OK.

[hopscc]

FWIW I've been thinking it'd be convenient to provide a way to suppress some warnings for things I dont want to be warned about ... most of the time
- theres the per line warning suppression but that gets a bit tedious for more than occasional use
if the facility exists then developers can choose to silence the compiler about things they might consider gratuitous nagging or at least uninteresting for their own purposes
( or warnings you might disagree with chuck over the need for (:-) )...

The nominal way would be to number all the warnings (existing now and mandate numbering on added warnings from that point) and provide some form of cmdline switch or other config setting
listing warning numbers to suppress ( like the cs compiler does - /noWarn (??) ) ... but nahh

What I've been thinking minimally is to provide an extra compiler directive that as an argument has a regexp pattern of the warning to suppress
- these patterns then become a filter the warnings pass through similar to whats done with line numbers for the per line warning suppression
This would be adequate for single file and low numbers of files for a compile...
..some form of file inclusion might be useful in conjunction with this for larger numbers of files....

syntax something along the lines of

Code: Select all

%%no-warning 'The first statement of an "init" cue should be a call to another "init"'
%%no-warning 'Did you mean .cue init'


That has the benefit of being self documenting at least
( cf

Code: Select all

/nowarn:0108,0162,0169,0183,0184,0219,0414,0429,1717,1718

who can tell what warnings they might refer to ...)

Eventually perhaps allow access to a compiler config file that could contain these and other things that might want to be set on a per project basis
and some way of enabling access to this at cobra compiler runtime

More consideration and raise in irritation level required but I'll probably post a patch for this in some form eventually.

[Charles]

Which, if any warnings, are unnecessary?

-Chuck