On May 15, 12:31 pm, Jeremy Evans <[email protected]> wrote:
> On May 15, 9:11 am, Paploo <[email protected]> wrote:
>
> > On May 14, 2009, at 19:55, Jeremy Evans wrote:
>
> First, let me thank you for taking the time to share the reasoning
> behind your choice of Sequel. It gives me a perspective I don't often
> get.
[Jeff R] No problem. You take the time to make and maintain the ORM
that we are using... the least I can do is spend a few moments giving
you the information you want. :)
<snip>
> Other people have requested that an error be raised or
<snip>
[Jeff R] I agree with you on that one. No need to code a framework
*around* the bad habits that Rails devs are in. That is actually part
of our goal with our application; we are getting back to *real* OO
Ruby as much as possible, which is strange and difficult for Rails
developers. This is because Rails is practically a language in
itself. It introduced syntax paradigms that I had never heard of
until Rails hit the scene. Some of these were for the better, and
some of them weren't. Not that I can complain about Rails too much:
thanks to it I get paid to architect and write Ruby code, instead of
doing little for-fun and side projects in it. :)
<snip>
> I'm definitely against the use of interchangeable strings and symbols
> in most cases. About the only time I think it makes sense is for
> things like HTTP param hashes, where the keys in the hash have to be
> strings and not symbols (otherwise you open yourself to a DOS attack)
> but you still want to use symbols in your code to make it cleaner.
[Jeff R] I mostly agree here... indeed, I brought up this point
multiple times when we started planning our new base framework.
I do find myself often converting to string internally, so Symbol
support comes along for the ride. This is, however, a byproduct of
how I solve the problem internally, but it dose have the nice side
effect of not throwing off the Rails guys. :) (It also has some
benefit with duck typing, anything that behaves like a string can be
used, even if it is not a string. Sort of like how most I/O related
methods can take a string or a Pathname instance because they call
#to_s, but a few crash because they don't.) In my own code I don't
attempt to attain String-Symbol Duality(tm), I just let it work when
it works and not when not.
On a related note, Notice how they added a whole String-like API to
Symbol in 1.9? Shows how much Rails has changed how Ruby is used.
<snip>
> Would you be willing to share your test suite? I have a benchmark
> application I'm working on that works with both ActiveRecord and
> Sequel and I'd love to get more tests.
[Jeff R] That task was assigned off to someone else while I worked on
architecting the primary framework. Come to think of it, however, I
seem to recall Tim saying that he sent you a copy at one point and
that you couldn't duplicate the results, which is probably why we
considered the results suspect.
In the end, the decision was really about if the performance
difference was enough to overcome the costs of re-training the dev
staff to work with a new ORM, and we waffled a lot because we could
never get clear results. It wasn't until Chris did an eager loading
test that our minds were settled.
<snip>
> Yeah, the modular way Sequel is put together makes customization
> pretty easy, unlike ActiveRecord which is a bit more monolithic.
[Jeff R] It's architected very well, which has allowed us to get away
with a lot of strange requirements that seem to only show up in
enterprise. It's hard to get a lot of devs to admit it, but
enterprise web app development has very different requirements than
typical "Web 2.0" development. While Rails is a great "Web 2.0" dev
platform, it just isn't cutting it for enterprise use.
> Anyway, I'm glad you choose Sequel. If you have any questions, please
> post them here or join #sequel on IRC and I'll be happy to answer
> them.
[Jeff R] Thanks for the fast replies! I'm sure Chris (a.k.a. the
cowboy coder) and I (a.k.a. paploo) will run into further questions as
we get into the thick of this project. It is nice to have someone
friendly and helpful behind the framework we are using. :)
> Thanks,
> Jeremy
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/sequel-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
