On Wed, 06 May 2015 16:54:46 +0000, Luís Marques wrote:
> * Regular expressions -> I have no idea what you have in mind for this
> one; even after looking at std.regex...
I meant both patterns and matches/captures.
> * Tokens -> On the one hand, I think this could be an excellent example,
> since it's a case where the bit pattern is arbitrary (because it
> generally has no numeric properties). On the other hand, I could see
> people arguing that just using an int is perfectly fine, so it doesn't
> benefit from a custom type. Do notice that, even in D, an enum converts
> without a cast to an int, so the fact that an enum might be used to list
> the possible abstract values (the tokens) doesn't quite make it a
> completely independent type, IMHO.
By tokens I mean the output of a lexer, usually looking like:
struct Token
{
Type type;
uint line, uint col;
string captured;
}
> * lazy generators -> explain, please?
Phobos is full of these. A simple example is the result of
std.range.iota. The motivation is that a generator is actually an
algorithm which happens to be wrapped up as a value.
> * digests -> do you mean the digest output, or the digest function
> state?
Certainly the output, haven't given much thought to the intermediate
state.
>> Frankly, the real divide in my mind is polymorphic/non-polymorphic, not
>> by-reference vs by-value, though I will occasionally use `final class`
>> if I want a convenience reference type around a resource.
>
> Aren't you arguing against yourself? In those cases you wanted your type
> to have reference semantics, even though it wasn't a polymorphic type.
> Doesn't that counterexample prove that polymorphic/non-polymorphic is
> just an heuristic, while the value/ref distinction is more fundamental?
Ideally they're orthogonal, though you need reference types to do true
dynamic polymorphism. Using `final class` is a pragmatic move given that
D conflates reference types with polymorphic types, i.e. if there were a
`ref struct` I'd use it.
