Merb compat / API change recommendations

8 views
Skip to first unread message

Nate Wiger

unread,
May 28, 2008, 9:31:38 AM5/28/08
to merb
Based on the previous Merb / Rails compatibility thread here:

http://groups.google.com/group/merb/browse_thread/thread/2327341145a4cb66/bdd3621131191c78

Ezra asked for a list of API nitpicks, pre-1.0. So I'm establishing
this thread to do so.

Here is my list. Most are simple suggestions that can avoid potential
support timesinks. I can help with patching if needed.

If others have recommendations, please post them here as well. A
couple guidelines: (1) Be clear, (2) Be succinct, (3) Be nice.
Thanks.

===========================================================================
I'm basing this on Ngoc's blog/wiki port to Merb here:

http://openkh.rubyforge.org/svn/branches/merb-activerecord/app/controllers/users.rb

As well as discussions and questions I've seen on this group so far.


Controllers
----------------------------------------
1. Merb.logger.debug - recommend dropping the "Merb.", it's repetitive
to look at and type

2. before/after - recommend using before_filter/after_filter since the
functionality is the same

3. This looks awkward

def index
render('', :layout => :application)
end

Can we add a render() keyword for clarity?

render :nothing, :layout => :application

4. The provides() vs only_provides() difference is confusing, just
because of the method inconsistency vs the rest of Merb. I don't have
a suggestion yet that would be a workable method signature.


Helpers
----------------------------------------
1. I'm not sure if Ngoc's port is accurate, but why are the helpers
injecting into Merb's GlobalHelpers? Seems monkey-patchy. If Ngoc's
port is accurate, can't Merb do this under the covers, rather than
exposing it? That would clean up the interface, and offer protection
for Merb in case Merb's internal API needs to change in the future.


Views
----------------------------------------
1. Provide a url_for wrapper around url().

2. Provide a heckuva Wiki page for everything else :-)


Configuration
----------------------------------------
1. Add support for the Rails-style initializers/ directory. This is a
simple nicety that will be a "Why don't my initializers work?"
question otherwise (already popped up in this google group)

2. Standardize the "merb more" and "merb plugin" names to all use "_",
ie, "merb_assets", "merb_cache", etc. Otherwise it'll be another
support timesink of answering, "No, it's merb *dash* cache, but merb
*underscore* paginate".

3. Change the default router.rb file to use "|map|" like Rails.
Everyone's used to "map.resources". Yes, people can change it
themselves, but providing it the same as people are used to will save
support questions.

Julian Leviston

unread,
May 28, 2008, 10:21:57 AM5/28/08
to me...@googlegroups.com
I don't like ANY of those suggestions at all.

The merb equivalents are much more brief, and better.

If people want rails compatibility, why not offer a merb_rails plugin
solely for this purpose.

Julian.

Michael Klishin

unread,
May 28, 2008, 10:22:43 AM5/28/08
to me...@googlegroups.com
2008/5/28 Nate Wiger <nwi...@gmail.com>:

> 1. Merb.logger.debug - recommend dropping the "Merb.", it's repetitive
> to look at and type

Then if someone has logger method or variable in the app, it will clash.
If you want to save yourself some typing, use ctags/etags, Merb textmate
bundle or IDE.

Wrappers IMO go into plugin — not every app our there,
not every developer out there would need it.

I want to stress it again in this very same thread: if you want to
make transition from Rails simple for people, write in depth
tutorial and post it on Merbunity and help fix bugs. This is what's
important, not making API
exactly as in Rails. People who get off the rails hook usually know
what they do and what they need.

I don't know if I was nice, this "lets make Rails out of Merb" thing
seems insignificant to me.
--
MK

Matthijs Langenberg

unread,
May 28, 2008, 10:30:12 AM5/28/08
to me...@googlegroups.com
I fully agree with Michael and Julian.
Merb shouldn't feel like a Rails drop-in, just because it isn't.

I actually prefer render('') above render(:nothing), because you
aren't returning nothing, you are returning an empty string, which
looks a bit awkward because it is a bit awkward to return an empty
response.

The other changes just don't matter.

On Wed, May 28, 2008 at 4:22 PM, Michael Klishin
<michael....@gmail.com> wrote:
> 2008/5/28 Nate Wiger <nwi...@gmail.com>:
>> 1. Merb.logger.debug - recommend dropping the "Merb.", it's repetitive
>> to look at and type
>
> Then if someone has logger method or variable in the app, it will clash.
> If you want to save yourself some typing, use ctags/etags, Merb textmate
> bundle or IDE.
>

> Wrappers IMO go into plugin -- not every app our there,

Michael D. Ivey

unread,
May 28, 2008, 10:47:20 AM5/28/08
to me...@googlegroups.com
On May 28, 2008, at 8:31 AM, Nate Wiger wrote:
> 4. The provides() vs only_provides() difference is confusing, just
> because of the method inconsistency vs the rest of Merb. I don't have
> a suggestion yet that would be a workable method signature.

There are 3 methods: provides, only_provides, and does_not_provide.
They each do exactly what they say. Obviously, I'm biased, since I
wrote them, but I think they're perfect. :)

The nice thing about provides not overwriting the list is that you can
do "provides :foo" in a parent class, then only "provides :bar" in the
controllers that do :bar.


> 1. Provide a url_for wrapper around url().

I don't get this one. What would url_for do?


> 1. Add support for the Rails-style initializers/ directory. This is a
> simple nicety that will be a "Why don't my initializers work?"
> question otherwise (already popped up in this google group)

This one is a good example of a real philosophy difference. If you
want to split up your application load process, you have complete
control over init.rb ... Merb doesn't push you to do it any particular
way. It would be trivial to add a few lines to support an
initializers/ directory ... so since it's trivial, we choose not to do
it. Trivial patches are sometimes a code smell...if it's trivial,
maybe we don't need it at all.


> 2. Standardize the "merb more" and "merb plugin" names to all use "_",
> ie, "merb_assets", "merb_cache", etc. Otherwise it'll be another
> support timesink of answering, "No, it's merb *dash* cache, but merb
> *underscore* paginate".

I think we need to have 1 final revisit of this one, and if we decide
not to change, make a wiki page that explains why it is this way, and
why we're not changing it.

Jed Hurt

unread,
May 28, 2008, 11:03:37 AM5/28/08
to me...@googlegroups.com
On Wed, May 28, 2008 at 8:47 AM, Michael D. Ivey <michae...@gmail.com> wrote:
It would be trivial to add a few lines to support an
initializers/ directory ... 

Ngoc Dao

unread,
May 28, 2008, 12:38:54 PM5/28/08
to me...@googlegroups.com
> I'm not sure if Ngoc's port is accurate, but why are the helpers injecting into Merb's GlobalHelpers? Seems monkey-patchy.

Hi.

I am doing this because of the module architecture of this CMS, I want
all the helpers to be horizontal: views of a controller/helper can
call helpers of others. Notice that helpers of module xxx are prefixed
with xxx_, ex: users_gravatar(user)

Ngoc.

Nate Wiger

unread,
May 28, 2008, 12:50:41 PM5/28/08
to merb
>> 1. Merb.logger.debug - recommend dropping the "Merb.", it's repetitive
>> to look at and type
>
> Then if someone has logger method or variable in the app, it will clash.

Obviously. But the same can be said of all Merb methods. I'm sure you
wouldn't want to have to say

class MyController
Merb.before ...
Merb.provides
def index
Merb.logger.debug "foo"
Merb.render :layout => :application
end
end

You're also missing the point that "logger.debug" is not only easier
on the eyes, but One Less Thing to have to explain is different.

> > It would be trivial to add a few lines to support an
> > initializers/ directory ...
>
> That's what Collective does. No Big Deal.http://github.com/meekish/collective/tree/master/config/init.rb#L40-43

Sure. But it probably took more time to mention it in this thread than
it would just to integrate that into Merb.

Here's a scenario: Some people using Merb like "initializers", but
others decide "startups" is better. Now, some Merb plugins use a
startups/ directory, whereas others use initializers/. So now you have
two (or more!) ways that people have to learn... that have to be
documented, Wiki'ed, and answered in mailing lists such as this.

> I want to stress it again in this very same thread: if you want to
> make transition from Rails simple for people, write in depth
> tutorial and post it on Merbunity and help fix bugs.

I think you are underestimating the amount of a time that superficial
compatibility can save - in development, documentation, and support.
Writing a new framework is the fun part, but supporting it can be
hell, and your support timesinks are almost always seemingly inane
differences ("before" instead of "before_filter").

Putting on my manager hat, I'm a bit concerned by the tone of the
responses in this thread, and whether Merb will be properly
supported. I'm not trying to throw stones, but if you haven't had the
"joy" of supporting a large piece of software, used in ways you never
intended or even forsaw, I would urge you to rethink some of the
suggestions I made above.

Nate Wiger
PlayStation

Matt Aimonetti

unread,
May 28, 2008, 12:59:45 PM5/28/08
to me...@googlegroups.com
Good listing Nate, thanks a lot.




4. The provides() vs only_provides() difference is confusing, just
because of the method inconsistency vs the rest of Merb.  I don't have
a suggestion yet that would be a workable method signature.

http://merbunity.com/tutorials/9

By default, all actions provide :html

There's a number of methods to help make this not only easy, but flexible.

  • provides - provides each of the given formats + :html
  • only_provides - only provides the supplied formats. It does not include the default of :html or any other previously set formats.
  • does_not_provide - turns off responses for this format
  • clear_provides removes all response formats. You won't get very far in your app if you use this in a controller. But it can be a handy spec'ing tool
  • reset_provides - resets the provided formats to the defaults. :html

Each of these methods are called with a list of symbols representing the formats to operate on.


2. before/after - recommend using before_filter/after_filter since the
functionality is the same


I personally don't like before_filter I think before and after are easier to use. If it doesn't affect the code complexity and performances, I don't see a problem with adding an alias tho.


1. Provide a url_for wrapper around url().

url_for is really not something we have in Merb since we don't guess urls based on the attributes passed. Our url method isn't as smart but is very efficient.



2. Provide a heckuva Wiki page for everything else :-)

Totally agree on that one!


3. Change the default router.rb file to use "|map|" like Rails.
Everyone's used to "map.resources".  Yes, people can change it
themselves, but providing it the same as people are used to will save
support questions.


I think the reason because we use Merb::Router.prepare do |r| is because you are passing the router (r) not a map. Your routes will end up looking like that:

Merb::Router.prepare do |r|
  # RESTful routes
 
  r.namespace :admin do |admin|
    admin.resources :content_owners
    admin.resources :publishers do |publisher|
      publisher.resources :assets
      publisher.resources :content_partners
    end
    admin.resources :users
    admin.resources :stats
  end
end

it personally makes more sense to me. But maybe I didn't understand what you meant.




2. Standardize the "merb more" and "merb plugin" names to all use "_",
ie, "merb_assets", "merb_cache", etc.  Otherwise it'll be another
support timesink of answering, "No, it's merb *dash* cache, but merb
*underscore* paginate".
Yeah that became a bit of a mess. underscore was reserved to "not core" plugin and dash was for core supported stuff.... we might want to review that soon.


-Matt

Ngoc Dao

unread,
May 28, 2008, 1:11:44 PM5/28/08
to me...@googlegroups.com
I prefer xxx_filter. If it is a filter then why not call it a filter?
If you look at the log output, for every request you will see
something like:
{:action_time=>0.011294, :before_filters_time=>0.00018,
:after_filters_time=>4.5e-05, :dispatch_time=>0.011568}

> underscore was reserved to "not core" plugin and dash was for core supported stuff.... we might want to review that soon

In Merb 2.0, things might go into or out of the core (who knows? :D).
This might cause renaming problems.

Ngoc.

Matt Aimonetti

unread,
May 28, 2008, 1:23:44 PM5/28/08
to me...@googlegroups.com
good points Ngoc. Anyone intersted in adding an alias and submit a patch for before_filter and :after_filter? (if an alias is doable)


-Matt

Michael D. Ivey

unread,
May 28, 2008, 1:33:19 PM5/28/08
to me...@googlegroups.com
On May 28, 2008, at 11:50 AM, Nate Wiger wrote:
> You're also missing the point that "logger.debug" is not only easier
> on the eyes, but One Less Thing to have to explain is different.

"One Less Thing to have to explain is different" isn't a compelling
argument for the core team. I understand that you wish it were, but
it just isn't. We're not building Merb to be a "Better Rails" or any
kind of "n Rails" (for your favorite values of n).

We're building Merb to be the awesomeness. So arguments based on "Do
X and Merb will be more awesome" will be well received. Let's focus
on those things, and stop worrying about the Rails comparisons.

Dudley Flanders

unread,
May 28, 2008, 1:40:03 PM5/28/08
to me...@googlegroups.com
> Putting on my manager hat, I'm a bit concerned by the tone of the
> responses in this thread, and whether Merb will be properly
> supported. I'm not trying to throw stones, but if you haven't had the
> "joy" of supporting a large piece of software, used in ways you never
> intended or even forsaw, I would urge you to rethink some of the
> suggestions I made above.

One of the biggest advantages that Merb has is its comprehensibility.
If you need someone else to "support" your software, you should be
using a bigger framework like Rails, or possibly Struts. I chose Merb
because using Merb meant I didn't need to depend on someone for
support. If Merb-the-community disappeared tomorrow, I would still
have a chunk of well-written, easy-to-understand code underlying my
application. At any given point, I could stop following the changes
coming from upstream, and simply treat the Merb code as part of my
application that someone saved me the trouble of writing myself. Merb
is (and hopefully will remain) a hacker's framework, not a manager's
framework.
Having said that, I was also pretty disappointed by the tone of this
thread. I don't think it's representative of the core team's attitude
in general.

:dudley

Ezra Zygmuntowicz

unread,
May 28, 2008, 1:49:56 PM5/28/08
to me...@googlegroups.com
Hi~

On May 28, 2008, at 6:31 AM, Nate Wiger wrote:
>
> Based on the previous Merb / Rails compatibility thread here:
>
> http://groups.google.com/group/merb/browse_thread/thread/2327341145a4cb66/bdd3621131191c78
>
> Ezra asked for a list of API nitpicks, pre-1.0. So I'm establishing
> this thread to do so.
>
> Here is my list. Most are simple suggestions that can avoid potential
> support timesinks. I can help with patching if needed.
>
> If others have recommendations, please post them here as well. A
> couple guidelines: (1) Be clear, (2) Be succinct, (3) Be nice.
> Thanks.
>

> =
> =
> =
> =
> =
> ======================================================================

> I'm basing this on Ngoc's blog/wiki port to Merb here:
>
> http://openkh.rubyforge.org/svn/branches/merb-activerecord/app/controllers/users.rb
>
> As well as discussions and questions I've seen on this group so far.
>
>
> Controllers
> ----------------------------------------
> 1. Merb.logger.debug - recommend dropping the "Merb.", it's repetitive
> to look at and type

Add your own helper method if you want this to be shorter:

def logger
Merb.logger
end


>
>
> 2. before/after - recommend using before_filter/after_filter since the
> functionality is the same

Definitely *not* going to happen. I always hated before_filter when
before/after is plenty good enough. This definitely will not change.


>
>
> 3. This looks awkward
>
> def index
> render('', :layout => :application)
> end
>
> Can we add a render() keyword for clarity?
>
> render :nothing, :layout => :application

Why do you want to render an empty layout with nothing inside? I don't
see a good reason to add yet another magic keyword here. Merb's render
philosophy is completely different from rails since return values of
merb actions are sent to the browser.


>
>
> 4. The provides() vs only_provides() difference is confusing, just
> because of the method inconsistency vs the rest of Merb. I don't have
> a suggestion yet that would be a workable method signature.

I don't see any confusion here, these methods always made perfect
sense to me. Maybe we just need more docs but this is not going to
change either, it is one of merb's nicer features.


>
>
>
> Helpers
> ----------------------------------------
> 1. I'm not sure if Ngoc's port is accurate, but why are the helpers
> injecting into Merb's GlobalHelpers? Seems monkey-patchy. If Ngoc's
> port is accurate, can't Merb do this under the covers, rather than
> exposing it? That would clean up the interface, and offer protection
> for Merb in case Merb's internal API needs to change in the future.

I don't know what know what you are talking about here.


>
>
>
> Views
> ----------------------------------------
> 1. Provide a url_for wrapper around url().

Merb does not have url_for so this makes no sense


>
>
> 2. Provide a heckuva Wiki page for everything else :-)

We're working on this, the wiki is starting to get a lot of content.

>
>
>
> Configuration
> ----------------------------------------
> 1. Add support for the Rails-style initializers/ directory. This is a
> simple nicety that will be a "Why don't my initializers work?"
> question otherwise (already popped up in this google group)

I'm still on the fence on this one. I might be swayed to add it but
it's so trivial that it's easy for folks to add themselves.


>
>
> 2. Standardize the "merb more" and "merb plugin" names to all use "_",
> ie, "merb_assets", "merb_cache", etc. Otherwise it'll be another
> support timesink of answering, "No, it's merb *dash* cache, but merb
> *underscore* paginate".

This is probably a good idea to cleanup soon.

3. Change the default router.rb file to use "|map|" like Rails.
> Everyone's used to "map.resources". Yes, people can change it
> themselves, but providing it the same as people are used to will save
> support questions.


Merb's router is fundamentaly a different beast then rails router. It
is not a map so map has no meaning here. You are free to change this
if you want but you are not passing a map to the block you are passing
a route set.


I'm happy to see people thinking about these things but merb is not
rails and never will be. Some of these changes need to be made but
most of them are just rails habits that need to be retrained.

Cheers-


- Ezra Zygmuntowicz
-- Founder & Software Architect
-- ez...@engineyard.com
-- EngineYard.com

Ezra Zygmuntowicz

unread,
May 28, 2008, 1:52:52 PM5/28/08
to me...@googlegroups.com

On May 28, 2008, at 9:50 AM, Nate Wiger wrote:
>
> Putting on my manager hat, I'm a bit concerned by the tone of the
> responses in this thread, and whether Merb will be properly
> supported. I'm not trying to throw stones, but if you haven't had the
> "joy" of supporting a large piece of software, used in ways you never
> intended or even forsaw, I would urge you to rethink some of the
> suggestions I made above.


Merb will be properly supported because it is *way* simpler to
support than rails. The code base is simple and that is a huge
advantage. I've supported many large pieces of software and I will
take maintaining merb over rails any day of the week. You have nothing
to worry about here.

The thing to keep in mind is that merb is not rails, there are some
fundamental differences in opinion and that is ok, you just have to
learn to accept it. Merb will pay huge dividends whenever you have to
peek under the hood and I cannot stress enough how much of an
advantage this is

j3tch1u

unread,
May 28, 2008, 2:11:52 PM5/28/08
to merb
1. one could argue caches_page/caches_action (instead of cache_page/
cache_action) are more correct in the sense that "to cache" (the verb)
is not actually caching anything at that moment but rather setting up
something to be cached.
2. i think before_filter/after_filter should be aliased and deprecated
down the road (btw, what happened to around?). like ms does, embrace
and extend.
3. render file doesn't work in views, i've had to rewrite a lot of
those.
4. i like js_include_tag, css_include_tag, but i still think the old
ones could be aliased and deprecated. you'd be surprised at how many
ppl a couple of lines can help. remember, ppl's rails apps are like
their babies too--they wanna get their feet wet before diving in.
5. sometimes it's not the syntax but rather the behavior. ex, if i do
partial('p', :foo=>'funny') and in my partial: foo ||= 'not funny' (i
expect: funny, but get: not funny).

i think the key is to have the most elegant/concise syntax while
aliasing/deprecating the close calls (i don't believe there are that
many). what ez needs are the names and numbers rather then full-on
debates over each (let him be the decider). no need to search for
them, just report em if you come across em. hopefully by 1.0 this
group will have logger.silence do again; end.

Matt Aimonetti

unread,
May 28, 2008, 2:20:04 PM5/28/08
to me...@googlegroups.com
Dudley,  I agree with your comments. I think it's good to acknowledge realize that there have been a lot of tension lately caused by a lot of people migrating from Rails to Merb and some hardcore Merbists.

Rails is very opinionated (which is totally ok) but so is Merb ;) In a different way tho.
Merb's philosophy is that we don't want to force you to do things one way because we think it's the best thing ever and that will make your life easier. Generally, things are a bit harder in Merb, often different than Rails but we can "usually" find a valid justification and that's why Merb is faster/leaner.

Because we want to keep things flexible, the Merb framework doesn't have all the easy tools Rails would provide you with... but at the same time, it's quite easy to maintain Merb's fresh, simple and clean code compared to Rails, older/crustier code.

Anyway, to come back to the tone of the thread, I think some people are getting a bit upset by the newcomers who want to change Merb to be more like Rails. I personally think it's totally normal to want some similarities when you never had any issues with Rails. Same thing happens with people coming from Django. 
However instead of just saying no, we probably should justify a bit better why we are saying no ;)

A potential solution would be to have a wiki page explaining some of the decisions so we wouldn't constantly have to repeat the same things over and over. ( plus we could get quotes from some of the core team members ;) )

-Matt

j3tch1u

unread,
May 28, 2008, 2:28:34 PM5/28/08
to merb
didn't see your post ez (was writing mine). all your points are valid
and i wouldn't dare disagree. with all due respect tho,

def logger
Merb.logger
end

is three locs for merb and 3 * (who knows how many apps) locs for
something as common/short/sweet/as/logger. i can totally see where
you're coming from tho..i just don't wanna dirty my babies up either
man! hmmm merb_is_not_rails gem is not sounding so bad after all.
cheers.

-ben

Michael D. Ivey

unread,
May 28, 2008, 3:49:28 PM5/28/08
to me...@googlegroups.com
On May 28, 2008, at 1:11 PM, j3tch1u wrote:

> i still think the old ones could be aliased and deprecated

The key point to take away here is that there are no old ones.

Merb != (Rails += 1)

Ben Nevile

unread,
May 28, 2008, 4:15:14 PM5/28/08
to me...@googlegroups.com
> i still think the old ones could be aliased and deprecated

The key point to take away here is that there are no old ones.

Merb != (Rails += 1)


Hi Michael and other core contributors,

I understand what you are saying above.  And it certainly is up to you, as framework heavyweights, to decide what is important and what isn't.  

I don't want to belabor this point further.  I just want to say that like the English language, the Rails "language" is a common set of symbols that many of us understand. As merb's popularity grows - and it will! - this community is going to be inundated with programmers migrating from Rails.  Design of any sort - architecture, web interface, and framework API - is about the relationship between whatever it is that you're designing and the people using it.

Ben

Ezra Zygmuntowicz

unread,
May 28, 2008, 4:16:51 PM5/28/08
to me...@googlegroups.com
Yes it is just a few lines, but the bigger issue is that to make this
'logger' method available everywhere we would have to add it to Kernel
which makes it effectively global. So if any other gems or piece of
code you use defines a logger method then things break.

Merb very much so wants to play nice with *any* ruby code you may
want to run in your app, so I'd like to avoid adding more methods to
Kernel, we have too many already. Maybe we could add it to the
application controller or a mixin that you could explicitely mixin.
I'm up for ideas here, but don;t want to make another global method.

I don't want anyone to think that Merb is not open for new ideas. But
I really think all of these make merb more like rails requests belong
in plugins. Merb id definitely *not* rails and the sooner you can stop
leaning on rails crutches the sooner you will become one with the merb
codebase.

I have a fundamental difference of opinion in merb, in rails hardly
any users ever go into the framework code. In merb I don't want this
to be the case, merb is a hackers framework, It is not and never will
be batteries and training wheels included like rails is.

But the upside of all this is that merb is extremely easy to extend
to make it do whatever you want. It would be very easy for some
enterprising individual to make a
merb_acts_like_rails_with_training_wheels plugin that makes the life
of folks porting their rails apps to merb easier. But merb does not
exist as a rails alike that is only meant for porting apps to.

Fundamentally, Merb is a platform rather then a full stack framework.
Use the pieces you want, leave the rest alone. This makes merb a more
scalable solution for the future as we can leave all the bloat out of
the core and plugins have clearly defined API's for hooking into the
framework.

I think the best solution for all of this is for folks who really
want this stuff to make the merb_as_rails plugin and use that. But I
highly encourage folks to only do something like that if they have a
large app to port. If you start with merb from scratch or are porting
a small app, it may take you a few hours extra but you will be better
off using the real merb idioms that have a lot of thought and
experience put into them.

Cheers-
-Ezra

- Ezra Zygmuntowicz

Ezra Zygmuntowicz

unread,
May 28, 2008, 4:24:29 PM5/28/08
to me...@googlegroups.com


Ben-

I don't want anyone to think that merb core folks are resistant to
change and are just downplaying folks concerns. We hear you loud and
clear. But if merb just copies everything rails does then what is the
point? Merb is an evolution of rails it is not a port or copy. I do
not want to hinder merb's clean api with concerns about porting apps
from rails. If merb just adopts all of rails apis it will be no better
off then rails itself is.

So I think the best thing for folks all around is to make a plugin
that is a rails compatibility shim that folks porting apps can use.
Also we should add a few wiki pages with descriptions of why and how
merb's api's differ from Rails apis to help folks coming from rails to
merb.

I understand how people fresh off the rails boat may get confused
about some of this stuff, but we will just have to document the
differences and why they exist. Rails IMHO has grown *way* to big for
a framework, this is why people run into the wall when they need to do
something that is not "on the golden path". I will not make this same
mistake in merb.

Cheers-

Michael Klishin

unread,
May 28, 2008, 4:39:04 PM5/28/08
to me...@googlegroups.com
2008/5/28 Ben Nevile <ben.n...@gmail.com>:

> I don't want to belabor this point further. I just want to say that like
> the English language, the Rails "language" is a common set of symbols that
> many of us understand.

Ben,

As person who can read 4 (natural) languages I should say nothing
benefits your brain
as much as learning a new language or living in a country that has
different culture from
your home land.

It even makes you understand your mother tongue better in some ways. This is
just another point of keeping Merb's "post Rails" decision around for years.
--
MK

Michael Klishin

unread,
May 28, 2008, 4:53:03 PM5/28/08
to me...@googlegroups.com
2008/5/28 Dudley Flanders <dud...@misnomer.us>:

> Having said that, I was also pretty disappointed by the tone of this
> thread. I don't think it's representative of the core team's attitude
> in general.

Attitude of most active Merb contributors is to keep Merb's philosophy
in place => keep Merb's benefits for those who need it. Nothing else.

To keep your ideas in place you have to give up on some of the
opposite ideas. And it
pisses someone off.

What's I especially like about that thread is that no one from people
who need "Rails compatibility"
so bad they spend hours arguing actually submitted a few lines patch,
kicked off merb plugin project
at github or ever asked what *they* can do about it.

They just give recommendations.
--
MK

Matt Aimonetti

unread,
May 28, 2008, 5:12:47 PM5/28/08
to me...@googlegroups.com
Michael, take it easy :)

People didn't submit patches because they wanted to know why we were not doing things the way they expected us to do it. Now that they have a clearer answer from Ezra, I'm sure we will see few patches and hopefully a rails idioms plugin for Merb.

I actually thought that the people asking for the Rails syntax were quite nice about it. I do disagree with the reasoning, but I really appreciated Ezra's reply explaining the reasons why things are the way they are right now.

I'm off to the Rails Conf, I know for a fact that at least Yehuda and Ezra should be around if you have any questions regarding Merb. I think Yehuda also has a Merb BoF talk scheduled.

Finally, we'll more than likely announce the first Merb Camp planned for October 08 (planning on 10-11) in San Diego California. So if you couldn't make it to Rails Conf, plan a trip to Southern California!

-Matt

Jed Hurt

unread,
May 28, 2008, 5:17:22 PM5/28/08
to me...@googlegroups.com
Perhaps all mailing list posts should be automatically appended with a sig: "The views and opinions expressed by the members of this mailing list do not necessarily reflect the views of Merbivore, Inc." ;)

Dudley Flanders

unread,
May 28, 2008, 5:50:31 PM5/28/08
to me...@googlegroups.com

On May 28, 2008, at 3:53 PM, Michael Klishin wrote:

> 2008/5/28 Dudley Flanders <dud...@misnomer.us>:
>> Having said that, I was also pretty disappointed by the tone of this
>> thread. I don't think it's representative of the core team's attitude
>> in general.
>
> Attitude of most active Merb contributors is to keep Merb's philosophy
> in place => keep Merb's benefits for those who need it. Nothing else.

I said "core team", not "active Merb contributors".

> What's I especially like about that thread is that no one from people
> who need "Rails compatibility"
> so bad they spend hours arguing actually submitted a few lines patch,
> kicked off merb plugin project
> at github or ever asked what *they* can do about it.

Most of these API changes are technically trivial. Implementing them
is easy, deciding whether they're a good idea is the harder part.

:dudley

Michael Klishin

unread,
May 28, 2008, 5:59:07 PM5/28/08
to me...@googlegroups.com
2008/5/29 Dudley Flanders <dud...@misnomer.us>:

> I said "core team", not "active Merb contributors".

what is core team other than active contributors? buzzword from
Rails world? with git everyone is on the core team.

> Most of these API changes are technically trivial. Implementing them
> is easy, deciding whether they're a good idea is the harder part.

It is much easier to convince people by doing change first, then showing
it to them. Rails core team (c) (tm) once made a decision that all
change requests
that have no patches are closed as invalid right away. It was back in
2006 I think.
Think why.

--
MK

Dudley Flanders

unread,
May 28, 2008, 6:42:22 PM5/28/08
to me...@googlegroups.com

On May 28, 2008, at 4:59 PM, Michael Klishin wrote:

>> Most of these API changes are technically trivial. Implementing them
>> is easy, deciding whether they're a good idea is the harder part.
>
> It is much easier to convince people by doing change first, then
> showing
> it to them. Rails core team (c) (tm) once made a decision that all
> change requests
> that have no patches are closed as invalid right away. It was back in
> 2006 I think.
> Think why.

You're saying it's right because Rails does it? I'm getting some mixed
signals here ;-) You're absolutely right that it's easier to convince
people with code, but that doesn't make discussion without code
"invalid" or "insignificant".

:dudley

Ben Nevile

unread,
May 28, 2008, 7:13:35 PM5/28/08
to me...@googlegroups.com
 
What's I especially like about that thread is that no one from people
who need "Rails compatibility"
so bad they spend hours arguing actually submitted a few lines patch,


That's because everybody who commented had already figured out the merb way.  We don't need a patch now that we know how.  

To be clear, I never tried to argue that i NEED any rails compatibility.  I was just pointing out that without it, this same meme is going to appear over and over.  If someone does eventually write a merb_rails_training_wheels gem, it will be out of frustration with the recurring theme.

Ben

Peter Dirickson

unread,
May 28, 2008, 7:17:36 PM5/28/08
to me...@googlegroups.com
I think more documentation is really necessary and post like these can help us all:

http://freelancing-gods.com/posts/migrating_code_from_rails_to_merb
http://www.wikivs.com/wiki/Merb_vs_Ruby_on_Rails (I don't like the title of this wiki 'Merb vs Rails' should be more like 'Merb and Rails differences')

Because at some point newbies to the Ruby frameworks will probably put his hand first in a Merb app and then he'll be or not using Rails and face the same questions, why in Rails it's called before_save instead of just save and so on?

So is rails_plugin needed for Merb to aliases some methods or add more helpers and vice versa? Maybe not, maybe yes, it all depends like someone said, we are learning a new language and new APIs and we get used to it or we can patch, fork it and contribute or not.

Cheers,

Peter.

Jed Hurt

unread,
May 28, 2008, 7:42:44 PM5/28/08
to me...@googlegroups.com
[Meet Merb](https://peepcode.com/products/meet-merb-pdf-draft) is written for peeps migrating from Rails to Merb. I'm sure Geoffrey will finish it once Merb hits one dot oh.

Michael Latta

unread,
May 28, 2008, 7:50:57 PM5/28/08
to me...@googlegroups.com
To take Ben's point further, I would rather program in a more
consistent and structured language. Please do not make Merb the
english language of frameworks where you borrow words from
everywhere. (Not that I am worried that would happen). Yes what we
are familiar with appears more natural, but that is just habit.

Michael


On May 28, 2008, at 1:15 PM, Ben Nevile wrote:

Michael Latta

unread,
May 28, 2008, 7:54:29 PM5/28/08
to me...@googlegroups.com
I vote for no more global methods as well. I also vote for not having
mixins or "magic". Writing code is 20% at most of the time. Reading
code is 90%. Keep it clear over short.

I do not use Rail's logger method because it does not work everywhere,
and I do not want to have multiple idioms, so I use
RAILS_DEAULT_LOGGER which is quite a keyboard full, but always works.
I like having Merb provided services tagged with Merb and not
magically available. It makes it easier for a new person to know
where to look for docs and info on the code and it makes name clashes
impossible.

Michael

Yehuda Katz

unread,
May 28, 2008, 10:49:27 PM5/28/08
to merb
Guys,

Just a few clarifications. Very early in the project (0.4.x), we
discussed making Merb a literal drop-in replacement for Rails. Even
back then, before the days of provides/display and other fundamental
philosophical differences between Merb and Rails, we decided that
attempting to maintain compatibility with the ever-changing landscape
of Rails idioms would conflict (from a purely time perspective). As
Merb diverged somewhat from Rails philosophically, it became less and
less appealing to try and maintain a shim.

We, for instance, really really disliked respond_to (why call a method
in a framework respond_to when the language itself has a respond_to?
method). I know it personally confused me a LOT back in the days of
1.2, and we just considered our provides framework (with a sprinking
of content_type flow control) to be a superior way of doing things.
Similarly, we considered our gem-based plugins to be fundamentally
superior to Rails' plugin system, in a philophically conflicting way.

In a few cases (before vs. before_filter), we chose to go with the
cosmetic. Frankly, I'm not really sure in what way before_filters are
a "filter" at all. Sure, it *sometimes* filters out requests, but
other times it's simply just an implementation of AOP using the Rails/
Merb dispatcher. Basically, what I'm getting at is that while a few
decisions that might seem annoying at present might appear to be
purely cosmetic, we considered (and rejected) the approach of trying
to work-alike to Rails. We also considered, fairly carefully, the
specific departures that we made from Rails "vocabulary" and made
decisions based on elegance or clarity.

With all that said, you have a very good point. People coming in from
Rails expect certain vocabulary. They are not necessarily expecting a
dialect of the Rails vocabulary (it's easy to be tripped up by small
changes when so much of the overall scheme is identical). Nobody, for
instance, would expect CakePHP to use identical terms, because it's
fundamentally so different to begin with. The solution, in my opinion,
is substantially better documentation ("Provide a heckuva Wiki page
for everything else :-) ").

A shim might work for some cases, but my sense is that the
philosophical mismatches might make it more trouble in the long run
than it's worth. Also, in the case of small changes to the public API,
you would need to wait for the person maintaining the shim plugin to
update it, rather than have a clearly defined upgrade path. If you're
willing to take those risks, I'd have no problem with someone putting
together a merb_acts_like_rails plugin.

I think the root of the issue, however, is in a lack of a prominent
document that clearly maps Rails idioms onto Merb ones (like the
Test::Unit => Rspec document).

Hope all that made sense.

-- Yehuda

On May 28, 2:12 pm, "Matt Aimonetti" <mattaimone...@gmail.com> wrote:
> Michael, take it easy :)
>
> People didn't submit patches because they wanted to know why we were not
> doing things the way they expected us to do it. Now that they have a clearer
> answer from Ezra, I'm sure we will see few patches and hopefully a rails
> idioms plugin for Merb.
>
> I actually thought that the people asking for the Rails syntax were quite
> nice about it. I do disagree with the reasoning, but I really appreciated
> Ezra's reply explaining the reasons why things are the way they are right
> now.
>
> I'm off to the Rails Conf, I know for a fact that at least Yehuda and Ezra
> should be around if you have any questions regarding Merb. I think Yehuda
> also has a Merb BoF talk scheduled.
>
> Finally, we'll more than likely announce the first Merb Camp planned for
> October 08 (planning on 10-11) in San Diego California. So if you couldn't
> make it to Rails Conf, plan a trip to Southern California!
>
> -Matt
>

Michael Latta

unread,
May 29, 2008, 12:22:24 AM5/29/08
to me...@googlegroups.com
I think a lot of thinking has gone into the Merb API and generally am
quite glad that you did not go for a work-alike. There are things I
can easily do in Merb that were a **** in Rails. There are also
things in Rails that are still not production ready in Merb just
because Merb is so new. But, the biggest thing missing for Merb is
good documentation, and a landmark book like the Agile book was for
rails. In 6 months to a year Merb will have the supporting
documentation and infrastructure to really take off. Until then we
all get to be on the bleeding edge, where the fun is. Having Merb use
a different vocabulary is I think a good thing, as it will help us
keep the Rails thoughts from being mixed up with the Merb thoughts.
Thinking about problems the way Merb works is more important than
having some things be the same while other things are different.
Right now the pain is that too much has to be discovered from the code
for those learning the framework.

Michael

Nate Wiger

unread,
May 29, 2008, 1:21:43 AM5/29/08
to merb
Ezra,

> The thing to keep in mind is that merb is not rails, there are some
> fundamental differences in opinion and that is ok, you just have to
> learn to accept it. Merb will pay huge dividends whenever you have to
> peek under the hood and I cannot stress enough how much of an
> advantage this is

I agree with you fundamentally. At the same time, what is so wrong
about closer compatibility with Rails *where it makes sense*? Can the
Merb team honestly say that trivial changes like the logger.debug and
initializers/ items would so pollute the Merb codebase as to
invalidate the Merb architecture? Sounds like a bit of religious code
fanaticism taken to the extreme.

If Merb is going to be more than modestly successful, it needs to get
interest/porting from people with existing Rails apps, plain and
simple. (Note I'm assuming the Merb team wants it to be successful).
Personally, my team has a very large (>100 table) Rails app here at
PlayStation. Our schedules are beyond insane. A few days of extra
porting time can literally be a go/no-go.

So, I think there's a "cake-and-eat-it-too" issue. Remember, in your
initial talk you said Rails was too opinionated for you. If Merb
becomes the same, then what has it accomplished, really? There's
already Nitro, Ramaze, Camping, and other "also-rans" in the Ruby MVC
framework space. If Merb is going to be successful, it will do so by
being a couple-hour port from Rails with a 20% speed boost. Otherwise
people won't care, or spend the time, or both.

And sorry, porting a little homepage blog just doesn't count. Think
porting Twitter, or Backpack.

Nate Wiger
PlayStation

Michael Klishin

unread,
May 29, 2008, 1:35:15 AM5/29/08
to me...@googlegroups.com
2008/5/29 Nate Wiger <nwi...@gmail.com>:

> So, I think there's a "cake-and-eat-it-too" issue. Remember, in your
> initial talk you said Rails was too opinionated for you. If Merb
> becomes the same, then what has it accomplished, really?

Merb is clean, simple and easy to build your own thing on top of it. It works
nice with DataMapper => you won't have to fight with ActiveRecord when
you work with something that it was not developed for. It does not
consume 60 megs per app
server when all you need is one-feature application. It proven that
Ruby tools can be very fast and
frameworks can be very modular while staying simple. I know it is
nothing from manager's perspective.
We are not all managers, thankfully.

> If Merb is going to be successful, it will do so by
> being a couple-hour port from Rails with a 20% speed boost. Otherwise
> people won't care, or spend the time, or both.

So what? Merb does a great job for some people. Nothing does great job
for everyone.
Including Rails. Sorry that it wasn't developed for Playstation team
needs from the ground up.
You can build Ruby on RailsStation on top of Merb and make it 100%
Ruby on Rails API compatible.
--
MK

Michael Latta

unread,
May 29, 2008, 1:35:34 AM5/29/08
to me...@googlegroups.com
I think there are several issues and assumptions flying there.

If all Merb offered was a speed boost it would be dead already. That
may be your pain point, but I doubt that would justify an entirely new
framework and code base. Better performance is a caret, but to get
better performance requires approaching things differently.

If it looks too much like Rails people are going to "port" their code
using all the old thinking and bad habits, and find they do not get
the performance benefit. For most of the issues raised in this thread
a gem for rails compatibility could easily add aliases and such,
without forcing that compatibility "crap" on newly built Merb apps. I
would rather build Merb apps using Merb as it was intended and have a
lean framework to maintain and support. The more ways there are to do
things the more cost there is in learning, maintaining, and training.

For those with large existing code bases the death of a thousand cuts
could be a real issue, and a compatibility gem makes sense. But, I
doubt the Merb core team cares about that. Some largish project is
going to need to do that gem and share.

Michael

Ben Nevile

unread,
May 29, 2008, 1:49:54 AM5/29/08
to me...@googlegroups.com
Hi Yehuda,
 
I think the root of the issue, however, is in a lack of a prominent
document that clearly maps Rails idioms onto Merb ones (like the
Test::Unit => Rspec document).

Agreed.  Thanks for the extended + friendly explanation.

Ben

Nate Wiger

unread,
May 29, 2008, 3:46:18 AM5/29/08
to merb
Yehuda, thanks for your reply.

> > I think the root of the issue, however, is in a lack of a prominent
> > document that clearly maps Rails idioms onto Merb ones (like the
> > Test::Unit => Rspec document).

The issues are no all about documentation. They're about established
expectations. For example, what should this do?

6 * 5 - 10

What if I told you, in my framework, we did right-binding since it
seemed better. So the above is:

-30

Now, pretend you don't know Merb that well for a second. What should
this do?

class Thread < Controller
before :verify_login, :except => :subscribe
def subscribe(id)
logger.debug "subscribing to thread"
@thread = Thread.find(id)
if @thread.subscribe
render :layout => false
end
end
end

Do you see the bugs?

Let's consider another example, of porting from Rails to Merb. I
decide I don't have time to change "logger.debug" to
"Merb.logger.debug" everywhere. So I do something like this:

class ActiveRecord::Base
def logger
Merb.logger
end
end
class Merb::Controller
def logger
Merb.logger
end
end
class Merb::View # ?
def logger
Merb.logger
end
end


That code is simple... and as such, I immediately share my new "easy
Rails compat" solution:

1) I blog or Wiki about it
2) I guarantee you I'm not the only one who's going to want this...
3) And then a compat gem or numerous digg links will appear

NOW, here's the point: this compat gem will become a *requirement*
for many other Merb plugins, because...

1) People will install the compat gem as one of the first steps when
installing Merb
2) It will become so ingrained that people won't even realize they're
leveraging it.
3) They'll upload a brand new Merb plugin, it will break, and then
they'll be totally confused
4) They'll post to the list, chewing up everyone's time
5) The "solution" will be saying, "merb_rails_logger_compat" is a
required gem for "merb_ajax_pagination".

Like it or not, Rails has ingrained certain idioms. The few that
we're talking about here (logger, initializers) are exceedingly
simplistic - which is all the more reason Merb should just cut-and-
paste the 3 lines of code into core and call it done.

Bottom line, it seems in everyone's interests for the Merb team to be
able to focus on *real* issues, rather than documenting and answering
"No, it's Merb.logger.debug, not logger.debug" questions all day.

Anyways, I'll shut up now.

Nate Wiger
PlayStation

Matthijs Langenberg

unread,
May 29, 2008, 5:14:16 AM5/29/08
to me...@googlegroups.com
Michael Latta, you are exactly describing my thoughts. When I see
Merb.logger, I know I need to look in the Merb module, when I see just
logger, I've no clue about which magic mixin I'm accessing.

Rowan Hick

unread,
May 29, 2008, 7:32:26 AM5/29/08
to me...@googlegroups.com
+1 on this side of the fence. I personally love the fact that Merb does it like this as well. Makes investigating/hacking a whole lot easier :)

I'm doing a 15-20min presentation on June 10th to Toronto Rubyist's on jumping into Merb so I hope to cover off a lot of tidbits gathered from emails/wiki's and personal experience in playing with Merb 'what you need to know', I'll post this up on my blog and so hopefully will help with Rails devs wanting to explore Merb. It's all about setting expectations - if you come in with the mindset Merb != Rails, then life gets a lot easier. 

Cheers
Rowan

Michael D. Ivey

unread,
May 29, 2008, 12:08:17 PM5/29/08
to me...@googlegroups.com
On May 29, 2008, at 6:32 AM, Rowan Hick wrote:

> It's all about setting expectations - if you come in with the
> mindset Merb != Rails, then life gets a lot easier.

I think this is a really good point, and maybe something someone
should blog about.

Michael D. Ivey

unread,
May 29, 2008, 12:33:34 PM5/29/08
to me...@googlegroups.com
On May 29, 2008, at 2:46 AM, Nate Wiger wrote:
> The issues are no all about documentation. They're about established
> expectations. For example, what should this do?

I think the real disconnect here is that I, and I assume others, do
not believe that Rails has established expectations for all
programmers. It's established expectations for *Rails* programmers,
just as Spring has established expectations for Spring programmers and
Maypole has established expectations for Maypole programmers.

We're never going to do something just to be different, but I really
hope we never add a single line of code that can only be justified by
"Because Rails does it that way". "Because Rails does it and it's
awesome" is a great justification, though.

So let's argue these things on the merits of them.

> Like it or not, Rails has ingrained certain idioms. The few that
> we're talking about here (logger, initializers) are exceedingly
> simplistic - which is all the more reason Merb should just cut-and-
> paste the 3 lines of code into core and call it done.

No code is faster than no code. I don't object to initializers
because of some NIH feeling. I object to them because it's
unnecessary code that doesn't belong in merb-core. "Its simple, so we
should do it" is a strategy that will always lead to bloat. Many
things are simple, but that doesn't mean they're good.

As a compromise on initializers, what if we put the 1 line snippet to
add initializers into the default generated init.rb, commented out, so
people can see how to do it if they need it? That would fit with the
Merb philosophy of less behind-the-scenes magic and more explicit Ruby
code, but would also make it easy to turn on for people who feel they
need it. Plus, it's in merb-more and not merb-core.

I think wycats is going to comment more on the philosophy about why we
don't have a logger() method in Kernel, so I'll just say it really is
a philosophical point. It's not arbitrary. We're not just trying to
be jerks.

Ben Nevile

unread,
May 29, 2008, 3:04:01 PM5/29/08
to me...@googlegroups.com
ps. armed with my new poke-through-the-source-code attitude, I was just tickled to discover that in abstract_controller.rb they are referred to as before_filters and after_filters!

Sam Smoot

unread,
May 30, 2008, 2:35:06 AM5/30/08
to merb
On May 28, 12:49 pm, Ezra Zygmuntowicz <ezmob...@gmail.com> wrote:
> def logger
>    Merb.logger
> end

I know I'm very late to the party, but this makes perfect sense to me.
Merb.logger is a Singleton. By not having the helper method in
controllers built-in, that becomes obvious. Which makes the framework
more transparent. I like that.

Also, gotta say, not a fan of render(:nothing). Arbitrary Symbols as
values are no better than magic-numbers. A little less API flux over
time since new symbols can be added transparently, but a lot more API
cruft to remember and complexity to implement. I'm guilty of the
occasional magic-symbol myself, but that doesn't mean it's a good
idea. ;-)

Just my 2c.

James Herdman

unread,
May 30, 2008, 1:44:41 PM5/30/08
to me...@googlegroups.com
Ah!  You beat me to it, Jed :)

I submitted this "enhancement" to Merb-core and it was rejected per Michael's reasoning.  And you know what, 9 times out of 10, he's right.  Chances are if you need the functionality, you'll figure out how to bring it in anyways.  Merb's cool like that.

James H.

On Wed, May 28, 2008 at 11:03 AM, Jed Hurt <jed....@gmail.com> wrote:
On Wed, May 28, 2008 at 8:47 AM, Michael D. Ivey <michae...@gmail.com> wrote:
It would be trivial to add a few lines to support an
initializers/ directory ... 




Reply all
Reply to author
Forward
0 new messages