4 ms·

There are two problems with that. 1. In practice you almost never want to load a random library that says it supports a certain interface, you will want a spec

There are two problems with that. 1. In practice you almost never want to load a random library that says it supports a certain interface, you will want a specific library. Notable exceptions are glibc where the interfaces are well-defined over several decades but that brings us to... 2. Few libraries implement the same exact interface. Mongrel and Unicorn have totally different interfaces. Phusion Passenger is also a web server but works in a fundamentally different way from either of them. Hpricot and Nokogiri are both XML parsers but their usage API is different.

derefr 16y ago
Thus, I imagine, why djacob's link to HTTPI talks about protocol adapters, rather than expecting the implementations to adhere to the protocols directly. Still, the adapters could come with each protocol-supporting gem, rather than being housed in some third party "interface library." Then we could have something more like this in each class of a gem: class Mongrel::HttpServer class HttpServerProtocolAdapter < Gem::ProtocolAdapter implements 'http-server' implements 'http-server/with-middleware-support' ... and the manifests (which would then look more like this:) {'http-server' => Mongrel::HttpServer::HttpServerProtocolAdapter, 'http-server/with-middleware-support' => Mongrel::HttpServer::HttpServerProtocolAdapter, ...} would be generated automatically at gem installation by loading the gem and then probing for ProtocolAdapter instances in ObjectSpace. Of course, if you had a class that matched the protocol exactly, you could just use something like class Mongrel::HttpServer supports_protocol 'http-server' end and be done with it. This is all assuming that we don't actually want our protocols to be modules or classes or something else that we have to include in the adapter somehow (because this is Ruby, and we do well without needing IDuck.) Instead, protocols would just be externally specified things, with their name-strings perhaps being the URIs of standards docs. At most, if a Gem::Protocol was a reified type, it would be a unit test suite to determine whether a ProtocolAdapter actually supported its protocol (minimally, via a series of #respond_to?s.)

derefr 16y ago

Thus, I imagine, why djacob's link to HTTPI talks about protocol adapters, rather than expecting the implementations to adhere to the protocols directly. Still, the adapters could come with each protocol-supporting gem, rather than being housed in some third party "interface library." Then we could have something more like this in each class of a gem: class Mongrel::HttpServer class HttpServerProtocolAdapter < Gem::ProtocolAdapter implements 'http-server' implements 'http-server/with-middleware-support' ... and the manifests (which would then look more like this:) {'http-server' => Mongrel::HttpServer::HttpServerProtocolAdapter, 'http-server/with-middleware-support' => Mongrel::HttpServer::HttpServerProtocolAdapter, ...} would be generated automatically at gem installation by loading the gem and then probing for ProtocolAdapter instances in ObjectSpace. Of course, if you had a class that matched the protocol exactly, you could just use something like class Mongrel::HttpServer supports_protocol 'http-server' end and be done with it. This is all assuming that we don't actually want our protocols to be modules or classes or something else that we have to include in the adapter somehow (because this is Ruby, and we do well without needing IDuck.) Instead, protocols would just be externally specified things, with their name-strings perhaps being the URIs of standards docs. At most, if a Gem::Protocol was a reified type, it would be a unit test suite to determine whether a ProtocolAdapter actually supported its protocol (minimally, via a series of #respond_to?s.)