Jump to page: 1 2 3
Thread overview
[Confusion] delete is an operator
Jan 25, 2005
Manfred Nowak
Jan 25, 2005
Chris Sauls
Jan 25, 2005
Kris
Jan 25, 2005
Matthew
Jan 25, 2005
parabolis
Jan 25, 2005
parabolis
Jan 25, 2005
Kris
Jan 25, 2005
Lars Ivar Igesund
Jan 25, 2005
Ben Hinkle
Jan 25, 2005
parabolis
Jan 25, 2005
Matthew
Jan 25, 2005
Ben Hinkle
Jan 25, 2005
Kramer
Jan 25, 2005
Ben Hinkle
Jan 25, 2005
Ben Hinkle
Jan 25, 2005
Manfred Nowak
Jan 25, 2005
Matthew
Jan 26, 2005
Manfred Nowak
Jan 26, 2005
Matthew
[OT] Re: [Confusion] delete is an operator
Jan 26, 2005
Manfred Nowak
Jan 26, 2005
Matthew
Re: [OT][Confusion] delete is an operator
Jan 26, 2005
Manfred Nowak
Jan 27, 2005
Norbert Nemec
Jan 26, 2005
Norbert Nemec
Jan 26, 2005
Manfred Nowak
Jan 27, 2005
Norbert Nemec
January 25, 2005
<specs>
This confusingly appears to delete the value of b["hello"], but does not,
it removes the key "hello" from the associative array.
</specs>

D is a language that states parts of itself as confusing.

And that seems not to be neccessary:

  b.delete("hello");

or

  delete "hello" in b;

or

  in b delete "hello";

seem far more appropriate.

But that is not the main problem.

Imagine, and i really did that :-), you use an associative array for some rudimentary operations. As time goes by the operations on that array become more in number and complexity. You want a redesign an put the array in a class.

Naturally there exists some code, that does a `delete b["hello"]'.

Your redeclaration from some `V[char[]] b' to some `Class b=new Class'
causes some missing overload errors. Among them the error:
  `no [] operator overload' error.

But mechanically declaring one throws you into the next pit:
  `opIndex() is not an lvalue'

You can see: not only you think, that `delete b["hello"]' should delete the value of "hello" in b, but also the compiler thinks so.

But you want to delete the key, not the value, and there is currently no possibility to overload the `delete'.

You are to wear sackcloth and ashes and change all occurrences of this delete instead of simply overloading it.

I do not believe that this is necessary. Can we change this please?

-manfred


January 25, 2005
Maybe D should have an opIndexDelete override?  Or opAsocDelete, or similar, since its specifically for use with associative arrays (and therefore emulators of such).

-- Chris Sauls


January 25, 2005
In article <ct4c3b$3r2$1@digitaldaemon.com>, Chris Sauls says...
>
>Maybe D should have an opIndexDelete override?  Or opAsocDelete, or similar, since its specifically for use with associative arrays (and therefore emulators of such).
>
>-- Chris Sauls
>
>

I perhaps shouldn't do this, but I will because it seems so blindingly obvious where the true problems lie:

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.

The same could be said for the 'handy' .sort mechanism which doesn't allow one
to replace the algorithm (unless you also replace all the .sort instances also).
And, of course, these two are responsible for the otherwise unwarranted addition
of opCmp() and opEquals() within the root Object itself (which has been
belaboured to death several times prior).

I'll lay decent odds, with quantities of hard cash, that this is not "the last issue with AA or .sort". Oh, I agree that building the functionality into the core language skirts around some other issues. However; the original ones should have been resolved instead. Embedded compound-behaviour such as AA's and .sort will ultimately, IMO, hurt D more than most might think.

And for those who might think otherwise: I truly wish to see D succeed & flourish. For that to happen, some of the very, very, early concepts should at least be seriously re-evaluated.

- Kris


January 25, 2005
This has been an evil wart for some years, pricking the programming conscience of all and sundry. However, until now, there's never been an unequivocal and uncontestable reason, just the instincts of many smart and experienced people.

Thank you for providing this case. Now we must all cross our fingers and hope that Walter will take on board this (real) example from the practice and experience of another as reason why we should get rid of the wart for good.

"Manfred Nowak" <svv1999@hotmail.com> wrote in message news:ct4amm$2b2$1@digitaldaemon.com...
> <specs>
> This confusingly appears to delete the value of b["hello"], but does not,
> it removes the key "hello" from the associative array.
> </specs>
>
> D is a language that states parts of itself as confusing.
>
> And that seems not to be neccessary:
>
>  b.delete("hello");
>
> or
>
>  delete "hello" in b;
>
> or
>
>  in b delete "hello";
>
> seem far more appropriate.
>
> But that is not the main problem.
>
> Imagine, and i really did that :-), you use an associative array for some rudimentary operations. As time goes by the operations on that array become more in number and complexity. You want a redesign an put the array in a class.
>
> Naturally there exists some code, that does a `delete b["hello"]'.
>
> Your redeclaration from some `V[char[]] b' to some `Class b=new Class'
> causes some missing overload errors. Among them the error:
>  `no [] operator overload' error.
>
> But mechanically declaring one throws you into the next pit:
>  `opIndex() is not an lvalue'
>
> You can see: not only you think, that `delete b["hello"]' should delete the value of "hello" in b, but also the compiler thinks so.
>
> But you want to delete the key, not the value, and there is currently no possibility to overload the `delete'.
>
> You are to wear sackcloth and ashes and change all occurrences of this delete instead of simply overloading it.
>
> I do not believe that this is necessary. Can we change this please?
>
> -manfred
>
> 


January 25, 2005
Please no. Let's just have a simple syntax, like, er,

    aa.remove(key);

??

"Chris Sauls" <Chris_member@pathlink.com> wrote in message news:ct4c3b$3r2$1@digitaldaemon.com...
> Maybe D should have an opIndexDelete override?  Or opAsocDelete, or similar, since its specifically for use with associative arrays (and therefore emulators of such).
>
> -- Chris Sauls
>
> 


January 25, 2005
> And for those who might think otherwise: I truly wish to see D succeed & flourish. For that to happen, some of the very, very, early concepts should at least be seriously re-evaluated.

Hear, hear!!

The Dr .....

P.S. I'm hoping, when we get down to writing the book next month, that Walter will realise just how hard to swallow some of these concepts will be, and this may be a final motivation for some changes. (I've certainly experienced this phenomenon in various libs/articles(or chapters) in my own stuff.) I know I don't relish the idea of writing a book in 2005, and having to do a revised edition in 2006. ;)


January 25, 2005
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.
January 25, 2005
parabolis wrote:

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

I am terribly mistaken on this point. Given:

  RegExp[char[]] re;
  // with key "bob" and value "b[o]+b"
  delete re["bob"];

In the example above re should eliminate "bob" from its data structure and its reference to the corresponging RegExp object should be set to null. Should actually deleting the RegExp the following would work:

  RegExp tmp = re["bob"];
  delete re["bob"];
  delete tmp;
  tmp = null;

Ergo I was mistaken and (3) is quite clearly broken.
January 25, 2005
Manfred Nowak wrote:

(http://www.digitalmars.com/d/arrays.html#associative)
> <specs>
> This confusingly appears to delete the value of b["hello"], but does not, it removes the key "hello" from the associative array.
> </specs>
> 
> D is a language that states parts of itself as confusing.

At least Walter is being honest there :-)

> And that seems not to be neccessary:
> 
>   b.delete("hello");
> 
> or
> 
>   delete "hello" in b;
> 
> or
> 
>   in b delete "hello";
> 
> seem far more appropriate.

How about this new "creative" syntax:

     "hello" out b; // remove key:"hello" from hash:b

No new keywords needed there either ;-)

It could even return a pointer to the old entry,
and null if not found ? Or just a sane "void"...

--anders
January 25, 2005
"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.


« First   ‹ Prev
1 2 3