Why use :exclude rather than :except?
Nate Wiger
using :exclude rather than :except for stuff like before filters.
I'm sure there's an argument over which term is better, but it seems
like using the same term as Rails would cut down on potential FAQ's/
confusion going forward. Is :exclude a strongly held belief or
something that might be worth putting back in line with Rails? The
before filters in Merb already use :only
-Nate
Ben Nevile
Michael Klishin
> +1 for this question. Perhaps there's room for a merb_rails_compatibility
> gem that has helper methods to map old words to new words.
>
> Ben
I've spotted such project at github. Looks like way to go in this
particular case.
--
MK
Matthijs Langenberg
exclude/except thing though)
gluis
syntax difference?
it seems arbitrary, especially since it isn't as if merb was created
by someone unfamiliar w/ rails (or unaware of merb's primary initial
audience).
g
On May 21, 2:26 pm, "Matthijs Langenberg" <mlangenb...@gmail.com>
wrote:
> exclude/except thing though)
>
> On Wed, May 21, 2008 at 6:54 PM, Michael Klishin
>
>
> > 2008/5/21 Ben Nevile <ben.nev...@gmail.com>:
j3tch1u
for several reasons:
- foster migration of users to merb
- easier to re-use existing codebase of plugins, snippets, etc.
- applicability of existing docs, tutorials and other support
- easier to find/compare differences in implementation
- less confusion for ppl working with both frameworks simultaneously
- no need to reinvent the wheel when it comes to carefully thought out
names and apis
i for one, wouldn't mind if you guys broke the api for more rails
compatibility in 1.0. i think this is an internal philosophy issue
which can't be addressed with a compatibility gem. it would be like
trying to hit two moving targets at the same time. i think the main
reason ppl won't switch over is due to rails maturity and larger code/
support base.
compatibility on top of performance would definitely be a big carrot.
i would go so far as to say the two communities should work together
when planning new features/releases.
On May 22, 12:54 am, "Michael Klishin" <michael.s.klis...@gmail.com>
Ngoc Dao
I have just ported this little CMS from Rails
(http://openkh.rubyforge.org/svn/trunk/) to Merb
(http://openkh.rubyforge.org/svn/branches/merb-activerecord/). It was
very painful and time-consuming. I have to rewrite everything because
of the incompatability between:
* Merb::Controller and ActionController::Base (a little painful)
* merb_helpers and ActionView (<- very painful!)
Ahsan Ali
While some of the advantages you enumerated are tempting, it would just add another layer that would need maintenance. Also, isn't the merb team trying to not compete with rails ?
Perhaps people will have more options when the team has ported back some of the good things about merb to rails.
Ngoc Dao
for the Merb team only, it does affect plugins developers and users.
Isn't it a waste of time to rewrite *too many* existing plugins?
Michael Klishin
> +1 for me too. i think rails compatibility should be a top priority
> for several reasons:
I think you are paying too much attention to one option naming.
First off, I am all for changing it to whatever it should be for "compatibility"
but I cannot agree on the tone. It seems like Merb should do everything to be
like Rails? Then why develop Merb, use Rails.
> - foster migration of users to merb
Merb needs no world domination. If people use Rails instead, they make
their choice.
> - easier to re-use existing codebase of plugins, snippets, etc.
Controller plugins are incompatible anyway. Reuse with copy-paste
can be complemented by find-and-replace.
> - applicability of existing docs, tutorials and other support
Other difference make them pretty irrelevant anyway.
> - easier to find/compare differences in implementation
People who do hack on internals won't have problems finding
differences in it, trust me. Others do not care.
> - less confusion for ppl working with both frameworks simultaneously
I do. I have no confusion and you won't after you find the difference for the
first time.
> - no need to reinvent the wheel when it comes to carefully thought out
> names and apis
It is not reinventing the wheel, it is just one option naming.
Come on, it is one option, not core concept, not
completely different conventions, one option of method
not every controller uses.
> i for one, wouldn't mind if you guys broke the api for more rails
> compatibility in 1.0. i think this is an internal philosophy issue
> which can't be addressed with a compatibility gem. it would be like
> trying to hit two moving targets at the same time. i think the main
> reason ppl won't switch over is due to rails maturity and larger code/
> support base.
Until they find ActiveRecord doing
crazy number of queries while walking down tree structures.
> compatibility on top of performance would definitely be a big carrot.
> i would go so far as to say the two communities should work together
> when planning new features/releases.
Again, they have different sense of value. No power in this Universe
convince Michael Koziarski
that alias method chain is insane and 5 CGI wrappers in dispatch process, too.
--
MK
Michael Klishin
>
> Remember Merb is the architecure for plugins, so this problem is not
> for the Merb team only, it does affect plugins developers and users.
> Isn't it a waste of time to rewrite *too many* existing plugins?
You cannot use Rails controller plugins out of the box in 99% of
cases. So it does not matter
what's the option name.
I am +10/-10, I don't mind updating one option in my own applications,
I don't mind not doing it :)
--
MK
Michael Klishin
> I have just ported this little CMS from Rails
> (http://openkh.rubyforge.org/svn/trunk/) to Merb
> (http://openkh.rubyforge.org/svn/branches/merb-activerecord/). It was
> very painful and time-consuming. I have to rewrite everything because
> of the incompatability between:
> * Merb::Controller and ActionController::Base (a little painful)
> * merb_helpers and ActionView (<- very painful!)
Would you say Django should use Rails helpers and stuff?
If you would rewrite it using Django, it is so much more pain.
--
MK
j3tch1u
pretty important to many ppl.
> I think you are paying too much attention to one option naming.
> First off, I am all for changing it to whatever it should be for "compatibility"
> but I cannot agree on the tone. It seems like Merb should do everything to be
> like Rails? Then why develop Merb, use Rails.
other instances. don't get wrong, i'm on your side. i'm not saying
let's clone rails--absolutely not. there are just some small cosmetic
details that could make it that much easier to migrate to merb--and
i'm all for seeing that happen. if migration wasn't an issue, this
point would be moot. for instance, if a merb method takes the same
arguments and returns the same expected result why change the name if
it wouldn't break existing code otherwise? of course methods that are
fundamentally different should break the code by design. for methods
that are almost the same but break, well it would be just that much
easier to search for that identical method on rails doc. you can't
say there aren't similarities between the two--i'd like to think of
merb as the best of breed. so why not factor out the minor differences
and highlight the rest?
> Merb needs no world domination. If people use Rails instead, they make
> their choice.
new adopters. obviously merb is superior to rails in many ways.
however, user base is still important for the obvious reasons.
> Controller plugins are incompatible anyway. Reuse with copy-paste
> can be complemented by find-and-replace.
same. there are many other snippets, plugins, etc. that aren't tied to
actioncontroller ideosyncracies and could work out of the box with
minimal changes. obviously all controller plugins are incompatible now
because before_filter is called before. just alias or change it right?
as for as rails wikis, forum posts, tips, blogs, etc. they don't need
to be compatible to still be applicable.
> People who do hack on internals won't have problems finding
> differences in it, trust me. Others do not care.
aren't so great at hacking on internals.
> I do. I have no confusion and you won't after you find the difference for the
> first time.
would figure things out eventually right?
> It is not reinventing the wheel, it is just one option naming.
> Come on, it is one option, not core concept, not
> completely different conventions, one option of method
> not every controller uses.
> Until they find ActiveRecord doing
> crazy number of queries while walking down tree structures.
redundant layers. it's more about a small subset of the public api
methods, options, etc. it's an important discussion to have before 1.0
is set in stone.
> Again, they have different sense of value. No power in this Universe
> convince Michael Koziarski
> that alias method chain is insane and 5 CGI wrappers in dispatch process, too.
j3tch1u
> -1 for me.
>
> While some of the advantages you enumerated are tempting, it would just add
> another layer that would need maintenance. Also, isn't the merb team trying
> Perhaps people will have more options when the team has ported back some of
> the good things about merb to rails.
i think compete is a word that can be used in a broad sense. in a way
merb is competing (it doesn't need to be intentional or conscious).
resources are finite meaning mindshare can sometimes be a zero sum
game esp when it comes to frameworks. if an individual developer ports
his project to framework x, chances are he's gonna build future
projects with framework x and tell his friends to use x instead of y.
some community is going to lose the support of that user. support can
be word of mouth, tickets, plugins, tutorials, blogs, etc. there is a
monetary impact in the end as well.
Michael Klishin
> if an individual developer ports
> his project to framework x, chances are he's gonna build future
> projects with framework x and tell his friends to use x instead of y.
If framework X is worth using it, (s)he will tell friends anyway or at
least continue using it.
This is the goal to chase.
I think you can stop convincing people that "maximum Rails
compatibility" is so extremely important. If it is, why waste time? Go
and create
local branch, make changes you want to see and submit patches. It is
much easier to make decision when most of work is already done.
You can get that method use both :except and :exclude to satisfy
people who prefer the way it works now.
Even if you won't have your patches applied, you will learn a lot
about framework you use.
--
MK
j3tch1u
> > his project to framework x, chances are he's gonna build future
> > projects with framework x and tell his friends to use x instead of y.
>
> If framework X is worth using it, (s)he will tell friends anyway or at
> least continue using it.
> This is the goal to chase.
developer is coming from and his pain/pleasure learning the framework.
if i'm coming from django, i won't have any issues because i'm not
expecting to reuse much of my codebase. expectations for ppl coming
from rails are different i'd say.
> I think you can stop convincing people that "maximum Rails
> compatibility" is so extremely important. If it is, why waste time? Go
> and create
> local branch, make changes you want to see and submit patches. It is
> much easier to make decision when most of work is already done.
> You can get that method use both :except and :exclude to satisfy
> people who prefer the way it works now.
>
> Even if you won't have your patches applied, you will learn a lot
> about framework you use.
> --
> MK
week, ported my app and thought i'd contribute to this discussion
about syntax. really, it is only about syntax and not about turning
merb into a rails frankenmonster. i've submitted a few patches to merb-
core and i see you've opened the tickets. still learning the ins-and-
outs but i'm getting there. just thought i'd share some opinions along
the way. i've also put in some time revamping merb-cache and fixing
some things in core test (i'll submit those after they've been tested
thoroughly). merb paginate is an example of functionality that relies
on a tried and tested rails plugin (will paginate)..so there is some
symbiotic dependency (for some, more than others). in this example,
neither rails nor merb take params for action/page caching. i know
what you're thinking..no basic caching for pagination?? this is
something i'm taking the time to do out of respect for the team and
other dutiful contributors like yourself. i think in the interests of
fostering a productive talk no opinion should be written off so
quickly. looking ahead, a lot of design options are not binary all or
nothing.
tks,
-ben chiu
Ben Nevile
I think you can stop convincing people that "maximum Rails
compatibility" is so extremely important.
Michael Klishin
> how often do you want to
> this issue to come up? If nothing changes it's guaranteed that this issue
> will surface again, and again, and again, each time a new rails user tries
> merb.
I am all for it, I did say it, didn't I? I just don't
agree on the tone. Rails compatibility is not top priority. Noisy
mailing list messages
will pop up anyway. If you need Rails compatibility today, go
do it, it is as easy as a few lines patch in this particular case.
One thing makes me wonder. We have problems with inflector. We have some
code duplications with DataMapper core. Merbful authentication is so
ActiveRecord
oriented I could not port Merbums to DM0.9 today without rewriting it.
There are
specs missing in -more/-plugins. Merb-more rakefiles are not not well organized.
And there are lots of other things to care about much more.
Still people care about naming of options "like in Rails"
and "code reuse" (with copying and pasting obviously, Merb controllers
are different
so much you cannot use 95% of Rails controller plugins out of the box).
Think about it next time you want to mention "faster adoption" or
something like this.
--
MK
Matt Aimonetti
Rails compatibility is not top priority however we are not changing
method signatures just to be different than Rails. I personally didn't
write this method and I'm not sure why we would prefer :exclude
instead of :except. However we are trying to get things done to
release 0.9.4 real soon and 1.0 in the next few weeks.
I hope that answers your question Nate.
-Matt
On May 25, 6:51 pm, "Michael Klishin" <michael.s.klis...@gmail.com>
wrote:
> 2008/5/26 Ben Nevile <ben.nev...@gmail.com>:
j3tch1u
tone i was meaning to convey. after coming across several method
signatures that look like they were changed just to be different (and
would have worked fine otherwise), i thought it might be a good idea
to nip the bud before 1.0 api is set in stone and future additions
introduce even more syntax ideosyncracies.
as it stands, googling for specific bugs or hidden how-to's doesn't
come up with much. this is where the power of numbers (users) come
into play. point is, the faster we get ppl to port their apps the
better. hopefully in the future i can spend less time diving into the
framework and devote more time to my app. i do appreciate the fact
that merb contains less magic.
if the team says they're looking out for it, a simple "thanks, we've
got your back" would be good enough for me. if the team is open to it,
i'm sure some of us would be willing to help. however if they're not,
then there is no point spending the time sifting through the api
haystack for these needles. thanks once again for taking the time.
Ahsan Ali
Personally, I like the loose coupling approach of merb and django, so I am not averse to using even django if I have to, or an X/Y/Z framework if that is the right tool for the right job.
And as far as the trouble with rewriting plugins goes, plugins revolve _around_ a framework, not vice-versa. I would be surprised if a plugin could be run with just 'any ruby web framework' (that's an idea, though :D).
Ahsan Ali
What do you think ?
Julian Leviston
Web Frameworks really need something that will generate flash-like
functionality easily.
I say flash-like because Flash really sucks, and so does the whole
host of flash-like things that have sprung up around it.
The reason is mostly that:
1. They're big to code, and big to download.
2. They don't allow their source to be seen inside of.
3. They're proprietary.
4. They are difficult to code in.
5. They often require downloading things to work.
We need something that will make us happy on the view side.
Julian.
Michael D. Ivey
1: will someone please start a page on the wiki for 'common gotchas
for rails devs' or something equivalent.
2: please keep in mind that merb and rails have different target
'markets'; it is kinda assumed that if you're using merb, you're going
to read the docs and the source.
3: I think a case could be made that 'except' is the more correct
choice. If someone wants to make that case, a patch would be welcome.
I don't think 'because it will make it easier for rails folks' has
positive or negative weight for 'correctness' ... let's just use the
best names and APIs and not focus so much on Rails at all.
Sent from my iPhone
On May 25, 2008, at 8:51 PM, "Michael Klishin" <michael....@gmail.com
Michael D. Ivey
differently from Rails just to be contrary.
Sent from my iPhone
Ezra Zygmuntowicz
If people are really annoyed by the except, exclude thing I have no
problems adding support for except and wither leaving or removing
exclude. But I am not going to go down the rabbit hole of going
through the whole api and trying to make it more rails like. That is
not going to fly as merb is not rails.
So for now let's add support for :except while still
supporting :Exclude as I do not want to break everyones apps right now.
If anyone has any other parts of the API they want to speak up about
do it now or forever hold your piece ;)
Cheers-
-Ezra
- Ezra Zygmuntowicz
-- Founder & Software Architect
-- ez...@engineyard.com
-- EngineYard.com
Nate Wiger
Regarding Rails compatibility, I think Ben Nevile hit it right on the
head:
as an important merb person you will probably frequent this mailing
list and
this issue to come up?
finishing 1.0 for RailsConf, and that there are many other higher
priorities.
So...... how do I supply a patch? Are these instructions still valid?
http://merbivore.com/contribute.html
Nate Wiger
PlayStation
Nate Wiger
Please ignore my post above. I agree with your position.
Give me a second to compose my thoughts and I'll post again in this
thread.
Nate Wiger
PlayStation