Fixing const arrays

[Regan Heath]

On Wed, 14 Dec 2011 13:50:09 -0000, Michel Fortin  
<michel.fortin at michelf.com> wrote:

> On 2011-12-14 13:27:57 +0000, "Regan Heath" <regan at netmail.co.nz> said:
>
>> On Wed, 14 Dec 2011 02:36:43 -0000, Michel Fortin
>> <michel.fortin at michelf.com> wrote:
>>
>>> By "code patterns", you mean something like this?
>>>  	struct Foo
>>> 	{
>>> 		int getBar();
>>> 		void setBar(int);
>>> 	}
>>>  	void main()
>>> 	{
>>> 		Foo foo;
>>> 		int a = foo.bar;  // calls getBar()
>>> 		foo.bar = a;      // calls setBar(a)
>>> 	}
>>  Why not something similar to C# syntax...
>
> I know the basics of the C# property syntax, but how do you take the  
> address of the getter with it?

I hadn't given this a lot of thought.  But, here goes.. :)

The compiler (whatever the syntax used) will generate the get/set  
functions internally.  So, it will technically be possible to take the  
address of both the getter and setter.

Using my suggested syntax there is only 1 property name 'bar' and  
typically the function called is determined by the usage, e.g.

Foo foo;
int a = foo.bar; // getter called
foo.bar = 4;     // setter called

So, what happens when we take the address..

Foo foo;
int delegate(void) getter = &foo.bar;  // takes the address of the getter
void delegate(in) setter = &foo.bar;   // takes the address of the setter

I think that works, what do you reckon?

> And how do you define array-member properties like you can do with  
> functions?

I don't think we should call these "properties".  What we're actually  
doing is adding members to built in types which can have any number of  
arguments and are therefore they're not strictly "properties".  I think  
part of the confusion around properties comes from conflating these two  
ideas into one and calling them both "properties".

> And how do you disambiguate access those array members properties if two  
> imported modules define a property with the same name for an array?

I'd like to split the "adding array members" feature away from  
"properties" and look at it again, specifically due to problem cases like  
this.  For example, in this case we could require the use of () for  
"adding array members" while for actual properties (user defined, on user  
defined types, using a c# like syntax or similar) we could require () not  
to be used.  I think that pretty much avoids the whole can of worms,  
doesn't it?

Regan

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/