Required Reading: "How Non-Member Functions Improve Encapsulation"

Dukc ajieskola at gmail.com
Tue Oct 31 08:45:11 UTC 2017


On Monday, 30 October 2017 at 23:03:12 UTC, H. S. Teoh wrote:
> For example, suppose you're using a proprietary library that 
> provides a class X that behaves pretty closely to a range, but 
> doesn't quite have a range API.  (Or any other API, really.)  
> Well, that's not a problem, you just write free functions that 
> forward to class X's methods to bridge the API gap, and off you 
> go.  You don't have to work with your upstream provider, who 
> may not be able to provide a fix until months later, and you 
> don't have to create all sorts of wrapper types just to adapt 
> one API to another.

Yes, the idea here is great. It will work with range functions 
you define. The problem is, it won't work with Phobos functions 
because they do not see your extensions to that proprietary type. 
They see only the true member functions of it.

Unless you hack phobos and add your extensions to that propietary 
library there, which would be a very ugly solution.

You can of course wrap that proprietary range type but that is a 
lot of manual work and requires maintenance. Alias this solves 
some cases but not all of them.

I am not sure what would be the best way for the language to 
handle this but for sure not the present way. The idiom is 
otherwise so great.


More information about the Digitalmars-d mailing list