Yes, I'm aware of the date. AFAIR, 1 ed. is circa 1974, so in 14 years
I'd say the principles were still effective.
``Prior to this time'' you probably meant prior to 1974.
[cut]
> functional abstractions. Using your argument that the example code
> hides an "implementation", it's difficult to conceive of a code example
> that hids neither its data nor its implementation.
So why should you change a definition to allow for a specific case?
Isn't a function de facto an implementation detail and thus encapsulating
the actual implementation (i.e. it's workings).
Anyway this is not important and is just formalisms.
My whole point was to put down in text file, the already practiced rule
of thinking out data representations, since this has direct effect on
the complexity of the code (i.e. the choice of data represenation).
I'm sure you know which example I'm thinking of.
-- Luben
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/