March 08, 2005
> So, my preferred AA api:
> bit opIn(Key key) // possibly return value* instead
> Value opIndex(Key key) // throws on missing key
> bit contains(Key key, out Value value)
> void remove(Key key) // ignores missing key
> ... rest as before except "delete" is removed...

ack - let me add another one:
 Value* insert(Key key) // lookup and insert if not present

That way in the example at the end of
http://www.digitalmars.com/d/arrays.html the expression
  dictionary[word]++;
would become
  (*dictionary.insert(word))++;
To me even though it looks uglier it's more explicit about what is really
going on.


March 08, 2005
"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:d0k900$2d77$1@digitaldaemon.com...
>
> "Regan Heath" <regan@netwin.co.nz> wrote in message news:opsna9qiqv23k2f5@nrage.netwin.co.nz...
>> On Tue, 08 Mar 2005 17:10:04 +0900, Mike Parker <aldacron71@yahoo.com> wrote:
>>> Matthew wrote:
>>>
>>>> Same here. And trying to get a value out of an associative container that does not exist is exactly that, exceptional. (Or it certainly should be.)
>>>
>>> I just can't agree with this. A missing key is simply a missing key. See below.
>>
>> I'm with Matthew on this one. Assuming there is a method:
>>   bool contains(KeyType key, out ValueType value);
>>
>> that returns true/false and sets value when found.
>>
>> Then array["key"] makes an assumption (that the key exists), and if it's false, that is an exception.
>
> This proposal is pretty nice. At the risk of going even more off-topic we should add a method to remove an item from the AA instead of "abusing" delete.

Not off topic. I think no-one's mentioned it because it is such an obvious and total wart. I'd confidently say that aa/delete is the (current) worst part of D. Anyone think of anything more stupid??

I'm just expecting Walter to kill it quietly one day, to avoid the shit storm of protest if he doesn't.

Or maybe I'm being naive. In which case I'd better get my shovel ...



March 08, 2005
Ant wrote:
> In article <d0isq0$p3n$1@digitaldaemon.com>, John Demme says...
> 
>>Here's a good example:
> 
> [... polymorphism bug example ...]
> 
> can you show the same without using global static functions
> (I mean free standing functions)?
Sure... well, exception for main()
import std.stdio;

class TwoDImage {
  TwoDImage overlap(TwoDImage i) {
    //Returns the overlap of the two images.
    writefln("Potentially long calculation");
    return null;
  }

  static void PrintOverlap(TwoDImage a, TwoDImage b) {
    TwoDImage i = a.overlap(b);
    //Graphically print the overlap
  }
}

class Circle: TwoDImage {
  //HACK
  override TwoDImage overlap(TwoDImage i) {
    //if (cast(Circle)i)
      //return this.overlap(cast(Circle)i);
    //else
      return super.overlap(i);
  }
  TwoDImage overlap(Circle c) {
    //Does the same thing as super.overlap,
    //But is able to calculate the overlap much more effeciently
    writefln("Trivial calculation");
    return null;
  }
}

void main() {
  Circle a = new Circle();
  Circle b = new Circle();
  TwoDImage.PrintOverlap(a, b);
}

> 
> 
>>This makes a lot of sense to me.
> 
> 
> it's called polymorphism,
> integral to OOP, we can't say D supports OOP until this is fixed.
Well, that's what I thought, but Java doesn't do it either, and I thought Java fully supported polymorphism.  Here's the Java code for reference:
class TwoDImage {
  TwoDImage overlap(TwoDImage i) {
    //Returns the overlap of the two images.
    System.out.println("Potentially long calculation");
    return null;
  }

    static void PrintOverlap(TwoDImage a, TwoDImage b) {
 TwoDImage i = a.overlap(b);
 //Graphically print the overlap
    }
}

class Circle extends TwoDImage {

  TwoDImage overlap(Circle c) {
    //Does the same thing as super.overlap,
    //But is able to calculate the overlap much more effeciently
    System.out.println("Trivial calculation");
    return null;
  }
}

class test {
    public static void main(String[] args) {
  Circle a = new Circle();
 Circle b = new Circle();
 TwoDImage.PrintOverlap(a, b);
    }
}

> 
> I hope this doesn't no into early/late binding discussions.
> 
> Ant
> 
> 

Since I don't see any reason for D not to support this behavior, I think it would be great if it did!  One up Java, right?!

John Demme
March 08, 2005
On Tue, 08 Mar 2005 16:04:54 -0500, John Demme wrote:


> Well, that's what I thought, but Java doesn't do it either, and I

can't be!
oh! here,

> class Circle extends TwoDImage {
> 
>    TwoDImage overlap(Circle c) {
>      //Does the same thing as super.overlap,
>      //But is able to calculate the overlap much more effeciently
>      System.out.println("Trivial calculation");
>      return null;
>    }
> }

should be:
class Circle extends TwoDImage
{

	TwoDImage overlap(TwoDImage i)
	{
		//Does the same thing as super.overlap,
		//But is able to calculate the overlap much more effeciently
		System.out.println("Trivial calculation");
		return null;
	}
}

let's see the D version... it also works!
seems D supports OOP after all.

Ant
March 08, 2005
Ant wrote:
> On Tue, 08 Mar 2005 16:04:54 -0500, John Demme wrote:
> 
> 
> 
>>Well, that's what I thought, but Java doesn't do it either, and I 
> 
> 
> can't be!
> oh! here, 
> 
> 
>>class Circle extends TwoDImage {
>>
>>   TwoDImage overlap(Circle c) {
>>     //Does the same thing as super.overlap,
>>     //But is able to calculate the overlap much more effeciently
>>     System.out.println("Trivial calculation");
>>     return null;
>>   }
>>}
> 
> 
> should be:
> class Circle extends TwoDImage {
> 
> 	TwoDImage overlap(TwoDImage i) 	{
> 		//Does the same thing as super.overlap,
> 		//But is able to calculate the overlap much more effeciently
> 		System.out.println("Trivial calculation");
> 		return null;
> 	}
> }
> 
> let's see the D version... it also works!
> seems D supports OOP after all.
> 
> Ant

You clearly don't get what I'm saying.  Go back and (re-)read the posts.  I'm aware of to get it to work.  A simple override works fine.  It's when a subclass has a method by the same name, and accepts a parameter that is a subclass of class that is a parameter of the parent's method that I think it should be called when that method is called with that subclass as a parameter.  I realize that it's not hard to make it work, by creating another function to handle it, but I see it as a hack.

I think one of those was perhaps one of the worst sentences ever written... and my g/f is an english major...  If she saw it she'd probably kill me.

John Demme
March 09, 2005
On Tue, 08 Mar 2005 17:31:53 -0500, John Demme wrote:

> 
> You clearly don't get what I'm saying.  Go back and (re-)read the posts.
>   I'm aware of to get it to work.
I see now, sorry.

Ant

March 10, 2005
"Anders F Björklund" <afb@algonet.se> wrote in message news:d0jr3d$1tli$1@digitaldaemon.com...
> Regan Heath wrote:
> >> (but actually using "key.init" instead of null above
> >> does not work, due to a horrible init-related bug)
> >
> > Has Walter fixed the "horrible init-related bug" yet?
>
> Maybe... :-) I couldn't get it to reproduce, but anyway it was about key getting initialized when *reading* key.init ?

Oh that one. I believe it was fixed. Horrible is an accurate description of it. <g>


March 10, 2005
On Tue, 08 Mar 2005 12:05:49 +0100, Anders F Björklund <afb@algonet.se> wrote:
> Regan Heath wrote:
>
>>>>  Why? What's the difference between a hashmap class library and built  in  AA's?
>>>
>>> Objects ? :-)
>>  ? I'm not following...
>
> A class library implies that it would be using classes
> (or structs, if you want to do C++ish performance hacks)
> The built-in arrays are not classes, any more than
> strings are, so they would not use the same syntax ?

Ahh. I follow now. Yes, the syntax would be different.

> For a HashMap library, then a "contains" method with
> parameters is perfectly alright and could even throw
> exceptions if the class library designer so wished...

If it returns bool, then there is no need to.
Or rather, I wouldn't.

> But a built-in class is more about operators and such ?

We can emultate the built-ins to a large degree. NOt perfectly, but perhaps that will change?

>>> The above looks too much like a function call, to be a built-in op ?
>>> But I'm all for discussing/improving the syntax of "in" and "delete"
>>  I like "in".
>
> With the pointer and all ?

I have no problem saying "if (a in b)" where "a in b" equates to a pointer.
I would prefer it returned bool, and I had contains.

> Maybe one could tweak the
> language so that "in" can return either/or, and not
> require a cast to be assigned to a bool/bit variable...

Interesting idea, by checking the lhs type perhaps? That sounds a bit like picking an overload based on return type.

> Then you would only have to know about the "special feature"
> when doing performance tricks to avoid any double lookups ?

It would be best if no 'tricks' were required to get good performance.
I think if there are clearly 3 methods, for clearly different purposes we'll get that.

>> I think "delete" should be done as contains is done above, i.e.
>>  aa.delete("bob");
>>  or perhaps it should be called "remove"?
>
> I'm not sure you could even use the "delete" keyword, if you wanted?
> "remove" would work great for a library, along with get/put methods...
>
> I think I will hack together a simple Object-storing Map/HashMap,
> just to see what it would look like in D ? (much like my String)

Sounds like a good idea. Just to see.

> Still think "out" to be a great pun. :-)
>
> value = "bob" in aa; => aa.contains("bob",value);
> value = "bob" out aa; => aa.remove("bob", value);

No!! Don't "out" bob... ;)

Regan
March 12, 2005
"Matthew" <admin.hat@stlsoft.dot.org> wrote:

> Excellent philosophy.
[...]

Maybe it is a philosophy only. But if one have a look at this curious threads on how to denote the `.length' property of arrays one would like to declare it as some sort of mass hysterogeny otherwise.

Several intelligent representatives of mankind disputing on an object which is the equivalent of sparing a thousandth of the needed typing work. And it seems to be the typing only, as if in programming this part of the whole task is the most important.

This is such a tininess of the whole task of programming language design, that I could just not believe that under economic pressure a board of programmers would come together several times over a period of 15 month to discuss how to save themselves one minute of typing every two days of their job.

-manfred
March 12, 2005
On Sat, 12 Mar 2005 03:48:28 +0000 (UTC), Manfred Nowak wrote:

> "Matthew" <admin.hat@stlsoft.dot.org> wrote:
> 
>> Excellent philosophy.
> [...]
> 
> Maybe it is a philosophy only. But if one have a look at this curious threads on how to denote the `.length' property of arrays one would like to declare it as some sort of mass hysterogeny otherwise.
> 
> Several intelligent representatives of mankind disputing on an object which is the equivalent of sparing a thousandth of the needed typing work. And it seems to be the typing only, as if in programming this part of the whole task is the most important.
> 
> This is such a tininess of the whole task of programming language design, that I could just not believe that under economic pressure a board of programmers would come together several times over a period of 15 month to discuss how to save themselves one minute of typing every two days of their job.
> 
> -manfred

Me thinks ye are a dour sort.

http://www.cogsci.princeton.edu/cgi-bin/webwn?stage=1&word=fun

Its only a bunch of guys sitting around after work, having a beer or two, and talking about their favourite sporting team. Its not important; just a bit fun to unwind and prepare for the next real day. No one actually expects this to be a life-changing or world-saving discussion. Walter will sift through the chaff and rubbish, and form his own opinion and it will, in all probability, be "alright-ish'.

-- 
Derek Parnell
Don't Worry - Be happy, mon.