Mon, 3 Aug 2009 22:04:51 -0400, Nick Sabalausky wrote:

> It's been established in the recent epic-discussions on properties that one of the biggest uses for properties is to implement publically read-only (but privately-writable) fields. That got me thinking, why not actually have real publically read-only fields instead of merely emulating them with properties? They are, after all, a fairly common idiom.
> 
> // *Not* an actual syntax proposal, but just to get the idea across:
> 
> private @publicread int foo;
> 
> // The class sees it as "int", but everything else sees it as "const(int)" // ...or something like that...

Um... @publiconst? XD

or

private int foo;
public alias const foo foo;

or even

private public(const) int foo;

Weird...  OTOH this should be trivial from the implementation POV.  On the even other hand this only worth considering if actual properties are dropped because properties are more generic and you *can* implement a read-only field with them.  Maybe some syntactic sugar is in order if it really is such a common thing.

Sergey Gromov Wrote:

> Mon, 3 Aug 2009 22:04:51 -0400, Nick Sabalausky wrote:
> 
> > It's been established in the recent epic-discussions on properties that one of the biggest uses for properties is to implement publically read-only (but privately-writable) fields. That got me thinking, why not actually have real publically read-only fields instead of merely emulating them with properties? They are, after all, a fairly common idiom.
> > 
> > // *Not* an actual syntax proposal, but just to get the idea across:
> > 
> > private @publicread int foo;
> > 
> > // The class sees it as "int", but everything else sees it as "const(int)" // ...or something like that...
> 
> Um... @publiconst? XD
> 
> or
> 
> private int foo;
> public alias const foo foo;
> 
> or even
> 
> private public(const) int foo;
> 
> Weird...  OTOH this should be trivial from the implementation POV.  On the even other hand this only worth considering if actual properties are dropped because properties are more generic and you *can* implement a read-only field with them.  Maybe some syntactic sugar is in order if it really is such a common thing.

I like the idea. Writing a property requires more code, which is not essential. I think there can be many constructs. I don't know if private public(const) is easily parsed by the compiler though. perhaps this construct is:

pragma(read: const) private int foo;

otherwise a new keyword is necessary I think.

access(public, private) int foo;

Where the first parameter is the read situation, and the second parameter is the write situation. Or perhaps more verbose:

access(read: public, write: private) int foo;

Or maybe even better:

access(immutable: public, const: protected, mutable: private) int foo;

Meaning: everyone is able to read foo, subclasses can write to internal structures, but not change the object and only the object itself has full write access.

Just my 2 ct

Sergey Gromov schrieb:
> Mon, 3 Aug 2009 22:04:51 -0400, Nick Sabalausky wrote:
> 
>> It's been established in the recent epic-discussions on properties that one of the biggest uses for properties is to implement publically read-only (but privately-writable) fields. That got me thinking, why not actually have real publically read-only fields instead of merely emulating them with properties? They are, after all, a fairly common idiom.
>>
>> // *Not* an actual syntax proposal, but just to get the idea across:
>>
>> private @publicread int foo;
>>
>> // The class sees it as "int", but everything else sees it as "const(int)"
>> // ...or something like that...
> 
> Um... @publiconst? XD
> 
> or
> 
> private int foo;
> public alias const foo foo;
> 
> or even
> 
> private public(const) int foo;
> 
> Weird...  OTOH this should be trivial from the implementation POV.  On
> the even other hand this only worth considering if actual properties are
> dropped because properties are more generic and you *can* implement a
> read-only field with them.  Maybe some syntactic sugar is in order if it
> really is such a common thing.

Sounds good. Although I would like to keep the possibility that functions can be used as properties because there are cases when it's desirable. E.g:
---
class Clock {
	private int sec_;
	void sec(int s) {sec_ = s;}
	int sec() {return sec_;}
	void min(int m) {sec_ = m * 60;}
	int min() {return sec_ / 60;}
}
---
Here, only the "sec" property has a variable but "min" can be called the same way. Suppose you want to store the time in minutes later. When you are allowed to have wrapper properties like this it's easier to change because it looks the same from the outside. And it's more consistent, so  coders don't have to think about what property was a function and what was a variable.
Often though, they are just trivial functions like "sec" here. For that case, it is reasonable to have a shorter form.

Reply to Nick,

> It's been established in the recent epic-discussions on properties
> that one of the biggest uses for properties is to implement publically
> read-only (but privately-writable) fields. That got me thinking, why
> not actually have real publically read-only fields instead of merely
> emulating them with properties? They are, after all, a fairly common
> idiom.
> 
> // *Not* an actual syntax proposal, but just to get the idea across:
> 
> private @publicread int foo;
> 
> // The class sees it as "int", but everything else sees it as
> "const(int)" // ...or something like that...
> 

how about this for a syntax:

private int i;
alias public const i;