quote:Original post by the Speed Bump
quote:... the same is true of ''implicit'' inheritance of normal methods -- you might forget to override a method in a subclass, and the superclass''s implementation might leave one of your invariants violated. Also, the same is true of the zero-argument constructor -- forget to supply that, and all four languages will happily use the superclass''s, even though the resulting object might be bad.
You got me there. Sounds like a reason to avoid implementation inheritance. 
Ack!
Without implementation inheritance, we''d all be typing a lot more. Unless what you actually
mean is that it''s a reason to be able to seperate implementation inheritance from type inheritance. In which case I agree, some of the time.
quote:
I see your point (I recall writing code extremely similar to that, in fact), but I''m not so sure which the lesser of the two evils is.
Well,
I think the explicit version is the evil one.
quote:
quote:Other random features I''d like to see in a modern C-style programming language: multimethods and memoization. Or, ideally, a reflective metaprogramming system powerful enough to let me implement those in the language.
Is memoization the same as serialization? (I''ve never heard the term used before)
No.
memoization is
caching the return value of a function for each set of parameters it is called with.
If the function always returns the same value for the same parameters, particular sets of parameters are likely to be repeated, and the function is complex, then memoization can be a Big Win.
With a hit in performance, it is possible to let the function access variables other than its parameters and locals, if you ensure that you invalidate the cache when a variable it uses is changed. But if the function references a lot of variables, and if it isn''t called many times between being invalidated, then it probably shouldn''t be memoized.
If the parameters are likely to be different each time, then there is no point to memoization (but see below for a caveat).
int bar () { foo(rand(int::max));}// This is stupid, because x is highly unlikely to be the same// twice.int foo (memoize int x) { // Do complex stuff to x // return x;}
If the function is so simple that the time spent looking up the parameters in the cache will always outweigh the time it would take to process the function normally, then there''s never any reason to memoize it.
// This would be stupid, because incrementing i is// much much easier than looking up i in a cache.int add1 (memoize int i) { return ++i;}
If a parameter forms a continuous range, then it may be possible to memoize only discrete values from the range and interpolate between those values using a specified function.
A simple memoizing square root function might look like:
T sqrt<Number T> (memoize<0.01, memoize::linear> T value);
This declares a function that memoizes each value rounded to the nearest 0.01, and linearly interpolates between memoized values.
quote:
quote:Also, I greatly dislike the function/delegate distinction. If it looks like a function, smells like a function, and sounds like a function, I want to be able to put a pointer to it in a variable that points to a function.
I think everybody agrees with that. D separates functions and delegates because it has to, not because it''s the right thing. Delegates are implemented as a pair of pointers; a function pointer and context. (either an object instance or a stack frame) Function pointers are basically used for callbacks into C.
This is true. But if you read the standards for C and C++, you''ll note that the representation of function pointers is explicitly not specified. They are, amongst other things,
not officially compatible with any other kind of pointer. So, from C/C++''s point of view, it would be
valid for function pointers to include a pointer to some context.
quote:Original post by C-Junkie
What is D? D is C++ except without the stuff that makes C++ great,
Well, it
looks like D includes almost everything that I like in C++. Certainly, apart from MI, there''s nothing missing that I can''t live without. And even MI I can grudgingly do without. Are there any specific things you think are missing?
quote:
it''s C but with a bunch of extra clutter,
I''d say it''s only clutter if you''re
forced to use it, and if it doesn''t make your code clearer and more concise. The heavy-handed OOP of C#, also present in Java, which requires you to wrap even the "Hello, world" program in a class, is clutter. D, on the other hand, doesn''t do that.
In
my opinion, D introduces no notable clutter, except the distinction between delegates and functions. It also removes clutter relating to memory management.
quote:
its C# without all the nice libraries.
But you can use C libraries, many of which are
very nice, and many of which are in a much higher stage of development than currently available C# libraries.
quote:
So if you want a language that''s a mediocre imitation of a bunch of others, then D is right up your alley.
As is C, C++, C#...
