Cobra Forums

is there any way to define const members?

Not currently. I've just been using shared get-only properties:
With everything else going on in my programs, I don't know if I'd even notice a speedup.

But I'm not opposed to adding constants. I suppose the syntax would be like "var" but using the word "const".

We already have a ticket for "readonly": http://cobra-language.com/trac/cobra/ticket/100
which IMO should be a higher priority. Sometimes you don't want to use "const" in a library and also "readonly" can be applied to wider range of types (see the MSDN C# docs on "const" for what I mean).

Another bump.

Anyone see any need for supporting const on local variables ?

Code: Select all

/ c# const_keyword_2.cs
using System;
public class MainClass
{
    static void Main()
    {
        const int c = 707;
        Console.WriteLine("My local constant = {0}", c);
    }
}


or should we just rely on readonly/final ?

If supported it may get a bit confusing since conforming to the existing syntax would provide it as an access modifier ( on variables only) where it will
be entangled with 'final'

Code: Select all

class MainClass
    def main is shared
        c as int  = 707 is const  # new
        assert c == 707


also providing this capability in either form (on local variables) confounded by bug from ticket:34

The way C# works on this regard is confusing, with readonly and const meaning really similar things. I think Cobra should provide a solution that is more elegant and not so tied to C# (what ever is added now, will have to be "ported" to other backends that don't have similar construct).

I would probably use the modifier "final", which would work like C# const if it's applied on a value type, and like C#'s readonly when applied on a reference:

I might be missing something, but I don't see the point of needing two separate modifiers. I've used "final" because to me const is to tied to C++, in which it means a different thing (the part that is immutable is typically the referenced object, not the reference; there is no such thing in C#).

Since I think there are plans for a D backend, I think I should mention this. Despite its initial goal of being a streamlined version C++, D now seems to be taking an even more complicated approach to immutability:

http://www.digitalmars.com/d/2.0/const3.html
http://www.digitalmars.com/d/2.0/accu-functional.pdf

<dream_mode = "on">
My dream language would have the semantics of C++'s const, in which the const part is not the reference, but the pointed to object (D has something similar, follow the links above). But unlike C++, the compiler would analyze my code and automatically infer which methods are const and which aren't (in C++ you have to do it by hand, and it's a pain).

One problem I see with this approach is that it would require all non-Cobra methods (i.e., those imported from external DLLs) to be manually annotated as const or not const, which might be a tedious job
<dream_mode = "off">

Hi
I would prefer just

Code: Select all

class Foo         
     const pi = 3.14  is shared   # class constant                         
     const e = 2.718281828        # object constant   


For me these examples ar obvious.
Regards
Csaba

I presume theres two forms (C#) to allow optimisation between compile time (romable) and runtime (calculated) constants wrt initialisation.
While possibly sometimes desirable its probably overkill for a simpler/more approachable language..

I think I'd agree that its probably better to have a single (keyword) construct combination that will try and provide both - modulo backend support available
and I like jonathondavids suggestion:

Code: Select all

class Foo
    final a = 3.0 is shared # eq. to "const" in C#, static final in java
    final b = 4                   # eq. to "readonly" in C#, final in java


Change from patch ( now current) would be
'const' keyword -> 'final'
Lose 'final' access modifier/isname
Change CLR code gen such that
final instance vars map to c# readonly
final + shared instance vars map to c# const

Keep in mind that in .NET, a "const" use will be replaced by its value, whereas a "readonly" use will be a reference. In other words, if you say:
This has implications for what happens if you update a .DLL. In the case of const, the .EXEs that use it will NOT be affected. In the case of readonly, the .EXEs will be affected. There are even more implications.

If this isn't clear enough, read the C# docs on "const" and "readonly". Or even search the web for "C# const readonly".

I don't think we can have a "final" that acts like "const" when shared and "readonly" when not. This will cause confusion at some point later.

Currently, I favor the use of "const" as hopscc implemented in his recent patch which was applied the other day. I also favor adding a "readonly" which is what I would typically use. I admit I haven't studied the JVM side of things to see how any of this translates and that could affect things.

what about simply using "val" for value?

Code: Select all

val newLine = '\n'
val two = 2


simple, 3 characters, fits good to var/get/set/pro and doesnt break with cobras sexy style (what 'final' or 'constant' would do in my opinion)

Hi all,
Of coure, if "Const" is not a constant, then it should not be called "Const"!
The object "Const" I suggested above was to be able to write ".k_pi" instead of "ThisClassName.k_pi" as now done in VB.
Values determined/changed at load time, or when the first object of a certain class are created, or when the object is created are not "Const". EDIT: For these latter cases "get someReadOnlyParameter return SonehowFetchedAndOrCalculated" is as clear as it can be. Why introduce an extra reerved word for this?
Regards
Csaba