Can you elaborate?
Thanks Mostafa. I have the same Q.
Back in the day Jeremy told me he thought wrapper classes could be as efficient as function wrappers, but he couldn't convince others, thus BGL is functional. But I do remember seeing some convincing arguments against wrappers since then.
I would be very surprised if wrapper classes imposed any additional overhead (unless they're using virtual functions). I think Dave's argument comes from a perspective of supporting broader applicability. If a generic algorithm requires x.foo(), then you have a very strong requirement on the type of x, and you're forced to use wrapper classes for adaptation. If you write foo(x), then you just required some overload of foo for x. It gives you greater freedom to adapt the implementation to your type. Origin has a tendency to use a more OO-style for defining individual data structures, but uses the functional style in generic contexts. The concepts will be defined in terms of the free functions and not the data structures themselves. We'd like to support the idea writing g.size() should be the same as size(g). This lets users use OO-style when they know the type being operated on or the functional style when they only know the concept it models.
Also, do concept maps (RIP) fix this? I seem to remember some blurring between OO and functional there.
It would be interesting to see what people would do with concept maps. At the very least it adds another choice for adaptation. Free functions and traits, wrapper classes, and now concept maps (assuming they show up again). Andrew