I'm unsure on the exact syntax, but how to you resolve the following:

struct x {
	int size;
	int something_else;
};

// Which one is this?
struct x X;
int i = X.size;


Maybe structs do not have size?  In any case, I think that using the "." for both member access, and attribute access is not a really good idea.  Maybe "->" would be a better idea?  In that case you make pointer derefference (reference?) explicit:

struct x *Y = &X;

Then:
Y.size == sizeof(pointer)
(*Y).size == abiguous (same as above)


But if "->" is for attributes, then:

(*Y)->size and (*Y).size are different, as are
Y->size and Y.size (one of which is an error).

-- 
Tobias Weingartner |        Unix Guru, Admin, Systems-Dude
Apt B 7707-110 St. |        http://www.tepid.org/~weingart/
Edmonton, AB       |-------------------------------------------------
Canada, T6G 1G3    | %SYSTEM-F-ANARCHISM, The OS has been overthrown

Tobias Weingartner wrote:

> I'm unsure on the exact syntax, but how to you resolve the following:
> 
> struct x {
> 	int size;
> 	int something_else;
> };
> 
> // Which one is this?
> struct x X;
> int i = X.size;
> 
> 
> Maybe structs do not have size?  In any case, I think that using the
> "." for both member access, and attribute access is not a really good
> idea.  Maybe "->" would be a better idea?  In that case you make pointer
> derefference (reference?) explicit:
> 
> struct x *Y = &X;
> 
> Then:
> Y.size == sizeof(pointer)
> (*Y).size == abiguous (same as above)
> 
> 
> But if "->" is for attributes, then:
> 
> (*Y)->size and (*Y).size are different, as are
> Y->size and Y.size (one of which is an error).
> 
> 

Ada used the single forward tic mark (') for
accessing attributes... and it's sufficiently different from
any OTHER operator that C or C++ has to be noticed.

Other good potential characters would be '@' or maybe '#',
although if D supports a preprocessor with #if/#else/etc
it might get confusing, but I don't think so.

Regards,

Matt

In article <3B7C1784.7060104@aiinet.com>, Matt Gessner wrote:
> 
> Ada used the single forward tic mark (') for
> accessing attributes... and it's sufficiently different from
> any OTHER operator that C or C++ has to be noticed.
> 
> Other good potential characters would be '@' or maybe '#',
> although if D supports a preprocessor with #if/#else/etc
> it might get confusing, but I don't think so.

Other options exist.  Since __name is reserved, attributes could be made to exist within that "namespace".  So instead of x.size, you would have x.__size.


-- 
Tobias Weingartner |        Unix Guru, Admin, Systems-Dude
Apt B 7707-110 St. |        http://www.tepid.org/~weingart/
Edmonton, AB       |-------------------------------------------------
Canada, T6G 1G3    | %SYSTEM-F-ANARCHISM, The OS has been overthrown

Tobias Weingartner wrote:
> 
> I'm unsure on the exact syntax, but how to you resolve the following:
> 
> struct x {
>         int size;
>         int something_else;
> };
> 
> // Which one is this?
> struct x X;
> int i = X.size;
> 
> Maybe structs do not have size?  In any case, I think that using the "." for both member access, and attribute access is not a really good idea.  Maybe "->" would be a better idea?  In that case you make pointer derefference (reference?) explicit:

No ambiguity.  You just can't make a variable called "size" as part of a struct since it would now be a reserved keyword.

Chris


-- 
Chris Friesen                    | MailStop: 043/33/F10
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

In article <3B7C22EE.21ED6889@nortelnetworks.com>, Chris Friesen wrote:
> 
> No ambiguity.  You just can't make a variable called "size" as part of a struct since it would now be a reserved keyword.

I don't particularly like that idea.  A certain number of key words make the language easier to write, but having keywords for every possible attribute is not nice.  (nan, inf, sign, ...)

-- 
Tobias Weingartner |        Unix Guru, Admin, Systems-Dude
Apt B 7707-110 St. |        http://www.tepid.org/~weingart/
Edmonton, AB       |-------------------------------------------------
Canada, T6G 1G3    | %SYSTEM-F-ANARCHISM, The OS has been overthrown

Tobias Weingartner wrote in message ...
>I'm unsure on the exact syntax, but how to you resolve the following: struct x {
> int size;
> int something_else;
>};


No ; after }


>// Which one is this?
>struct x X;


Should be:
    x X;

>int i = X.size;


Both x.size and X.size will give the same result.

Oops, now I see what you were driving at. size is not a reserved word. If you have a member named size, it will override the size property.

Walter wrote in message <9m26sb$1qmj$1@digitaldaemon.com>...
>
>Tobias Weingartner wrote in message ...
>>I'm unsure on the exact syntax, but how to you resolve the following: struct x {
>> int size;
>> int something_else;
>>};
>
>
>No ; after }
>
>
>>// Which one is this?
>>struct x X;
>
>
>Should be:
>    x X;
>
>>int i = X.size;
>
>
>Both x.size and X.size will give the same result.
>
>
>

In article <9m27fb$1r13$1@digitaldaemon.com>, Walter wrote:
> 
> Oops, now I see what you were driving at. size is not a reserved word. If you have a member named size, it will override the size property.

In that case I would push for properties to be prefixed by _, such that they are in the "reserved" space.  If someone overrides them, they have been warned, or they know what they are doing.

--Toby.

Tobias Weingartner wrote:
> 
> In article <9m27fb$1r13$1@digitaldaemon.com>, Walter wrote:
> >
> > Oops, now I see what you were driving at. size is not a reserved word. If you have a member named size, it will override the size property.
> 
> In that case I would push for properties to be prefixed by _, such that they are in the "reserved" space.  If someone overrides them, they have been warned, or they know what they are doing.
> 
> --Toby.

	I don't exactly second this implementation, but I agree with the
sentiment.  How about an alternate syntax for properties?  I would agree
with the '_' prefix as a minimal fix though.
	On the topic of ambiguities:

		char[] Key = "idontcare";
		assoc[Key] = new Thingy();
		delete assoc["Key"];

Am I deleting the Thingy, removing Key from assoc or both?

Dan

Dan Hursh wrote in message <3B85D3D7.DDF4B79B@infonet.isl.net>...
> I don't exactly second this implementation, but I agree with the
>sentiment.  How about an alternate syntax for properties?  I would agree with the '_' prefix as a minimal fix though.


Think of it as members overriding properties of some hypothetical base class.

> On the topic of ambiguities:
>
> char[] Key = "idontcare";
> assoc[Key] = new Thingy();
> delete assoc["Key"];
>
>Am I deleting the Thingy, removing Key from assoc or both?


Good question. I don't have an answer at the moment!