"Matthew" wrote:

> Please no. Let's just have a simple syntax
[...]

Because I just reinvented that D has the bitweise toggle operator `^' I dare a suggestion for the syntax

  array ^ key

with the semantics, that the key is inserted into the array if not already present and deleted otherwise. The return value is true if the key exists after the operation and false otherwise.

This can yield to expressions loved by C-ish programmers and aversed by pascalean:

  key in array && array ^ key && assert(0);

And because we are at it: why introduces the keyword assert an expression but the keyword throw a statement? Why is it useful to be pressed to use an `ìf' together with the `throw', when refining the rather primitive `assert' by thrown exceptions?

And if it is useful to change the `throw' statement to a void expression, why dont hold the same arguments of usefulness for the other non declarative statements?

-manfred

This may be a dumb question, but *currently*, what's the best way to actually remove the element from the AA?

-Kramer

In article <ct5f71$1eb5$1@digitaldaemon.com>, Ben Hinkle says...
>
>
>"Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:ct4hj6$8s8$3@digitaldaemon.com...
>> Please no. Let's just have a simple syntax, like, er,
>>
>>    aa.remove(key);
>
>This gets my vote.
>
>Currently arrays only have properties so it would be the only array operation with a member function but it is less confusing than anything else. It is better to keep the semantics of "delete" consistent than preserve the fact that arrays have no member functions.
>
>

Fair enough, Parabolis.

Perhaps a reasonable criterion for core/non-core would be whether or not the functionality should be sensibly overridden or augmented?

Walter has gone to great pains to allow operator overloading, and to treat class methods as extended-attributes (to some degree), yet things like .sort and AAs are not customizable in the same manner: for example, you have to abandon the syntax completely to apply a different kind of sorting algorithm. In contrast, one can override most of the basic operators. That's asymmetrical.

If Array behaviour/properties were overridable (akin to class methods) then things might be cleaner. What if the 'array' type were actually a pre-defined class or struct? This is similar to the notion of other native-types being represented by a struct, such that one can augment their properties also. This idea has been bounced around before.

It'd certainly be more interesting :-)



In article <ct51ua$t7h$1@digitaldaemon.com>, parabolis says...
>
>Kris wrote:
>
>> None of these AA issues would be apparent, or they would be trivial to change, if the functionality were exposed via a library rather than being part of the language proper. Building this kind of thing into the language spec is where Pascal went wrong (in the commercial world -- it was great for its intended purpose). K & R 'recognized' this and placed all non-core facilities into a library instead. A similar notion is applied to O/S kernels, and so on, ad nauseum.
>
>We can indeed move *everything* out to a library and be left with expressions like:
>   opAssign(x, opAdd(1, opMul(2*3)));
>Then we can use infix notation to make parsing easy and end up with the strangly familiar:
>   (setq x (+ 1 (* 2 3)))
>
>With that said let me say lisp people would say K&R missed the boat if their goal was to put 'non-core facilities' into the library. Core vs non-core has nothing to do with the issue in my opinion. I think the real issue is what can we add to the language to make it easier for programmers.
>
>I have seen Walter mention elsewhere his suprise at how interwoven all the language elements are with each other. Adding something to a language like C should be viewed as a fairly drastic step which is only undertaken with care.
>
>I can imagine three criterion for language addition (I would not be suprised if I could be convinced there are some I missed):
>
>(1) A proposed addition should be a frequent case of use.
>(2) The syntax and semantics should already be familiar.
>(3) The actual syntax should fit nicely within existing syntax.
>
>I believe AAs satisfy (1) and (2) but stumbles slightly on (3).
>
>(1) is fairly obviously satisfied as hash tables are data structures with nice properties and thus are already frequently in use.
>
>(2) is satisfied as hash tables are indexed on the hash of a key meaning that considering them an array indexed by the key itself fits in nicely with both array index notation and hash table notions.
>
>(3) only seems to stumble on the new and .length syntax and does pretty well with insertion and removal. Deleting the Ith element of an array of objects should delete the element's value. It should be possible to specify the size of an AA as would would with a normal array -- especially if one knows exactly how many things one will expect it to hold or how many more it will need to hold.

I second the opinion that status quo must be changed. Kris' suggestion below is the one I've liked best sofar. Pending peeve (or at least it should be).

Lars Ivar Igesund

Kris wrote:
> Fair enough, Parabolis.
> 
> Perhaps a reasonable criterion for core/non-core would be whether or not the
> functionality should be sensibly overridden or augmented?
> 
> Walter has gone to great pains to allow operator overloading, and to treat class
> methods as extended-attributes (to some degree), yet things like .sort and AAs
> are not customizable in the same manner: for example, you have to abandon the
> syntax completely to apply a different kind of sorting algorithm. In contrast,
> one can override most of the basic operators. That's asymmetrical.
> 
> If Array behaviour/properties were overridable (akin to class methods) then
> things might be cleaner. What if the 'array' type were actually a pre-defined
> class or struct? This is similar to the notion of other native-types being
> represented by a struct, such that one can augment their properties also. This
> idea has been bounced around before.
> 
> It'd certainly be more interesting :-)
> 
> 
> 
> In article <ct51ua$t7h$1@digitaldaemon.com>, parabolis says...
> 
>>Kris wrote:
>>
>>
>>>None of these AA issues would be apparent, or they would be trivial to change,
>>>if the functionality were exposed via a library rather than being part of the
>>>language proper. Building this kind of thing into the language spec is where
>>>Pascal went wrong (in the commercial world -- it was great for its intended
>>>purpose). K & R 'recognized' this and placed all non-core facilities into a
>>>library instead. A similar notion is applied to O/S kernels, and so on, ad
>>>nauseum.
>>
>>We can indeed move *everything* out to a library and be left with expressions like:
>>  opAssign(x, opAdd(1, opMul(2*3)));
>>Then we can use infix notation to make parsing easy and end up with the strangly familiar:
>>  (setq x (+ 1 (* 2 3)))
>>
>>With that said let me say lisp people would say K&R missed the boat if their goal was to put 'non-core facilities' into the library. Core vs non-core has nothing to do with the issue in my opinion. I think the real issue is what can we add to the language to make it easier for programmers.
>>
>>I have seen Walter mention elsewhere his suprise at how interwoven all the language elements are with each other. Adding something to a language like C should be viewed as a fairly drastic step which is only undertaken with care.
>>
>>I can imagine three criterion for language addition (I would not be suprised if I could be convinced there are some I missed):
>>
>>(1) A proposed addition should be a frequent case of use.
>>(2) The syntax and semantics should already be familiar.
>>(3) The actual syntax should fit nicely within existing syntax.
>>
>>I believe AAs satisfy (1) and (2) but stumbles slightly on (3).
>>
>>(1) is fairly obviously satisfied as hash tables are data structures with nice properties and thus are already frequently in use.
>>
>>(2) is satisfied as hash tables are indexed on the hash of a key meaning that considering them an array indexed by the key itself fits in nicely with both array index notation and hash table notions.
>>
>>(3) only seems to stumble on the new and .length syntax and does pretty well with insertion and removal. Deleting the Ith element of an array of objects should delete the element's value. It should be possible to specify the size of an AA as would would with a normal array -- especially if one knows exactly how many things one will expect it to hold or how many more it will need to hold.
> 
> 
> 

Kramer wrote:

> This may be a dumb question, but *currently*, what's the best way
> to actually remove the element from the AA?

The *only* way at the momement to remove an element is:

	delete b["hello"];

> This confusingly appears to delete the value of b["hello"], but
> does not, it removes the key "hello" from the associative array.

See http://www.digitalmars.com/d/arrays.html#associative

--anders

"Kramer" <Kramer_member@pathlink.com> wrote in message news:ct61cu$24em$1@digitaldaemon.com...
> This may be a dumb question, but *currently*, what's the best way to
> actually
> remove the element from the AA?
>
> -Kramer
[snip]
>>    aa.remove(key);
[snip]

Currently
  delete aa[key]
is the only way to remove an an element. See
http://www.digitalmars.com/d/arrays.html#associative

"Anders F Björklund" <afb@algonet.se> wrote in message news:ct692r$2dju$1@digitaldaemon.com...
> Kramer wrote:
>
>> This may be a dumb question, but *currently*, what's the best way to actually remove the element from the AA?
>
> The *only* way at the momement to remove an element is:
>
> delete b["hello"];
>
>> This confusingly appears to delete the value of b["hello"], but does not, it removes the key "hello" from the associative array.
>
> See http://www.digitalmars.com/d/arrays.html#associative
>
> --anders
>

heh - you beat me by 1 minute and our messages are almost identical. freaky! :-)

"Kris" <Kris_member@pathlink.com> wrote in message news:ct63md$27eb$1@digitaldaemon.com...
> Fair enough, Parabolis.
>
> Perhaps a reasonable criterion for core/non-core would be whether or not
> the
> functionality should be sensibly overridden or augmented?
>
> Walter has gone to great pains to allow operator overloading, and to treat
> class
> methods as extended-attributes (to some degree), yet things like .sort and
> AAs
> are not customizable in the same manner: for example, you have to abandon
> the
> syntax completely to apply a different kind of sorting algorithm. In
> contrast,
> one can override most of the basic operators. That's asymmetrical.

One can define a class or struct with a ".sort" property that does whatever one wants just as one can write a class or struct with an opAdd overload that does whatever one wants. Seems symmetrical to me. You can't overload what + does on two ints so it isn't unusual to force people to make a custom type to get "non-standard" behavior. Enhancements to the .sort behavior (like the ability to customize the sort algorithm somehow) of AAs can wait for post 1.0 IMO but something like the syntax for removing elements should be finalized by 1.0. Anyway, one can always write a sort function and call it directly.

[snip]

Kris wrote:
> Fair enough, Parabolis.
> 
> Perhaps a reasonable criterion for core/non-core would be whether or not the
> functionality should be sensibly overridden or augmented?

I think that fits a hole in (2) nicely so I would have to agree.

>   b.delete("hello");

I think this would be the most logical syntax, as it would simply be another property of associative arrays (rather than some complex and hard-to-parse syntax like "in b delete "hello").  Of course, using D's funky property syntax, it could also be written:

b.delete="hello";

 ;)