March 08, 2005 Re: in stinks | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Parker | "Mike Parker" <aldacron71@yahoo.com> wrote in message news:d0jmti$1noe$1@digitaldaemon.com... > Ben Hinkle wrote: > >>>I disagree. An out of bounds array index is an exceptional case because the size of the array is, usually, a known quantity - i.e. all members of the set of numbers from 0...n are valid, and n *must* be known during the allocation of the array. >> >> >> Dynamic arrays grow and shrink all the time. Same thing with adding and removing keys from an AA. The only difference (conceptually) is that dynamic arrays have a continuous block of integer keys. But I don't see why that matters. > > Maybe I'm missing something, but the only way in D for a dynamic array to grow or shrink is to set the length property, correct? That means the last index is always known - the index (n + 1) always points to an area of memory beyond the end of the array. > > I said in another post that the [] used by associative arrays causes people to view them in the same light as normal arrays. This looks like pure supposition. Or at least I suppose it is. Do you have evidence to support this? |
March 08, 2005 Re: in stinks | ||||
---|---|---|---|---|
| ||||
Posted in reply to Anders F Björklund | "Anders F Björklund" <afb@algonet.se> wrote in message news:d0jrgi$1u5h$1@digitaldaemon.com... > Regan Heath wrote: > >> I think throwing an exception is better than returning type.init. > > Maybe, but remember that you can write non-OOP code in D too... :-) > > And I think such an Exception would be better off hidden in a HashMap class library, instead of in the core language spec ? > >> But wait, you say, it's not an invalid assumption, I _want_ the value _or_ type.init, to which I answer, use 'contains': >> >> aa.contains("bob",value); >> >> value is an 'out' parameter, and will be set to type.init. >> >> As long as 'contains' exists I will be happy. >> >> bool contains(KeyType key, out ValueType value); >> bool contains(KeyType key); > > But that's how it works now ? Just using a pointer, > instead of: a "boolean" (bit) and an out reference. Come on. The pointer stuff is just a joke. A hack that'll make people question the sanity, or at least the intelligence, of the language designers. I can't believe you don't see that, never mind be concerned about it. |
March 08, 2005 Re: in stinks | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | Regan Heath wrote: >>> I think throwing an exception is better than returning type.init. >> >> Maybe, but remember that you can write non-OOP code in D too... :-) > > Sure, however Exceptions are the proposed/recommended "D Error Handling Solution" > http://www.digitalmars.com/d/errors.html Yeah, we just different in opinion on whether missing keys are errors ? If they are, then an exception is OK... Something like ArrayBoundsError. >> And I think such an Exception would be better off hidden in a >> HashMap class library, instead of in the core language spec ? > > Why? What's the difference between a hashmap class library and built in AA's? Objects ? :-) > In short I want to be able to say: > > if (aa.contains("bob",value)) { > } I like the current aa["bob"] syntax, just don't like the side effect. 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" --anders |
March 08, 2005 Re: in stinks | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew | Matthew wrote:
>>But that's how it works now ? Just using a pointer,
>>instead of: a "boolean" (bit) and an out reference.
>
> Come on. The pointer stuff is just a joke. A hack that'll make people question the sanity, or at least the intelligence, of the language designers. I can't believe you don't see that, never mind be concerned about it.
I do see it. I think it was simpler when they were
separate (like in DMD before version 0.107, or in
the Map interface of the Java Collections library)
The current "in" expr is a performance hack, nothing else...
I actually prefer to not use the pointer, just like a "bool".
My point was just that if you want both-at-once, it's there ?
As long as D uses the C++ way of setting non-existant elements,
or if it will switch to the proposed way of throwing Exceptions,
I need to use to "in" before accessing the array as a workaround.
Otherwise I would use it after, *if* I cared about the difference...
(between keys that don't exist, and keys that map to the .init value)
It seems that other people are using AA's in other ways, so I let them.
--anders
|
March 08, 2005 Re: in stinks | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew | Matthew wrote:
>>I said in another post that the [] used by associative arrays causes people to view them in the same light as normal arrays.
>
>
> This looks like pure supposition. Or at least I suppose it is. Do you have evidence to support this?
>
Just some comments I have read in this thread, such as in one of your posts:
"I'd disagree with both of you that it is in any way appropriate for the [] to return a default in the case where an
entry does not exist."
Couple that with the fact that I have never heard anyone ask for exceptions to be thrown from Hashmap.get() in Java and you may see where I draw the conclusion. My interpretation is that when thinking of a Hashmap class vs. D's associative arrays one might have different expectations, even the functionality is conceptually the same - is Hashmap.get("key") not the same as aa["key"]?
|
March 08, 2005 Re: in stinks | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Parker | Mike Parker wrote: > Matthew wrote: > >>> I said in another post that the [] used by associative arrays causes people to view them in the same light as normal arrays. >> >> >> >> This looks like pure supposition. Or at least I suppose it is. Do you have evidence to support this? >> > > Just some comments I have read in this thread, such as in one of your posts: > > "I'd disagree with both of you that it is in any way appropriate for the [] to return a default in the case where an > entry does not exist." And from Anders (just so I don't single out Matthew!): "I guess it boils down to whether you consider an empty array to be full of valid lookups, or not... To me, a dynamic array is full of .init values so then it makes sense that associative arrays should also be full of .init values as well." > > Couple that with the fact that I have never heard anyone ask for exceptions to be thrown from Hashmap.get() in Java and you may see where I draw the conclusion. My interpretation is that when thinking of a Hashmap class vs. D's associative arrays one might have different expectations, even the functionality is conceptually the same - is Hashmap.get("key") not the same as aa["key"]? |
March 08, 2005 Re: in stinks | ||||
---|---|---|---|---|
| ||||
Posted in reply to Anders F Björklund | On Tue, 08 Mar 2005 11:01:46 +0100, Anders F Björklund <afb@algonet.se> wrote: > Regan Heath wrote: >>> And I think such an Exception would be better off hidden in a >>> HashMap class library, instead of in the core language spec ? >> Why? What's the difference between a hashmap class library and built in AA's? > > Objects ? :-) ? I'm not following... >> In short I want to be able to say: >> if (aa.contains("bob",value)) { >> } > > I like the current aa["bob"] syntax, just don't like the side effect. I like that syntax too, and I'll use it, but only if I'm 100% certain the key exists, otherwise I prefer and will use the 'contains' syntax. > 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". I think "delete" should be done as contains is done above, i.e. aa.delete("bob"); or perhaps it should be called "remove"? Regan |
March 08, 2005 Re: in stinks | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | 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 ? 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... But a built-in class is more about operators and such ? >> 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 ? 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... Then you would only have to know about the "special feature" when doing performance tricks to avoid any double lookups ? > 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) Still think "out" to be a great pun. :-) value = "bob" in aa; => aa.contains("bob",value); value = "bob" out aa; => aa.remove("bob", value); --anders |
March 08, 2005 Re: in stinks | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | "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. I had guessed before that the reason Walter chose to use delete was to avoid adding a method to AAs. But now there are two good methods to add to AAs and so I hope he considers sacrificing the aesthetic beauty of method-less AAs for them. The "in" operator should stay since it would be annoying to have to pass a dummy value parameter just to see if a key is in the array. 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... This would make opIn the only obstacle to writing a user type that mimics builtin AAs. -Ben |
March 08, 2005 Re: Overriding and Overloading WAS: in stinks | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Demme | 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)? > >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. I hope this doesn't no into early/late binding discussions. Ant |
Copyright © 1999-2021 by the D Language Foundation