On Tue, Sep 04, 2007 at 06:37:20PM -0700, Zack Chandler wrote: > I like having the options of using the syntax sugar (when appropriate) > of returning and with_options. I totally agree that the framework can > do without due these idioms due to performance requirements but as an > app developer I'd like the option where cleanliness/beauty is valued > more than a small speedup.
I think this should be considered as two aspects: (1) Merb providing these constructs for application writers to use (2) Merb using these constructs itself For case (1), I have no problem with Merb providing an ActiveSupport-like feature bundle for users. My concern is whether Merb's extensions to Object, Hash etc would clash with similar extensions, like ActiveSupport. For case (2), this problem becomes more acute, since (for example) Merb may rely on a particular behaviour of Hash.from_xml, but ActiveSupport may implement Hash.from_xml differently, and itself rely on this different behaviour. It gets even more acute with people running Merb and Rails side-by-side in the same process. To solve this, I am pondering along the following lines: * Merb implements all these extension methods in a distinct namespace, e.g. Hash.merb_from_xml (or perhaps, for class methods, Merb::Hash.from_xml) * Merb's internal use of these constructs uses these distinct names * If a user 'require's a specific library, then these get aliased to the expected names, e.g. Hash.from_xml This means that: - Merb and language extensions (e.g. ActiveSupport/Facets/other ORM/other extensions) can be loaded simultaneously - Merb won't affect the behaviour of the extension library, and vice versa - If a programmer wants to use Merb's implementation of these language extensions, they are available given a 'require' Thoughts? Brian. _______________________________________________ Merb-devel mailing list Merb-devel@rubyforge.org http://rubyforge.org/mailman/listinfo/merb-devel
