struct A
{
void f() {std::cout << "A";}
};
struct B : A
{
void f() {std::cout << "B";}
};
//.,...
A a = B();
B b = B();
a.f();
b.f();
b.A::f();
This would print ABA, as the child's f() function simply hides the parent one when working in the context of B(), but it does not override it. struct A
{
virtual void f() {std::cout << "A";}
};
struct B : A
{
void f() {std::cout << "B";}
};
And: struct A
{
virtual void f() {std::cout << "A";}
};
struct B : A
{
virtual void f() {std::cout << "B";}
};
Therein lies an interesting dilemma. What if I wanted to prevent any child class of B, and only B, from changing the implementation of f. Under C++03, that is not possible. In C++11, final solves that. struct A
{
virtual void f() {std::cout << "A";}
};
struct B : A
{
void f() final {std::cout << "B";}
};
struct C : B
{
void f(); //I'm afraid I can't let you do that.
}; (|>) :: a -> (a->b) -> b
(|>) x f = f x
infixl 0 |>
There infixl 0 means infix operator with left associativity and 0 precedence. (5 + 3 |> show) ++ " times" |> putStrLn
Also, tying this back to one of the article's ideas, this piping-like syntax for doing things really manages to take away the emphasis from the function and put it back on the data. It isn't all about functions after all! (foldl * 1 '(1 2 3))
(* 1 (foldl * 1 '(2 3))
(* 1 (* 2 (foldl * 1 '(3))))
(* 1 (* 2 (* 3 (foldl 1 '()))))
(* 1 (* 2 (* 3 1)))
...
6
Basically, the calls to * start nesting into each other, so the one that actually gets evaluated first is the rightmost one. (define (foldl fn accum lst)
(if (null? lst)
accum
(foldl (fn accum (car lst)) (cdr lst))
)
)
Now if you expand this (dropping the tail recursion): (foldl * 1 '(1 2 3))
(foldl * 1 '(2 3))
(foldl * 2 '(3))
(foldl * 6 '())
6
And even though you think that such a tiny thing can't be a good implementations, it actually is super efficient. The tail recursion is automatically optimized for you (and you can assume that for any functional language - it's a very crucial optimization for this style of code, after all). That's what the core of it will be in an actual implementation, though with added error handling, type checking and so on. (apply * (list 1 2 3))
in order to get it to run on a list. No access code means a lower grade, all in the best interests of science.
I ... no. I can't even...
One caveat is the merging of the drops sometimes looks quite unnatural, but I'm not sure there's any simple way to represent that as just a couple of textures and a transformation, as real drops would have attractive forces on a molecular level pulling them towards one another once they're bridged, deforming pretty unevenly.