Key vs Value
-
This is not a programming but lazy abstraction and amateur philosophical question, hence qualifies for Lounge :) Any .NET related experience on this, since I have been thinking about it for too long and seeing this: > protected KeyedList<ViewListenerKey, List<SessionContainerListener>> viewListeners; > protected KeyedList<ViewListenerKey, ViewKeyData> viewKeyData; > protected KeyedList<SessionContainerViewListenerKey, List<DataTable>> sessionTransactions; > Run. Don't walk, run. I simply had to ask: a) I can understand std::map, Dictionaries and far more are popular out there especially Web work. I have seen code in which an abstraction seeked even inherits a Key (although reading code, it never suits an 'is-a'). This affects single-inheritance-challenged languages as well as make for some weird reading late at night. There is some verbosity issues for introducing key types (sometimes a tad of reuse in an orthogonal space) for both containers but I'd prefer not to focus on it and aim for 'usability' and 'correctness' b) If you read the .NET framework guidelines, that book "what to not do or do in commercial world and appear smart", you know they advertise less types as a form of metric reflecting usability. This arguably affects *Key proliferation as per sample above. On the opposite side of the spectrum, similarly, String seems to be the preferred 'universal' Key in plenty of code I come across. My question being, have you hit on and what do you do when you hit on a problem when neither a Key infestation (with inheritance or not) nor String can 'sufficiently' represent the associative containers value. I have come across an argument where constructing *Key types doesn't really help build intuitive indexers for api design and of course on top of it all you might have a need to build custom collections types over and over again.. I can understand DOM-like or similar APIs are better at expressing this rather than code, but I am after efficiency without parsing, dom, sax, reflection etc. (and while not directly related but remotely-linked, why would DLR ever make a difference to this world?)
-
This is not a programming but lazy abstraction and amateur philosophical question, hence qualifies for Lounge :) Any .NET related experience on this, since I have been thinking about it for too long and seeing this: > protected KeyedList<ViewListenerKey, List<SessionContainerListener>> viewListeners; > protected KeyedList<ViewListenerKey, ViewKeyData> viewKeyData; > protected KeyedList<SessionContainerViewListenerKey, List<DataTable>> sessionTransactions; > Run. Don't walk, run. I simply had to ask: a) I can understand std::map, Dictionaries and far more are popular out there especially Web work. I have seen code in which an abstraction seeked even inherits a Key (although reading code, it never suits an 'is-a'). This affects single-inheritance-challenged languages as well as make for some weird reading late at night. There is some verbosity issues for introducing key types (sometimes a tad of reuse in an orthogonal space) for both containers but I'd prefer not to focus on it and aim for 'usability' and 'correctness' b) If you read the .NET framework guidelines, that book "what to not do or do in commercial world and appear smart", you know they advertise less types as a form of metric reflecting usability. This arguably affects *Key proliferation as per sample above. On the opposite side of the spectrum, similarly, String seems to be the preferred 'universal' Key in plenty of code I come across. My question being, have you hit on and what do you do when you hit on a problem when neither a Key infestation (with inheritance or not) nor String can 'sufficiently' represent the associative containers value. I have come across an argument where constructing *Key types doesn't really help build intuitive indexers for api design and of course on top of it all you might have a need to build custom collections types over and over again.. I can understand DOM-like or similar APIs are better at expressing this rather than code, but I am after efficiency without parsing, dom, sax, reflection etc. (and while not directly related but remotely-linked, why would DLR ever make a difference to this world?)
because people like you will post about it, generate a flame war and increase site traffic with advertising dollars for code project. it's all part of chris' master plan
-
because people like you will post about it, generate a flame war and increase site traffic with advertising dollars for code project. it's all part of chris' master plan
> because people like you will post about it, generate a flame war and increase site traffic with > advertising dollars for code project. Not after a flame war (but I like to point out deficiencies in any tech ) but ideas having seen Marc's comment which resonated a bit. > it's all part of chris' master plan Ah, don't know about that, I don't speculate on that.. look, look up, Google revenues missed estimates :-) (I do have an issue with urchin deployment though but I sincerely believe Chris did a great thing for the community, even before user registration on the site existed :-). Thanks for the input anyway.
-
> because people like you will post about it, generate a flame war and increase site traffic with > advertising dollars for code project. Not after a flame war (but I like to point out deficiencies in any tech ) but ideas having seen Marc's comment which resonated a bit. > it's all part of chris' master plan Ah, don't know about that, I don't speculate on that.. look, look up, Google revenues missed estimates :-) (I do have an issue with urchin deployment though but I sincerely believe Chris did a great thing for the community, even before user registration on the site existed :-). Thanks for the input anyway.
jeez dewd. apparently i forgot the joke icon.
-
jeez dewd. apparently i forgot the joke icon.
no proms jg :)... serious though, I was interested if DLR makes a difference here by any chance? After all, one of the promises and utilities of .NET is that it gives us great APIs. So I was interested how do people go about this? Can't believe that it isn't a common problem in design and/or in migrating and/or doing interop code..
-
no proms jg :)... serious though, I was interested if DLR makes a difference here by any chance? After all, one of the promises and utilities of .NET is that it gives us great APIs. So I was interested how do people go about this? Can't believe that it isn't a common problem in design and/or in migrating and/or doing interop code..
Personally, I dont see it as "making a difference". I see this as developers having the ability to use many many tools and options. I think, personally, since the option is available that in itself does do something good for development. That's not to say that inappropriate use doesn't exist. There are plenty of people who will use a tow truck to move their radio flyer...but I don't want to limit the options we have because of other peoples' misuse.
Last modified: 10mins after originally posted --
-
This is not a programming but lazy abstraction and amateur philosophical question, hence qualifies for Lounge :) Any .NET related experience on this, since I have been thinking about it for too long and seeing this: > protected KeyedList<ViewListenerKey, List<SessionContainerListener>> viewListeners; > protected KeyedList<ViewListenerKey, ViewKeyData> viewKeyData; > protected KeyedList<SessionContainerViewListenerKey, List<DataTable>> sessionTransactions; > Run. Don't walk, run. I simply had to ask: a) I can understand std::map, Dictionaries and far more are popular out there especially Web work. I have seen code in which an abstraction seeked even inherits a Key (although reading code, it never suits an 'is-a'). This affects single-inheritance-challenged languages as well as make for some weird reading late at night. There is some verbosity issues for introducing key types (sometimes a tad of reuse in an orthogonal space) for both containers but I'd prefer not to focus on it and aim for 'usability' and 'correctness' b) If you read the .NET framework guidelines, that book "what to not do or do in commercial world and appear smart", you know they advertise less types as a form of metric reflecting usability. This arguably affects *Key proliferation as per sample above. On the opposite side of the spectrum, similarly, String seems to be the preferred 'universal' Key in plenty of code I come across. My question being, have you hit on and what do you do when you hit on a problem when neither a Key infestation (with inheritance or not) nor String can 'sufficiently' represent the associative containers value. I have come across an argument where constructing *Key types doesn't really help build intuitive indexers for api design and of course on top of it all you might have a need to build custom collections types over and over again.. I can understand DOM-like or similar APIs are better at expressing this rather than code, but I am after efficiency without parsing, dom, sax, reflection etc. (and while not directly related but remotely-linked, why would DLR ever make a difference to this world?)
Awesome. I love it when my code is the subject of in-depth discussion. :-D
User of Users Group wrote:
I have come across an argument where constructing *Key types doesn't really help build intuitive indexers for api design
I never would expose complex keys and collections like that in an API. This is deep in the bowels of some server code that monitors transactions coming in from a client and notifies other clients that have views that are affected by the changes to the underlying (and in common) DataTable instances.
User of Users Group wrote:
have you hit on and what do you do when you hit on a problem when neither a Key infestation (with inheritance or not) nor String can 'sufficiently' represent the associative containers value.
That's an interesting question. In cases where I've to write complex keys like this, the associative information is very specific to the problem domain. Given that, I don't think that's a bad thing. But I've also seen complex dictionaries set up that are little more than key value pairs, where the key is not used as a key but as another piece of information, and the dictionaries are only used in iteration. That's definitely the wrong approach. A part of me wants to say that there are times when you can't avoiding complex associations. There may be other ways of handling the association information though that makes the key simpler. Explicit serialization/encoding-compacting might be an option. Marc
-
Awesome. I love it when my code is the subject of in-depth discussion. :-D
User of Users Group wrote:
I have come across an argument where constructing *Key types doesn't really help build intuitive indexers for api design
I never would expose complex keys and collections like that in an API. This is deep in the bowels of some server code that monitors transactions coming in from a client and notifies other clients that have views that are affected by the changes to the underlying (and in common) DataTable instances.
User of Users Group wrote:
have you hit on and what do you do when you hit on a problem when neither a Key infestation (with inheritance or not) nor String can 'sufficiently' represent the associative containers value.
That's an interesting question. In cases where I've to write complex keys like this, the associative information is very specific to the problem domain. Given that, I don't think that's a bad thing. But I've also seen complex dictionaries set up that are little more than key value pairs, where the key is not used as a key but as another piece of information, and the dictionaries are only used in iteration. That's definitely the wrong approach. A part of me wants to say that there are times when you can't avoiding complex associations. There may be other ways of handling the association information though that makes the key simpler. Explicit serialization/encoding-compacting might be an option. Marc
> I never would expose complex keys and collections like that in an API. This is deep in the bowels Which makes a lot of sense, I just wanted to see whether a dev would ever be interested in plugging to this sort of 'functionality'/organisation, and indeed it seems extremely rare or some other way or mechanism always exists. I can sleep better now :) > That's an interesting question. In cases where I've to write complex keys like this, the a > ssociative information is very specific to the problem domain. Well put. Shifting focus to a higher level of what an api user, looking to extend and/or customise sees, it is so tightly knit that most of the times a large number of key-information can even be utilised intuitively on a UI display, almost directly. Which again brings me to some form of key exposure to the outside world. > Given that, I don't think that's a bad thing. I see what you mean. > But I've also seen complex dictionaries set up that > are little more than key value pairs, where the key is not used as a key but as another piece of > information, and the dictionaries are only used in iteration. That's definitely the wrong approach. Which makes a good, but high-level API and OO layer/design kind of eliminate Dictionaries and maps? I would lean towards that camp because a dev can too easily, well lets say use SGML, XML, HTML, XAML and suffer from parent.parent.parent.parent forest :-) > A part of me wants to say that there are times when you can't avoiding complex associations. Sometimes I believe we all work in the same domain :), but I agree it is inevitable in any, ideally internal, implementation. I just wonder whether it is good to know a great deal about the association, and once you do, the user/dev easily assumes they can enhance/utilise/twist/bend it and voila: changing internal impl breaks that model. > There may be other ways of handling the association information though that makes the key simpler. > Explicit serialization/encoding-compacting might be an option. Which is exactly what I keep hitting on and that unfortunately gives another reason for Key visibility (even some reuse) and unless 'is-a' is involved say with an internal class it is pretty hard to hide it (or not fall for it). On the other extreme, not exposing it means maintaining parallel value space implementation (which is what tried to avoid in the original question but you got me there:). And while explcit compacting can be used in higher layers, I've seen it
-
> I never would expose complex keys and collections like that in an API. This is deep in the bowels Which makes a lot of sense, I just wanted to see whether a dev would ever be interested in plugging to this sort of 'functionality'/organisation, and indeed it seems extremely rare or some other way or mechanism always exists. I can sleep better now :) > That's an interesting question. In cases where I've to write complex keys like this, the a > ssociative information is very specific to the problem domain. Well put. Shifting focus to a higher level of what an api user, looking to extend and/or customise sees, it is so tightly knit that most of the times a large number of key-information can even be utilised intuitively on a UI display, almost directly. Which again brings me to some form of key exposure to the outside world. > Given that, I don't think that's a bad thing. I see what you mean. > But I've also seen complex dictionaries set up that > are little more than key value pairs, where the key is not used as a key but as another piece of > information, and the dictionaries are only used in iteration. That's definitely the wrong approach. Which makes a good, but high-level API and OO layer/design kind of eliminate Dictionaries and maps? I would lean towards that camp because a dev can too easily, well lets say use SGML, XML, HTML, XAML and suffer from parent.parent.parent.parent forest :-) > A part of me wants to say that there are times when you can't avoiding complex associations. Sometimes I believe we all work in the same domain :), but I agree it is inevitable in any, ideally internal, implementation. I just wonder whether it is good to know a great deal about the association, and once you do, the user/dev easily assumes they can enhance/utilise/twist/bend it and voila: changing internal impl breaks that model. > There may be other ways of handling the association information though that makes the key simpler. > Explicit serialization/encoding-compacting might be an option. Which is exactly what I keep hitting on and that unfortunately gives another reason for Key visibility (even some reuse) and unless 'is-a' is involved say with an internal class it is pretty hard to hide it (or not fall for it). On the other extreme, not exposing it means maintaining parallel value space implementation (which is what tried to avoid in the original question but you got me there:). And while explcit compacting can be used in higher layers, I've seen it
User of Users Group wrote:
Which makes a good, but high-level API and OO layer/design kind of eliminate Dictionaries and maps? I would lean towards that camp because a dev can too easily, well lets say use SGML, XML, HTML, XAML and suffer from parent.parent.parent.parent forest
...
User of Users Group wrote:
That unfortunatelly leaves a simple hiearachical model which again resembles the DOM so much that I have trouble bothering with code and wonder why not go straight for data representation (but that has its own inefficiencies and I have to target a strongly typed and ''rich' api ).
When I first started experimenting with declarative markup, I discovered what you are describing. The control graph would be entangled with data binding, style information, mouse-over events altering style, data paths dynamically modified, and event wireup to imperative code, which itself was entangled with declarative MVC architecture. Yuck. It became an unmaintainable morass of spaghetti code. Now, quite frankly, that really surprised me. I thought an object graph would be clean, readable, and easy to maintain. Turns out that that's not true. I've realized that declarative code (DOM's, hierarchies, object graphs) are maintainable only of the different aspects of graph are separated out. In hindsight, that's obvious, but I was fooled by the elegance of a hierarchical DOM. One graph for the UI layout, another (flatter) graph specifically for data binding, another graph for event wire up, another graph for style information, and so forth. That ends up being much more maintainable, even if it all gets compiled into the imperative code as spaghetti. :)
User of Users Group wrote:
Not sure whether this will makes sense, but you seem to confirmed it for me that Key and Value seperation for user API design is at odds as much as OO is with data and distributed technologies.
Yup. You can see it in declarative code, where you have to massage the data post-instantiation to set up the dictionaries. And as you pointed out earlier, that results in maintaining two seperate collections. One for the "interface" (the XML, the API, whatever), and one for the internal representation. As you point out, the same ends up happening with objects vs. schema. Interesting discussion. It's brought a couple things more to consciousness. :) Marc