Hello, At least David Alan Black and Ben Tilly have been conversating, the latter's last comment being: > Say modules called ArrayInterface, HashInterface and > StringInterface. > > If you want to use it you would have to write []= and so > on, but the so-on to get the whole interface would be much > smaller than it would be now. Ok. I've been following this thread with great interest, but I've been somewhat lost. That's mostly due to my quite limited knowledge of Perl Tying concept. I always thought it's quite simple, but it's referred everywhere as pure magic. Now I guess I got on the map again. So if I understand correctly we would like to have (sorry being wordy, I just wanted to be clear): module StandardHashClassMethodInterface def []; end def new; end end module StandardHashInstanceMethodInterface def []; end # alias fetch def []=; end # alias store def delete; end def keys; end # or first_key, next_key iterators # which is probably better def has_key?; end # alias key? and # include? (which is in Enumerable too) # OTOH, this could be defined in terms of # Hash#keys, but we'd lose O(1) look-up def rehash; end end module StandardHashConvenienceInterface =begin Convenience methods can be described in terms of standard instance method interface. In most cases one would like to optimize some of these methods by redefining them. == clear default default= delete_if each each_key each_pair each_value empty? has_value? include? index indexes indices invert key? length member? reject reject! replace shift size sort to_a to_s update value? values =end end And then our current hash and all user defined hashes could be done by saying: class HashAlike include StandardHashInstanceMethodInterface # and by defining 6 or 7 methods the interface *requires* include Enumerable # and by redefining methods for speed if needed # like include? for Hash include StandardHashConvenienceInterface # and by redefining methods for speed if needed end Ben, is this explicit separation and grouping of methods to interfaces (which might be expressed by default in terms of other interfaces) what you have in mind? If so, then we might proceed to define interfaces for Strings and Arrays, and what else needed. If I understand the underlying concept correctly, by imposing some more structure to current classes, and keeping eye on backwards compatibility, we ease up documentation of current behaviour and implementation of user made FooAlike -datastructures. If we get Perl's TIE behaviour as a bonus, this is surely the way to go. This discussion reminds me of the recent String as IO (or the otherway round) thread. IIRC, the end result was that the APIs should be defined more clearly and then masquerading classes to act like other classes would be trivial. Aren't we approach that solution? - Aleksi