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