returning(...) ?

[Brian Candler]

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.