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

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.)

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!

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

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.

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;

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.

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;
>

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;
>>

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