www.digitalmars.com         C & C++   DMDScript  

D - Ambiguities?

reply weingart cs.ualberta.ca (Tobias Weingartner) writes:
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 
Aug 16 2001
next sibling parent reply Matt Gessner <mattg aiinet.com> writes:
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. although if D supports a preprocessor with #if/#else/etc it might get confusing, but I don't think so. Regards, Matt
Aug 16 2001
parent weingart cs.ualberta.ca (Tobias Weingartner) writes:
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.
 

 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
Aug 16 2001
prev sibling next sibling parent reply Chris Friesen <cfriesen nortelnetworks.com> writes:
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
Aug 16 2001
parent weingart cs.ualberta.ca (Tobias Weingartner) writes:
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
Aug 16 2001
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
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.
Aug 23 2001
parent reply "Walter" <walter digitalmars.com> writes:
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.
Aug 23 2001
parent reply weingart cs.ualberta.ca (Tobias Weingartner) writes:
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.
Aug 23 2001
parent reply Dan Hursh <hursh infonet.isl.net> writes:
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
Aug 23 2001
parent reply "Walter" <walter digitalmars.com> writes:
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!
Aug 24 2001
next sibling parent reply Russell Bornschlegel <kaleja estarcion.com> writes:
Walter wrote:
 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!
Yeah, I didn't like the use of "delete" for the assoc-array removal operation. But on the other hand, it would seem like assoc["key"] is a reference to the Thingy; if delete only deleted the Thingy, without removing the entry from assoc[], you'd have a dangling reference; if it only removed the reference and left the object, the GC would eventually clear it. The question of when GC gets run is still under debate, but it seems like the eventual end result is "both" -- the key/entry in assoc and the Thingy are both destroyed in the end. -RB
Aug 24 2001
next sibling parent Charles Hixson <charleshixsn earthlink.net> writes:
Russell Bornschlegel wrote:
 Walter wrote:
 
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!
Yeah, I didn't like the use of "delete" for the assoc-array removal operation. But on the other hand, it would seem like assoc["key"] is a reference to the Thingy; if delete only deleted the Thingy, without removing the entry from assoc[], you'd have a dangling reference; if it only removed the reference and left the object, the GC would eventually clear it. The question of when GC gets run is still under debate, but it seems like the eventual end result is "both" -- the key/entry in assoc and the Thingy are both destroyed in the end. -RB
Are you certain that there are no other references to it? ... But then that's the point, isn't it. The safe thing for the compiler to do is to null the reference, and let the garbage collector clean up. But that may not be the time efficient way to go. (Or at least it could cause the program to become dreamy every once in awhile.)
Aug 24 2001
prev sibling next sibling parent Russ Lewis <russ deming-os.org> writes:
Russell Bornschlegel wrote:

 Yeah, I didn't like the use of "delete" for the assoc-array
 removal operation.

 But on the other hand, it would seem like assoc["key"] is a reference
 to the Thingy; if delete only deleted the Thingy, without removing
 the entry from assoc[], you'd have a dangling reference; if it only
 removed the reference and left the object, the GC would eventually
 clear it. The question of when GC gets run is still under debate,
 but it seems like the eventual end result is "both" -- the key/entry
 in assoc and the Thingy are both destroyed in the end.
This comes back to a discussion about garbage collection. IMHO, delete doesn't make any sense in a garbage-collected language. The delete should be implicit when the last reference disappears. Thus, I would argue that you shouldn't use delete to remove objects from an associative array. It's a good keyword, but too likely to be confused with C++ delete. Perhaps you could use 'remove': remove array["key"]; I just had an idea about GC...but to keep this (relatively) on-topic, I'll post it there instead of here.
Sep 06 2001
prev sibling next sibling parent "Sean L. Palmer" <spalmer iname.com> writes:
"Russell Bornschlegel" <kaleja estarcion.com> wrote in message
news:3B861237.731DCE02 estarcion.com...
 Walter wrote:
 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!
Yeah, I didn't like the use of "delete" for the assoc-array removal operation. But on the other hand, it would seem like assoc["key"] is a reference to the Thingy; if delete only deleted the Thingy, without removing the entry from assoc[], you'd have a dangling reference; if it only removed the reference and left the object, the GC would eventually clear it. The question of when GC gets run is still under debate, but it seems like the eventual end result is "both" -- the key/entry in assoc and the Thingy are both destroyed in the end. -RB
Oct 16 2001
prev sibling parent reply "Sean L. Palmer" <spalmer iname.com> writes:
"Russell Bornschlegel" <kaleja estarcion.com> wrote in message
news:3B861237.731DCE02 estarcion.com...
 Walter wrote:
 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!
Yeah, I didn't like the use of "delete" for the assoc-array removal operation. But on the other hand, it would seem like assoc["key"] is a reference to the Thingy; if delete only deleted the Thingy, without removing the entry from assoc[], you'd have a dangling reference; if it only removed the reference and left the object, the GC would eventually clear it. The question of when GC gets run is still under debate, but it seems like the eventual end result is "both" -- the key/entry in assoc and the Thingy are both destroyed in the end. -RB
Oopsie, sent off too soon. How would you then go about removing the item from the associative array without destroying the object? For instance if it were still referenced by some other array? What about something like: assoc ~["Key"]; // remove from array Sean
Oct 16 2001
parent reply Russell Borogove <kaleja estarcion.com> writes:
"Sean L. Palmer" wrote:
 How would you then go about removing the item from the associative array
 without destroying the object?  For instance if it were still referenced by
 some other array?
 
 What about something like:
 
 assoc ~["Key"]; // remove from array
I believe the current D-canonical method of doing this is: assoc[ "Key" ] = NULL; This unlinks the element at "Key" from the associative array. If there are no other references to the element, eventually the GC will destroy it. -RB
Oct 16 2001
next sibling parent reply "Sean L. Palmer" <spalmer iname.com> writes:
 How would you then go about removing the item from the associative array
 without destroying the object?  For instance if it were still referenced
by
 some other array?

 What about something like:

 assoc ~["Key"]; // remove from array
I believe the current D-canonical method of doing this is: assoc[ "Key" ] = NULL; This unlinks the element at "Key" from the associative array. If there are no other references to the element, eventually the GC will destroy it. -RB
That sounds much better. Question: is D case-sensitive? If it is, can I request that if there's a NULL keyword that it be lowercase like all the other keywords? Sean
Oct 18 2001
parent Russell Borogove <kaleja estarcion.com> writes:
"Sean L. Palmer" wrote:
 Question:  is D case-sensitive?  If it is, can I request that if there's a
 NULL keyword that it be lowercase like all the other keywords?
It's case sensitive. According to: http://www.digitalmars.com/d/lex.html the keyword is in fact spelled "null" rather than "NULL". -RB
Oct 18 2001
prev sibling parent reply a <a b.c> writes:
Russell Borogove wrote:
 
 "Sean L. Palmer" wrote:
 How would you then go about removing the item from the associative array
 without destroying the object?  For instance if it were still referenced by
 some other array?

 What about something like:

 assoc ~["Key"]; // remove from array
I believe the current D-canonical method of doing this is: assoc[ "Key" ] = NULL; This unlinks the element at "Key" from the associative array. If there are no other references to the element, eventually the GC will destroy it. -RB
So you can have a key that references a null pointer? Or is it assumed that all possible keys are in every associative array be they "default" to null. If so, does that mean there is no way to differentiate between key that have null assigned to them and keys that were never defined or were meant to be undefined? Dan
Oct 18 2001
parent reply Russell Borogove <kaleja estarcion.com> writes:
a wrote:
 
 Russell Borogove wrote:
 I believe the current D-canonical method of doing this is:

  assoc[ "Key" ] = NULL;

 This unlinks the element at "Key" from the associative array. If
 there are no other references to the element, eventually the
 GC will destroy it.
So you can have a key that references a null pointer? Or is it assumed that all possible keys are in every associative array be they "default" to null. If so, does that mean there is no way to differentiate between key that have null assigned to them and keys that were never defined or were meant to be undefined?
Hmm, let me weasel a bit; according to the current online spec, we are supposed to: delete assoc[ "Key" ]; rather than: assoc[ "Key" ] = null; ...though I don't know if Walter has nailed this down yet, due to some uncertainty about whether "delete" should have GC-hazardous semantics, or whether it should encourage a GC recovery pass, or whether it should simply unlink a reference. Anyway, if "delete" has some semantics beyond simply unlinking, then we want some way of simply unlinking, for which the null assignment seems appropriate. For the null assignment, my expectation would be that makes the element of the associative array act as if it had never been defined. The spec is currently silent on what happens if you do: int[ char[] ] assoc; // string-to-int mapping // assoc is virginal, all undefined assert (!("Key" in assoc)); int result = assoc[ "Key" ]; In my opinion, whatever happens here should also happen in this case: assoc[ "Key" ] = 99; assoc[ "Key" ] = null; // undefine it, not assign integer 0 to it int result = assoc[ "Key" ]; *whew* Does that make sense? -RB
Oct 19 2001
parent reply a <a b.c> writes:
Russell Borogove wrote:
 Hmm, let me weasel a bit; according to the current online spec, we
 are supposed to:
 
    delete assoc[ "Key" ];
 
 rather than:
 
    assoc[ "Key" ] = null;
 
 ...though I don't know if Walter has nailed this down yet, due
 to some uncertainty about whether "delete" should have GC-hazardous
 semantics, or whether it should encourage a GC recovery pass, or
 whether it should simply unlink a reference.
 
 Anyway, if "delete" has some semantics beyond simply unlinking,
 then we want some way of simply unlinking, for which the null
 assignment seems appropriate.
 
 For the null assignment, my expectation would be that makes the
 element of the associative array act as if it had never been
 defined. The spec is currently silent on what happens if you do:
 
    int[ char[] ] assoc;   // string-to-int mapping
 
    // assoc is virginal, all undefined
 
    assert (!("Key" in assoc));
 
    int result = assoc[ "Key" ];
 
 In my opinion, whatever happens here should also happen in this
 case:
 
    assoc[ "Key" ] = 99;
    assoc[ "Key" ] = null;  // undefine it, not assign integer 0 to it
    int result = assoc[ "Key" ];
 
 *whew* Does that make sense?
Sure. So we'll never want to differentiate between an undefined value and a value defined to Zero. There is no difference between a value explicitly defined to be zero and one the programmer forgot/neglected to set. That also means that ("Key" in assoc) == (assoc["Key"] != null). Guess we don't need that in keyword anymore. BTW, what is the floating point equivalent to null? Zero or NaN? The default value for a float is NaN, however it seems odd that you can store a floating point zero in an associative array, but you cannot store an integer zero. Seems almost arbitrary. On the other hand, it would be odd for the default value of a float to be different in and associative array than in any other context. Making an assignment of zero revert to NaN would also be a bit rude. I will say that the inability to differentiate between zero and an undefined key could have adverse affects with regard to using an associative array as a form of symbol table. I do agree that reading from an undefined key should return the default value. I suppose some might thing that it ought to throw something. I could live with either, but I bet I'd find the default value use more often than a throw. I also agree that using an undefined Key as an lvalue should create and set it. Since there is no special syntax for creating a key, it seems there is nothing to argue against. This is the only way to create a key. If you want to throw when setting a key that isn't defined, you have to check. Personally, I have no problem here. I don't see a way around storing a meaningful zero and differentiating it from an oops though if they are equivalent. You'd have to have the overhead of a class or at least a pointer so you could have a meaningful zero. The ability to store a zero has to be trivial. You just have to have a way to tell if the value is defined (ala in) and to undefine it once it has been defined. That's where the delete ambiguity came in. Making null/zero assignment undefine the value seems like a nasty way to get around adding a keyword. You are trading functionalities here, not just conveniences like the example of how you handle accessing an undefined key. Dan
Oct 19 2001
parent Russell Borogove <kaleja estarcion.com> writes:
a wrote:
         Sure.  So we'll never want to differentiate between an undefined value
 and a value defined to Zero.  There is no difference between a value
 explicitly defined to be zero and one the programmer forgot/neglected to
 set.
         That also means that ("Key" in assoc) == (assoc["Key"] != null).  Guess
 we don't need that in keyword anymore.  BTW, what is the floating point
 equivalent to null?  Zero or NaN?  The default value for a float is NaN,
 however it seems odd that you can store a floating point zero in an
 associative array, but you cannot store an integer zero.  Seems almost
 arbitrary.  On the other hand, it would be odd for the default value of
 a float to be different in and associative array than in any other
 context.  Making an assignment of zero revert to NaN would also be a bit
 rude.
Nonono, that's not what I was suggesting at all -- a null reference is different from a reference to zero. You can store zero integers, or ((float)0x00000000), just fine. When the compiler sees an assignment of null (which is a keyword in D, rather than a macro evaluating to zero), it would have to generate the equivalent of a delete, rather than an assignment. And I don't know whether reading an undefined element should return a default or throw an exception. I'd lean towards throwing an exception. -RB
Oct 21 2001
prev sibling parent reply Dan Hursh <hursh infonet.isl.net> writes:
Walter wrote:
 
 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.
Does D have a sizeof operation other than the size style properties? If not this could really make life hard. Maybe a <type>.<property> expression? (I can't remember what the spec said.) Anyhow, if the only way to get the memory size is <var>.<property> then this could make life difficult of people using C structs that use a size member (or some other property) to mean something other than what D's property means. It could make generic programming absolutely impossible since C struct don't know there a D properties to walk all over. I do like the idea of been able to intentional override properties though. It rank right up there with operator overloading. (hint-hint) I'd hate for a property to be overridden by accident though. I like to live dangerously but I like to know I'm doing it. With operator overloads the user has to know how to do it to even do it wrong. With properties, newbies would have to know all the name of possible properties and make sure NOT to use them. Worse yet, the names you picked aren't exactly obscure word that no one would use as a member name. At least with the '_' prefix you would be using reserved identifiers. I think I would even prefer the information stored in properties to be presented by methods in a special module over this. Maybe you could use some other special infix operator? Pretty please. Dan
 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!
Aug 24 2001
parent reply "Walter" <walter digitalmars.com> writes:
Dan Hursh wrote in message <3B8728E1.3663996F infonet.isl.net>...
 Does D have a sizeof operation other than the size style properties?
No.
If not this could really make life hard.  Maybe a <type>.<property>
expression?  (I can't remember what the spec said.)
 Anyhow, if the only way to get the memory size is <var>.<property> then
this could make life difficult of people using C structs that use a size
member (or some other property) to mean something other than what D's
property means.  It could make generic programming absolutely impossible
since C struct don't know there a D properties to walk all over.
 I do like the idea of been able to intentional override properties
though.  It rank right up there with operator overloading.  (hint-hint)
I'd hate for a property to be overridden by accident though.  I like to
live dangerously but I like to know I'm doing it.  With operator
overloads the user has to know how to do it to even do it wrong.  With
properties, newbies would have to know all the name of possible
properties and make sure NOT to use them.  Worse yet, the names you
picked aren't exactly obscure word that no one would use as a member
name.
You brought up an interesting point I hadn't thought of. I'll have to think some more about this. -Walter
Aug 25 2001
next sibling parent Charles Hixson <charleshixsn earthlink.net> writes:
Walter wrote:
 Dan Hursh wrote in message <3B8728E1.3663996F infonet.isl.net>...
 
Does D have a sizeof operation other than the size style properties?
No.
If not this could really make life hard.  Maybe a <type>.<property>
expression?  (I can't remember what the spec said.)
Anyhow, if the only way to get the memory size is <var>.<property> then
this could make life difficult of people using C structs that use a size
member (or some other property) to mean something other than what D's
property means.  It could make generic programming absolutely impossible
since C struct don't know there a D properties to walk all over.
I do like the idea of been able to intentional override properties
though.  It rank right up there with operator overloading.  (hint-hint)
I'd hate for a property to be overridden by accident though.  I like to
live dangerously but I like to know I'm doing it.  With operator
overloads the user has to know how to do it to even do it wrong.  With
properties, newbies would have to know all the name of possible
properties and make sure NOT to use them.  Worse yet, the names you
picked aren't exactly obscure word that no one would use as a member
name.
You brought up an interesting point I hadn't thought of. I'll have to think some more about this. -Walter
Does the name applied to the structure variables in C necessarily match the name applied in D? Perhaps there could be an arbitrary mapping rule that translates s{n}ize to s{n+1}ize, i.e. size -> ssize, ssize -> sssize, etc. And something similar for any other reserved words.
Aug 27 2001
prev sibling parent reply Charles Jenkins <cjenkins tec-usa.com> writes:
On Sat, 25 Aug 2001 02:02:06 -0700, "Walter" 
<walter digitalmars.com> wrote:
 
 Dan Hursh wrote in message 
<3B8728E1.3663996F infonet.isl.net>...
 Does D have a sizeof operation other than the size style 
properties?
 
 
 No.
 
If not this could really make life hard.  Maybe a <type>.
<property>
expression?  (I can't remember what the spec said.)
 Anyhow, if the only way to get the memory size is <var>.
<property> then
this could make life difficult of people using C structs 
that use a size
member (or some other property) to mean something other 
than what D's
property means.  It could make generic programming 
absolutely impossible
since C struct don't know there a D properties to walk 
all over.
 I do like the idea of been able to intentional override 
properties
though.  It rank right up there with operator 
overloading. (hint-hint)
I'd hate for a property to be overridden by accident 
though. I like to
live dangerously but I like to know I'm doing it.  With 
operator
overloads the user has to know how to do it to even do it 
wrong. With
properties, newbies would have to know all the name of 
possible
properties and make sure NOT to use them.  Worse yet, the 
names you
picked aren't exactly obscure word that no one would use 
as a member
name.
You brought up an interesting point I hadn't thought of.
I'll have to think
 some more about this. -Walter
 
Please excuse me if this idea is naive, has already been hashed over, etc. What about NOT using the operator '.' to access the intrinsic properties like size that aren't really members. Just to make something up completely off the top of my head... int i = X#size;
Sep 06 2001
next sibling parent reply "Walter" <walter digitalmars.com> writes:
It's not naive, I'd just like to find a way to still use . !

Charles Jenkins wrote in message <1103_999808085 jenkins-lt>...
Please excuse me if this idea is naive, has already been
hashed over, etc. What about NOT using the operator '.' to
access the intrinsic properties like size that aren't really
members.

Just to make something up completely off the top of my
head...

  int  i = X#size;
Sep 07 2001
parent reply "Ben Cohen" <bc skygate.co.uk> writes:
How about  using 2 dots instead of one?

   int i = X..size;

This might clash with other uses of 2 dots (ranges), and I'm not sure I
like it.  Otherwise, you could use a colon (X:size) or dot and colon
(X.:size).

In article <9nc5sh$2933$3 digitaldaemon.com>, "Walter"
<walter digitalmars.com> wrote:

 It's not naive, I'd just like to find a way to still use . !
 
 Charles Jenkins wrote in message <1103_999808085 jenkins-lt>...
Please excuse me if this idea is naive, has already been hashed over,
etc. What about NOT using the operator '.' to access the intrinsic
properties like size that aren't really members.

Just to make something up completely off the top of my head...

  int  i = X#size;
Sep 10 2001
next sibling parent Russell Bornschlegel <kaleja estarcion.com> writes:
Ben Cohen wrote:
 
 How about  using 2 dots instead of one?
 
    int i = X..size;
 
 This might clash with other uses of 2 dots (ranges), and I'm not sure I
 like it.  Otherwise, you could use a colon (X:size) or dot and colon
 (X.:size).
I like the colon; it does lead to a potential problem with: foo = bar ? baz:size : bork:size; -RB
Sep 10 2001
prev sibling parent reply Axel Kittenberger <axel dtone.org> writes:
Ben Cohen wrote:

 How about  using 2 dots instead of one?
 
    int i = X..size;
Or how about, hmmmm .... hmmmm, .. brackets! int i = X.size(); - sometimes we're spinning in a circle, and don't even notice it's round.
Sep 10 2001
parent reply Russ Lewis <russ deming-os.org> writes:
Axel Kittenberger wrote:

 Ben Cohen wrote:

 How about  using 2 dots instead of one?

    int i = X..size;
Or how about, hmmmm .... hmmmm, .. brackets! int i = X.size(); - sometimes we're spinning in a circle, and don't even notice it's round.
Now we run into problems with properties if X is a class and size() is a gettor for that class... :( Not an easy problem to solve, it seems. I kind of like the .. syntax myself.
Sep 10 2001
next sibling parent reply "Walter" <walter digitalmars.com> writes:
I've been thinking of the ::, sort of like in C++ it means "use the global
version".

    x = ::foo;        // use global foo

Russ Lewis wrote in message <3B9D14D3.D0491D6F deming-os.org>...
Axel Kittenberger wrote:

 Ben Cohen wrote:

 How about  using 2 dots instead of one?

    int i = X..size;
Or how about, hmmmm .... hmmmm, .. brackets! int i = X.size(); - sometimes we're spinning in a circle, and don't even notice it's round.
Now we run into problems with properties if X is a class and size() is a gettor for that class... :( Not an easy problem to solve, it seems. I kind of like the .. syntax myself.
Sep 10 2001
parent reply "Ben Cohen" <bc skygate.co.uk> writes:
In article <9njv6d$jp9$1 digitaldaemon.com>, "Walter"
<walter digitalmars.com> wrote:

 I've been thinking of the ::, sort of like in C++ it means "use the
 global version".
 
     x = ::foo;        // use global foo
 
Does this clash with use of : for properties?
Sep 11 2001
parent reply "Walter" <walter digitalmars.com> writes:
Ben Cohen wrote in message <9nkkrl$110k$1 digitaldaemon.com>...
In article <9njv6d$jp9$1 digitaldaemon.com>, "Walter"
<walter digitalmars.com> wrote:

 I've been thinking of the ::, sort of like in C++ it means "use the
 global version".

     x = ::foo;        // use global foo
Does this clash with use of : for properties?
No, : is used for labels.
Sep 14 2001
parent reply "Ben Cohen" <bc skygate.co.uk> writes:
In article <9nt7au$2ohh$1 digitaldaemon.com>, "Walter"
<walter digitalmars.com> wrote:

 Ben Cohen wrote in message <9nkkrl$110k$1 digitaldaemon.com>...
In article <9njv6d$jp9$1 digitaldaemon.com>, "Walter"
<walter digitalmars.com> wrote:

 I've been thinking of the ::, sort of like in C++ it means "use the
 global version".

     x = ::foo;        // use global foo
Does this clash with use of : for properties?
No, : is used for labels.
Sorry, I should have said "would this clash..."
Sep 14 2001
parent "Walter" <walter digitalmars.com> writes:
Ben Cohen wrote in message <9nt8jh$2p5h$1 digitaldaemon.com>...
In article <9nt7au$2ohh$1 digitaldaemon.com>, "Walter"
<walter digitalmars.com> wrote:

 Ben Cohen wrote in message <9nkkrl$110k$1 digitaldaemon.com>...
In article <9njv6d$jp9$1 digitaldaemon.com>, "Walter"
<walter digitalmars.com> wrote:

 I've been thinking of the ::, sort of like in C++ it means "use the
 global version".

     x = ::foo;        // use global foo
Does this clash with use of : for properties?
No, : is used for labels.
Sorry, I should have said "would this clash..."
No, I don't think it would clash. -Walter
Sep 14 2001
prev sibling parent reply a <a b.c> writes:
Russ Lewis wrote:
 
 Axel Kittenberger wrote:
 
 Ben Cohen wrote:

 How about  using 2 dots instead of one?

    int i = X..size;
Or how about, hmmmm .... hmmmm, .. brackets! int i = X.size(); - sometimes we're spinning in a circle, and don't even notice it's round.
Now we run into problems with properties if X is a class and size() is a gettor for that class... :( Not an easy problem to solve, it seems.
Just don't make classes with methods that have the same name as properties. No ambiguity there. The problem was with struct that were originally designed in C. Either our name could not match the C API or would collide with D properties. C didn't have class or member functions and we aren't even binary compatible with C++. It's still sub-optimal, but it fixes the serious problem.
 I kind of like the
    ..
 syntax myself.
char[5] a ="01234"; int b = 0; int size = 5; a[b..size]; // What do ya think happens? First 4 or first 5? Dan
Sep 10 2001
next sibling parent "Ben Cohen" <bc skygate.co.uk> writes:
In article <3B9D8704.50B5A32 b.c>, "a" <a b.c> wrote:

 I kind of like the
    ..
 syntax myself.
char[5] a ="01234"; int b = 0; int size = 5; a[b..size]; // What do ya think happens? First 4 or first 5? Dan
Yes, that's the main problem with this syntax, namely that it clashes with range notation. But there is no particular reason why we have to use two dots for ranges (other than it's what Pascal uses). We could use *three* dots for ranges, but that would get confusing: a[b..size]; vs. a[b...size]; I was going to suggest using two minuses but it might be problematic, at least for programmers if not the compiler: a[b--size]; I think Python uses colons for ranges, which may work better (unless you'd prefer them for properties): a[b:size];
Sep 11 2001
prev sibling parent Russell Bornschlegel <kaleja estarcion.com> writes:
a wrote:
 
 Russ Lewis (maybe?) wrote:
 I kind of like the
    ..
 syntax myself.
char[5] a ="01234"; int b = 0; int size = 5; a[b..size]; // What do ya think happens? First 4 or first 5?
line 3, error, reserved word used as identifier. :) -Russell B
Sep 12 2001
prev sibling parent John English <je brighton.ac.uk> writes:
Charles Jenkins wrote:
 
 Please excuse me if this idea is naive, has already been
 hashed over, etc. What about NOT using the operator '.' to
 access the intrinsic properties like size that aren't really
 members.
 
 Just to make something up completely off the top of my
 head...
 
   int  i = X#size;
Ada uses ' (x'size); it complicates the lexical analyser a bit (not much though). Alternatively, how about x!size or x$size? Using ! as infix should be unambiguous, and I don't think $ is used eleswhere... ----------------------------------------------------------------- John English | mailto:je brighton.ac.uk Senior Lecturer | http://www.it.bton.ac.uk/staff/je Dept. of Computing | ** NON-PROFIT CD FOR CS STUDENTS ** University of Brighton | -- see http://burks.bton.ac.uk -----------------------------------------------------------------
May 17 2002