All about types

[todd.a]

For example if you had the following code

Code: Select all

class Program
  def main
    a as Int32
    a = 33
    print a

You'll get "warning: Use the builtin type "int32" instead of the struct "Int32"." It might be in the grey area of having different backends but on .NET all "primitive" types are structs. This warning seems to hint that the builtin int32 is a more primitive value type than a struct. After all in C# int, bool, char, string, etc. are only aliases.

These warnings are very annoying on larger code bases and I don't think there is anyway to turn them off (if there is please tell).
I don't think it should give a warning since System.Int32 is a valid type and the same as int32. To me a warning should be for using code that is potentially harmful or outdated.

What do you think?

[hopscc]

For me most recently I've been wanting to suppress the two warnings I gave as examples earlier ( recompiling older code and stubbing constructors).
The other OTTOMH is the warning around the explicit form of adding/defining an event handler callback ( wayback).
Theres probably others dropped below notice for the moment

probably should clarify that its not that these warnings are always unnecessary/non useful its just that sometimes I dont want/need to know or
I just want the compiler to STFU about them while I fry other fish

The most recent irritant is that that

Code: Select all

class Foo
    cue init
        pass

    def something
....


emits this

Code: Select all

x.cobra(3): warning: The first statement of an "init" cue should be a call to another "init" in this class or the base class.
Compilation succeeded - 1 warning


STFU already - I've said I'm passing on the ctor contents ... quit yer bloody whining...

[todd.a]

Maybe the warnings should be tied into the verbosity level. After all they're only warnings, not errors.

Btw hopscc seems like you've been on a roll with the patches lately. You and Chuck have made some great contributions. I sure appreciate the improvements and features (I'm sure other members of the community do too). Looks like the makings of a great v1.0.

[Charles]

STFU already - I've said I'm passing on the ctor contents ... quit yer bloody whining...

So when you're passing on the constructor contents, what would you expect to see if you disassembled the byte code with ildasm or Reflector?

[Charles]

These warnings are very annoying on larger code bases and I don't think there is anyway to turn them off (if there is please tell).
I don't think it should give a warning since System.Int32 is a valid type and the same as int32. To me a warning should be for using code that is potentially harmful or outdated.

What do you think?

A few years from now there will be more open source projects in Cobra. I'm not enthused about downloading project A which uses "Int32" and "float", project B which uses "Int32" and "Single" and project C which does a mixture of everything because the developers couldn't agree. What's the benefit?

Yes C# allows you to seamlessly switch back and forth. But I can tell from having worked with .NET professionally that most dev teams would wonder what your major malfunction was if you wrote Int32, System.Bool, etc. .NET devs generally use the language types (int, bool, char, etc.) and the structs are there by virtue of being in System--and they're ignored.

It's notable that the vast majority of languages don't offer two ways to name every basic type. But I encourage you, as a learning experience, to suggest to the authors of Python, Ruby, Scala, etc. that they "enhance" their languages to do so.

[hopscc]

Dunno - never had the need to do either of those things to date.

What I'd want it to do is (continue to) just work - exactly as if I'd not put the stubbed ctor in at all
( or done a passthru boilerplate

Code: Select all

cue init
    base.init


What does it gen now ( in spite of the warning) ?

[Charles]

Well C# insists that there be a call to a sibling or base constructor, even if the call is invisible and silently inserted by the compiler. A fact that I think many devs lose track of. So a disassembly would show a call even though the original source code clearly had none ("pass").

There is also the question of what to do if there are no initializers specified at all. In C#, if you don't declare a constructor, it creates a parameterless one for you which calls the base parameterless one--which may not exist and therefore cause an error. Yuck! And Cobra does the same right now.

I'm still planning to change Cobra such that you if you don't specify an initializer, then you inherit covers for each base initializer. I think this makes more sense and it reduces some of my code.

If you specify just one initializer then no initializers are automatically covered--it's up to you to dictate what you want.

[todd.a]

Well not because the language is open source, doesn't mean that everything it is used for will be open source. I believe the MIT license allows use in closed source projects.

I have to differ with you on the use of "language types" and structs. The structs are the real types. int, bool, char are just aliases (not the other way around).

Some languages take votes on issues like this, others have one person making the calls. Either way I don't really care what the process is, my suggestion is just from the perspective of an average user. For me I don't care about the JVM, I want to run Cobra on .NET/Mono and as a personal coding standard I like keeping all my types capitalized. I'm not asking for you to change this in Cobra as an "enhancement". If it's a warning I want to turn the warning off because I don't want to be warned about it. If it is forced then it should be an error IMO.

I'm gonna go into Ted Kennedy mode on this issue. I think I should be free to do whatever in my personal code that no one cares about. If there are community guidelines for contributing open source I don't mind abiding by those. It's like the Python guidelines (I forgot the PEP number) that outlines how proper Python code should be written. That seems like an acceptable approach to me.

Funny that you mentioned Scala, Ruby, and Python, cuz they all use PascalCased types which is consistent. I can argue that if you want to use type names like int, float then I can should name custom types like person, stringbuilder in open source projects. I just like everything being consistent throughout in "my" own code. On someone else's project I go by their guidelines.

I'm not a language designer or compiler developer and only developed with C# for 3 years so I don't consider myself experienced. But I didn't like it then and I don't like it now. Microsoft has published guidelines, which they rightly followed by naming all types PascalCased but then they provided those aliases in C#. IMO they were idiots for doing it because AFAIK it was done to please C++ programmers. Call me obsessed but I like the code I write to be pretty as the UIs I design .

Chuck: I respect the decisions you make regarding the language but I'll give you nightmares about this one. I'm gonna use Cobra to write a spam bot LOL spreading the message. Who do you like more the senate or the house of representatives? I could just sit back and accept things the way they are, but not when I'm this passionate about using the next great language.

Just my 2 (maybe 1000) cents.

[hopscc]

Yah - The C# and current Cobra behavior is same as Java - call a base initializer explicitly if desired or the compiler will insert a default call for you
I dont have a problem with that
ditto compiler insert/create a default initializer if you dont specify one - Its needed as part of the architecture (initializer chaining so objects get constructed correctly)
- I'd suggest if devs dont realize or forget that they are liable to have other problems as well

While I guess its possible the default rules might cause problems if theres no baseclass no-arg initializer I cant say I've ever seen that happen ( Java ).
I vaguely recall that the Java language description reccommends that all classes have a no-arg constructor even if it does nothing beyond indicating an error - can't remember if the (java)compiler
warns or enforces that or not.

I'd imagine the default insertion behaviours cover this mostly anyway with the possibility that if default no-arg constructor is incorrect for must-init cases in which case you'll probably find out about it pretty quick .

FWIW I think its overly pedantic to always enforce an explicit first statement call to a base or sibling initializer (I preferred the original Cobra/C#/Java behaviour) - for most simple classes ( those that have/use no-arg ctors) its pointless boilerplate. Let the compiler insert it for you

For the implicit (no initializers specified at all ) case I agree its probably more preferable to shadow the baseclass initializer(s) in their entirety rather than create a default no-arg ctor

re use of pass in initializers; ( partial initializer ??)
I'd agree thats its a pretty pointless case but I seem to have been doing it rather a lot recently for some reason (placeholding stubs?) the warning is just annoying ( perhaps more so since it used to work silently)

With this

Code: Select all

cue init
    pass # do nothing else


What I want is as if I'd done this

Code: Select all

cue init
    base.init
    pass # do nothing else


since the pass is indicating that I explicitly have said I dont want anything else whereas

Code: Select all

cue init

def  anotherMethod


Might be construed as that I'd forgotten to insert any initializer code and that a warning may be appropriate...

Re webnovs points I mostly agree (with the concept at least, not the particular issue with type naming )
- while the compiler can try and enforce its view of desirable behaviours and guide with warnings, at some point it becomes counterproductive and annoying
(unless you work from the assumption that the developer always cant be trusted to know what they doing and must be forced to the 'one true path')

The devlpr makes the choice about what their app is for and what its range/target shall be and what their concept of consistency for it is
- the compiler should allow that freedom and provide the possibility of just doing as its told and getting out of the way

OTOH perhaps its in the warning wording (tone) ?
rather than

warning: Use the builtin type "int32" instead of the struct "Int32

perhaps something a little more obsequious

warning: Perhaps you meant to use the cobra builtin type "int32" instead of the less portable platform struct "Int32 (sir)

[Charles]

Re: @webnov8's most recent post on capping types:

-- Yes, the MIT license allows for closed source which is one reason why I'm a fan. But that doesn't remove my example case re: open source projects. Nor does it mean that I want to inherit private projects with randomized type names like what I see in C# (System.Int32 in one file, Int32 in another, int in another, mixture in another).

-- Some types such as "dynamic" and "streams" don't have a .NET equivalent, so not all types are aliases to structs (and there is no "Int" for "int"). But even for those that are aliases, that is a facet of the .NET VM, not of languages in general. Nor of Cobra which defines types such as "dynamic", "int" and "bool" and then implements those, currently on .NET.

-- Cobra is destined to have other back-ends like ObjC and Java. You may not care, but I do.

-- Re: voting, most languages have a lead designer such an Guido or Matz. More often than not, this results in a language with a cohesive design. (Whether or not you like that design is expressed by which language you end up choosing to use.) The Python community does collect votes on some things, but Guido still has the final decision, especially regarding language features. For an example of a committee-based language, see COBOL. I'm serious; that's how it was built.

-- Yes, Cobra is more syntactically strict about some things than Python, C#, etc. That's an intentional feature which makes sharing code more seamless. If you want to go into "coding cowboy" mode, Perl is your best choice.

-- You say Python consistently uses PascalCased type names. Python types include str, bool and int.

-- You will never agree with all the choices made in the design of a non-trivial language (other than one you write) because the space of possibilities is too large. If we faced only 32 binary decisions in the design, that's over 4 billion possibilities. And it's bigger than that, so at some point you have to go with what you like the most.

-- I'm not changing the type names or allowing multiple names for basic types such as "bool". For reference on types, see

http://cobra-language.com/trac/cobra/wiki/TypesOverview