|
Re: Introducing the Iterable Concept
|
Posted: Nov 10, 2005 1:15 PM
|
|
> <snip> > > This code is 7 lines (same counting method as > > above), half of your code. > > With all due respect Terje, this is an irrelevant and weak > comparison. You are ignoring the lines of code in the STL > itself.
I'm not igoring it, but I think "client code" (the code you have to write yourself) is way more important than any library code you happen to use.
> You also miss my point that you can save a lot of > code by modeling Iterable instead of modeling a Container, > in a collection class.
With all due respect, yourself, I responded with an alternative to a concrete use case. You may make as elaborate examples as you want, but they should be real, as in a concrete example of something that works, not a thought-experiment.
I showed in my example that one answer to your question is "Mu!" :) Which is an expression that Kevlin Henney is fond of, and it means basically "unasking the question". The point is that you _don't need to_ implement a container, to solve the problem you posed.
> > That's about 20 lines (again, not counting access > > specifiers, braces and blank lines). Using idiomatic > C++ > > and STL, you can get the same effect as the above, with > > just three lines: > > int main() > > { > > int array[]={1,2,3,4,5,6,7,8,9,10}; > > > > typedef std::ostream_iterator<int> out; > > > > std::copy(array,array+10,out(std::cout," ")); > > } It doesn't need to be more complex, you see... > And > > you're the one bringing up the simplicity argument. ;) > > I don't buy this kind of proof-by-example. It demonstrates > little, and is misleading.
You claimed the STL made writing code more complex than needed to. I showed examples where the resulting code was smaller (and arguably simpler, for someone knowing STL), than your alternative.
Why do you think this demonstrate little, and why is it misleading? We're discussing concrete examples _that you used in your own argumentation_!
> I also think it would be only > fair to compare high-level notations such as (ootl being > the namespace for a framework built on new concepts such > as Iterable, Indexable, Stackable):
I agree, and if you have such a framework, show us the examples with it. I can only respond to what you showed.
> > Don't be so quick to diss STL, before you've really > > learned what it can do. > > I am very aware of what can be done with the STL. Don't be > so quick to assume that the STL doesn't make any > trade-offs and represents the best design for all possible > circumstances.
Have I said otherwise? If so, then please provide a quote. Are you saying I've assumed that? You say I shouldn't be quick to assume, and I don't, but if you claim I assume the above, you went into that trap, yourself, and assumed something I haven't claimed.
I think, however, that I've shown that, for use cases you've provided so far, there may be an at least as good solution using STL, as well.
There's a reason why STL has stood the test of time (while various other "collection frameworks" have come and gone), and this generality is one of them.
> > Furthermore, as mentioned, the above is idiomatic, > modern > > C++, so other C++ programmers familiar with the > standard > > library should be able to understand it. > > I don't buy this argument neither. Being idiomatic is not > an advantage from my point of view.
Other programmers being able to understand the code without learning it from you not being an advantage? Heck, then there must be no advantage of knowing the language in the first place, so Heron and C++ have equal chance of being used on any project in the real world, right?
> > Not my idea of simplicity, cohesion and decoupling. > > Here is where I disagree, I think it is much simpler to > have iteration managed within a collections member > function, and not exposed to the programmer (sometimes).
I was not at least talking about a full system using this, where the decoupled elements of the STL means they can be combined in many ways, without having to write new code, or learn new components.
> The STL is great at being decoupled, but it would be > foolish to think that extreme decoupling has no downside. > One downside is complexity.
Here we need to thread carefully. What kind of complexity are we talking about? Is a system consisting of _one_ monolithic function consisting of several hundred lines of deeply nested code more or less complex than a program with, say 20 simple, focused functions, implementing the same functionality? The total complexity may be the same, even perhaps a little higher in the latter example (due to the decoupling you mention). However, what we perhaps most care about in any system is the _local_ complexity: what you need to understand, in order to understand a particular area of the code, and in _that_ case, the last example is likely enourmously less complicated. The last example lets us view the system as a whole, and drill in on the details, while the first example only provides a monolithic "blob".
The same goes for decoupling in general (as long as it's useful decoupling, i.e. where it makes sense): it may reduce local complexity, and increase chance of combination and reuse.
> I also argue that by placing the iteration within a single > method is in fact more cohesive. I like the following > definition of cohesion: > > "A measure of the extent to which related aspects of a > system are kept together in the same module, and unrelated > aspects are kept out". > > Iteration is arguably very closely related to collection > management, and deserves to be kept together in the same > place. This is of course highly subjective, and not > something which I would debate vigorously.
One thing you may agree on, however, is that whether or not iteration is closely related to collection management, depends heavily on what you use the collection _for_. An associative map may have no use for iteration, for example, if all you use it for is looking up values using keys.
> There are other properties of software which are important > as well, such as the property of encapsulation.
Indeed.
> This property is severely violated by STL iterators
Really? Could you explain why you think so?
Regards,
Terje
|
|