ActiveSupport for Rails 3

[botanicus]

Hey guys,

I'm wondering about future of AS and Extlib. I heard that these two
should be merged (so extlib will actually die), which makes sense
since these two are sort of similar so we can have just one main
library with Ruby stdlib extensions.

However would this library be suitable for smaller frameworks like
Ramaze or Rango? In current Rails 3 activesupport/lib has 2.8 MB and
52 415 lines (via wc -l) which is more than 20x times bigger than the
whole Rango, so it's not an option for me (as I'm the author of
Rango).

I was talking to Pavel Kunc who currently maintain Merb and it seems
he would like also something significantly smaller.

So what we are suggesting is to keep extlib for these really basic
things like cattr_*, String#to_snakecase etc and everything else put
into activesupport which will be builded on top of extlib.

So everyone should be happy:
1) There would be just one extensions library (well, one small and
one big, but the point is it's still DRY)
2) Rails will have AS, so Rails will be happy and smaller frameworks
will have extlib, so they could be happy as well.

In case you guys won't like this idea, there would be need for smaller
extension library, so someone (probably me) will write it and code
duplication, welcome back.

So what do you think?

Cheers,

Jakub

[Yehuda Katz]

Heya,

We spent a bunch of time making ActiveSupport more cherry-pickable. If there are still clumps that aren't fine-grained enough for your needs (I did some work to make the inflector a bit more fine-grained), please let me know (I'd consider it a bug).

Are you otherwise concerned about the disk space occupied by ActiveSupport? Please explain a bit more exactly what your requirements are that prevent the use of ActiveSupport in Rails 3.

Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325

--

You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonra...@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-co...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.

[Jeremy Kemper]

Active Support's baseline resource consumption is nearly zero. It now
boots faster, creates fewer objects, and allocates less memory than
extlib.

Why is wc -l your measure?

Best,
jeremy

[botanicus]

Hi Yehuda, I'm not sure if you get me right, AS is fine for Rails 3,
but we are more interested in something more suitable for smaller
frameworks, so we would very welcome to have extlib with basic things
and as with the rest.

> > rubyonrails-co...@googlegroups.com<rubyonrails-core%2Bunsubscrib e...@googlegroups.com>
> > .

[botanicus]

Because I don't want to spent ages when I'm reading source code just
scrolling down in dir browser buffer and I don't care about 95% stuff
included in AS. Because I want less things in my git repository,
faster deploys etc etc. AS is just not what I'm going to use when I
actually need just a few tiny methods to standard Ruby, that's it.

Cheers,

Jakub

On Dec 14, 10:06 pm, Jeremy Kemper <jer...@bitsweat.net> wrote:

[Ryan Bigg]

So far, from my understanding, what you've said is that you want to use
some parts of ActiveSupport, but you don't want to use the entire
ActiveSupport "collection". It would be helpful to us if you could name
the parts that you are wanting to use and we'll set you on the right path.

What you need from ActiveSupport will of course be different from what
other people need from ActiveSupport. I don't think it is up to Rails
Core to go through and rip out what you deem as important components;
It's already neatly sectioned off.

If you want only parts of ActiveSupport you're going to have require
them yourself, and a bit more. Take for example if you wanted to require
the extensions to the Array class you need to also require the object
extensions too, since some methods require the method "returning" from it.

require 'active_support/core_ext/object'
require 'active_support/core_ext/array'

This will let you use methods such as in_groups_of and so on, without
including the other stuff.

You'll need to include other things as well sometimes, such as I18n to
get to_sentence to co-operate.

[Yehuda Katz]

Just to be clear, if there are cases where useful functionality of ActiveSupport is hidden behind dependencies that aren't obviously necessary, I personally would consider that a bug, and improve the collection to make it easier to pick the parts that are needed.

However, I haven't seen any specific requests, or reports of dependency problems, so I don't know what to fix. All I know is that we've spent considerable time making ActiveSupport suitable for smaller projects that don't want to pull the entire thing in (with the base requirement consuming virtually no resources).

I'd like to hear specific, concrete problems. I assure you I will take them seriously.

Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325

--

You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonra...@googlegroups.com.

To unsubscribe from this group, send email to rubyonrails-co...@googlegroups.com.

[Ryan Bigg]

I understand.

From what I could see, there wasn't an "easy" way to require I18n, such as in my example of requiring the array extensions. Not too sure if this is important, but having a require 'activesupport/i18n' would be handy.

[Yehuda Katz]

Can you file a ticket. Let's get this fixed!

Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325

[Nicolás Sanguinetti]

On Tue, Dec 15, 2009 at 11:54 PM, Ryan Bigg <radarl...@gmail.com> wrote:
> So far, from my understanding, what you've said is that you want to use
> some parts of ActiveSupport, but you don't want to use the entire
> ActiveSupport "collection". It would be helpful to us if you could name
> the parts that you are wanting to use and we'll set you on the right path.
>
> What you need from ActiveSupport will of course be different from what
> other people need from ActiveSupport. I don't think it is up to Rails
> Core to go through and rip out what you deem as important components;
> It's already neatly sectioned off.
>
> If you want only parts of ActiveSupport you're going to have require
> them yourself, and a bit more. Take for example if you wanted to require
> the extensions to the Array class you need to also require the object
> extensions too, since some methods require the method "returning" from it.
>
> require 'active_support/core_ext/object'
> require 'active_support/core_ext/array'

Is there a specific reason why each pice won't require its
dependencies? I mean, if core_ext/array needs core_ext/object for
Object#returning, why doesn't it require at the top of the file?

That would certainly make it easier on whoever wants to just use
in_groups_of, since he doesn't have to go through the NoMethodErrors
(or with any luck, undefined constants, which means it breaks on
"compile" time)

> This will let you use methods such as in_groups_of and so on, without
> including the other stuff.
>
> You'll need to include other things as well sometimes, such as I18n to
> get to_sentence to co-operate.
>

[Yehuda Katz]

That's PRECISELY what we've been doing. If there are cases of dependencies that are not appropriately required, please file a bug so we can get it fixed.

Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325

2009/12/15 Nicolás Sanguinetti <god...@gmail.com>

[Mateo Murphy]

On 14-Dec-09, at 4:26 PM, Yehuda Katz wrote:

> Are you otherwise concerned about the disk space occupied by
> ActiveSupport? Please explain a bit more exactly what your
> requirements are that prevent the use of ActiveSupport in Rails 3.

Jakub's concern does indeed seem to be disk space. Maybe a solution
would be to develop a way to to easily redistribute parts of AS, for
those developing other frameworks that only require small bits of it.

[Yehuda Katz]

I'd like to understand what scenario is implicating disk space here.

Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325

[Nicolás Sanguinetti]

On Wed, Dec 16, 2009 at 12:19 AM, Yehuda Katz <wyc...@gmail.com> wrote:
> That's PRECISELY what we've been doing. If there are cases of dependencies
> that are not appropriately required, please file a bug so we can get it
> fixed.

Ah, sorry, I thought that, but Ryan's message confused me :)

[Ryan Bigg]

I'll file some tickets later on tonight, good to know Rails Core is
committed to something this simple and useful!

[botanicus]

First of all thanks all you guys for useful discussions.

Yehuda wants some concrete things I don't like on AS, so:

1) There is no reason why AS should have an executables. bin/
generate_tables is just messing my $PATH. It matter especially in
bundled environment where I want to have my bin/ clean.
2) I don't like that there is a lot of stuff which should be in
separate gems. For example multibyte, cache, backtrace cleaner ...
basically in my opinion in AS should be just core_exts and maybe some
other generic things like callbacks. I believe this is not very good
design.
3) Why is locale/en.yml in lib and therefore is de facto loadable (via
load 'active_support/locale/en.yml')?

1) & 3) isn't so important, the most important for me is definitely
2). In Merb, there was huge amount of gems, Rails 2 are too
monolithic, it would be nice to come with some reasonable design
finally :) I would really put some less generic stuff into separate
gems.

[Ryan Bigg]

As requested I have filed a ticket:
https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/3589-array-extension-standalone.
Looking for further cases where this is broken too.

[Xavier Noria]

I'll do a sistematic pass over all core extensions checking these dependencies.

[Xavier Noria]

On Thu, Dec 17, 2009 at 7:43 PM, Xavier Noria <f...@hashref.com> wrote:

> I'll do a sistematic pass over all core extensions checking these dependencies.

Done! I've found about 30 missing requires:

http://github.com/fxn/rails

There's no way to ensure nothing has been left but it is a pass at least.

[Jeremy Kemper]

Awesome - thanks Xavier!

jeremy