Forums
const / readonly member
12 posts
• Page 1 of 2 • 1, 2
Re: const / readonly member
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).
class X
get two as int is shared
return 2
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).
- Charles
- Posts: 2515
- Location: Los Angeles, CA
Re: const / readonly member
Anyone see any need for supporting const on local variables ?
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'
also providing this capability in either form (on local variables) confounded by bug from ticket:34
- 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
- hopscc
- Posts: 632
- Location: New Plymouth, Taranaki, New Zealand
Re: const / readonly member
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">
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:
class Foo
final a = 3.0 is shared # eq. to "const" in C#
final b = 4 # eq. to "readonly" in C#
final c = "foo" is shared # eq. to "static readonly"
final b = "bar" # eq. to "readonly"
class Test
def main is shared
final i = 0 # eq. to "const"
final str = "foo" # eq. to "const"
i = 1 # error
str = "bar" # error
Foo.a = 4.0 # error
Foo.c = "" # error
f = Foo()
f.b = 3.0 # error
f.d = "" # error
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">
- jonathandavid
- Posts: 159
Re: const / readonly member
Hi
I would prefer just
For me these examples ar obvious.
Regards
Csaba
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
- Csaba
- Posts: 42
Re: const / readonly member
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:
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
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
- hopscc
- Posts: 632
- Location: New Plymouth, Taranaki, New Zealand
Re: const / readonly member
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.
foo = MyLib.MyClass.Limit
# then if Limit is a const, the compiler does this:
foo = 100
# if Limit is a readonly, the compiler does this:
foo = <value of Limit in MyLib.MyClass.Limit at load time>
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.
- Charles
- Posts: 2515
- Location: Los Angeles, CA
Re: const / readonly member
what about simply using "val" for value?
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)
- 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)
- natter
- Posts: 20
Re: const / readonly member
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
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
Last edited by Csaba on Sun Feb 15, 2009 7:56 am, edited 2 times in total.
- Csaba
- Posts: 42
12 posts
• Page 1 of 2 • 1, 2
Who is online
Users browsing this forum: No registered users and 43 guests