search

rubymotion-community / BubbleWrap

Cocoa wrappers and helpers for RubyMotion (Ruby for iOS and OS X) - Making Cocoa APIs more Ruby like, one API at a time. Fork away and send your pull requests
Other
1.18k stars 208 forks source link

BubbleWrap's Future? #200

Closed clayallsopp closed 11 years ago

clayallsopp commented 11 years ago

So BubbleWrap was discussed pretty heavily at #inspect and, while everyone loves it and gives it two :+1:s way up, there were some concerns brought up that I'll try to tl;dr and get some feedback on.

Again, this is not to give a definitive plan or anything remotely similar, but just wanted to spark some dialog on BubbleWrap. And if you have more thoughts, obviously use this issue as a catch-all.

Done?

Is BubbleWrap "done"? Should it be done yet? What is missing? Contributions have remained slow over the past few months, why/are we doing something wrong?

I think this is more easily determined if we think about this next point, the vision of BubbleWrap:

Vision

What is BubbleWrap's purpose? Is it to port missing bits of MRI Ruby development (like ActiveSupport stuff) to RubyMotion? Is it to abstract Cocoa libraries to remove Ruby anti-patterns like delegates and multiple inline lambdas, on a framework-by-framework basis? Is it to create new abstractions that have no singular basis in Cocoa? All of the above? Or should it pick one and do it really well?

Maybe BubbleWrap could be divided into three logical chunks:

Basically, where are we going? What more can or should be done with BubbleWrap?

Remove some stuff

Candidates for future removal were brought up a few times:

There's a lot of work already being done in Objective-C CocoaPods to write better abstractions for Apple's Cocoa libraries, can we leverage those? Most obvious example is HTTP requests, for which AFNetworking is basically the de-facto solution over yet-another abstraction of NSURLRequest and NSURLConnection.

It seems like an anti-practice to try and double wrapping/abstractions efforts in RubyMotion when perhaps a better solution is to pull in these third-party libs as dependencies with only small Ruby-fication in BubbleWrap.

Of course the downside is additional dependencies and that associated pain, but there's no precedent in BW yet for how to handle wrapping non-Apple code.

Contribution Guidelines

There's confusion as to what kind of stuff should go in BubbleWrap. It would be nice to have some definitive metrics as to what is fit for BW and what should go in an external gem.

Is it lines of code, number of files, etc? How can we make the process of deciding to submit a PR or just create a new gem more frictionless for the community?

Name Change?

BubbleWrap is definitely referred to as the "ActiveSupport of RubyMotion"...so why isn't it just called that? @tkadauke has dibs on the name, and there are obviously lots of logistical problems with a name change, but hey it's worth having some discussion on a possible name change/migration. cc @qrush

supermarin commented 11 years ago

Exactly what I've took out from the slides :) Let's see where it goes

rbeene commented 11 years ago

As someone who has played with Rubymotion and has a nearly non-existent experience with Objective-C, I'd like to see more small convenience wrappers for specific classes. If the idea is that Rubymotion allows for an easier method to create iOS apps via ruby, it seems to follow that the syntax etc. should feel ruby-like.

As I'm just getting my hands dirty though, this opinion is subject to change.

colinta commented 11 years ago

I was hoping, before the conference, that the three of us - and whoever else is interested! :smiley: - would have time to pow-wow about minimizing the overlap with SugarCube and BubbleWrap, but the time just wasn't there. Oh well! Actually I don't think there is a lot of overlap right now. Maybe just gestures and accessing the notification center. And while I prefer SC's gesture methods (they accept lots of options), I find myself transitioning to BW for notifications.

I've always thought that BW works great as a collection of simple framework wrappers, whereas sugarcube is all about opening up existing classes. If sugarcube was broken up into smaller parts (very much like BW is already), I think it would be much less of the sprawling behemoth it is today.

I bet Thomas would be okay offering up the name, and if that happened what do you thinkg about merging the two projects? I think there would be too much confusion if we merged the projects and didn't change the names. Though, I also wonder if there would be much benefit to having just one name... having the two gives them a good distinction, and since they do (or could anyway) have different domains, that distinction has value.

For instance, in Clay's talk he used the example of implementing the << double chevron on NSOperationQueue, and to me that is very much a SugarCube addition. But the EventMachine code, on the other hand, is much better suited for BW.

tkadauke commented 11 years ago

Yes! Just take it! :D

Seriously though, maybe we should also merge in the code that Steve Ross and I put into the motion-support gem.

jimsynz commented 11 years ago

I think the main problem was that since @mattetti left there hasn't been a vision of what we want BubbleWrap to be.

I imagined it as infrastructure that other RubyMotion gems would be built upon. I'm completely happy for the BW.require stuff to be removed if RubyMotion is able to provide this functionality now (I haven't written any RM code in months).

I wanted to see a bunch of bw- gems out there wrapping APIs and doing it with a cohesive API and testing style. That hasn't happened, so I'm not entirely sure what use BW is actually bringing developers in the field? Perhaps we can strip it into different gems and let them go free?

jimsynz commented 11 years ago

I forgot to mention that I wanted to work on implementing the missing parts of Ruby's core and standard libraries with BubbleWrap so that those familiar APIs are present, but I don't know when I would ever get time to start on that :)

qrush commented 11 years ago

For some back history to read, if you haven't: #76. I'm not sure if things have changed or not since that issue. I still feel that splitting up the BubbleWrap gem would be a net win in the long term, and even more so now that it's much easier to include gems into the build system.

About the name change, I don't feel "BubbleWrap" as a name conveys any meaning. My vote is to extract just the "core" part of BubbleWrap into motion-support and make everything else another motion- gem. This might be controversial, but I want to see more momentum around the motion- namespace happen.

Another reason I want to see this change: I think the "Wrap" part has a negative connotation. We're making these APIs, libraries, etc better, not by applying a coat of paint of them, but by actually extending their functionality and making us more productive in RubyMotion.

clayallsopp commented 11 years ago

This idea is looking more attractive than it did when I read it awhile ago: https://github.com/rubymotion/BubbleWrap/issues/76#issuecomment-6646223

Basically, what about:

  1. gem install bubble-wrap should install all abstractions/support/extensions given the :+1:
  2. require "bubble-wrap" should only add all the very global stuff (I think this is just App and Device currently?) to your app. (currently, this also requires bubble-wrap/http for legacy reasons; so at some point, this should throw a deprecation warning before being removed in 2.0+)
  3. require "bubble-wrap/x" starts adding different libraries and code piece-meal; these probably simply require the other relevant gems. current wrappers get moved into other libs in the @rubymotion community.

Benefits are

@qrush if we change it to motion-support, how should the namespacing work? (i.e. does BW::Location become MotionSupport::Location?). Do new libraries added after the name change get wrapped in that name space or does it not strictly matter?

Another reason for the name is the whole BW:: vs. BubbleWrap:: thing is probably more confusing for newcomers than it has to be.

(sorry if you got an email about this earlier, finger slipped on the trackpad)

qrush commented 11 years ago

I'd say namespacing should be under Motion::Support. Motion is defined already in RubyMotion's build system and I don't see why we shouldn't stick it under there. (motion-layout and motion-settings-bundle already follow this)

https://github.com/HipByte/RubyMotion/blob/master/lib/motion/version.rb#L24-L26

colinta commented 11 years ago

I've been trying to warm up to the idea of using the motion- prefix in more gems, but I'm not enthusiastic about having a landscape of apps with somewhat repetitive names. I enjoy creative names. What if rails was called "active-web"?

On the other hand, using the "active" prefix within the rails project makes lots of sense, and RubyMotion is a specialized software tool, for sure...

So i guess I'm asking: what is the benefit to encouraging the "Motion::" namespace?

colinta

mattetti commented 11 years ago

While I'm not actively involved or supporting this project and I haven't used rubymotion for a very long time so take my comments with a grain of salt.

Renaming a successful project is a bad idea. You have blog posts, documentation and history behind the name, don't lose all of that because you think that the term wrapper has a negative connotation. Many popular ruby gems have no meaning or are hard to remember (nokogiri, rspec, hpricot...)

Identify the real problem you want to address: for me that would be to get more contributors. James, Marin and I aren't active anymore and we don't seen to really use RM in a very active manner. The project should live on. I would suggest to find a way to grow a sub community around what we have now. Let people experiment and take the project where they think it makes sense.

At the end of the day, as James said, what this project needs is a vision, not a new name or a better namespacing, these are orthogonal issues.

I wish you all the best,

Sincerely

-Matt On Mar 31, 2013 8:01 PM, "Nick Quaranto" notifications@github.com wrote:

I'd say namespacing should be under Motion::Support. Motion is defined already in RubyMotion's build system and I don't see why we shouldn't stick it under there. (motion-layout and motion-settings-bundle already follow this)

https://github.com/HipByte/RubyMotion/blob/master/lib/motion/version.rb#L24-L26

— Reply to this email directly or view it on GitHubhttps://github.com/rubymotion/BubbleWrap/issues/200#issuecomment-15702625 .

mattetti commented 11 years ago

One more thing... I think that blurring the separation by what is provided by RubyMotion and what is added is confusing. Well defined namespaces avoid issues like that. If everything Motion::* good luck figuring where things come from. The same thing obviously applies to BubbleWrap, extensions should be named as such so its easy for users to identify what "package" is being used and if it's an original package or an extension provided by someone else.

On Sun, Mar 31, 2013 at 9:13 PM, Matt Aimonetti mattaimonetti@gmail.comwrote:

While I'm not actively involved or supporting this project and I haven't used rubymotion for a very long time so take my comments with a grain of salt.

Renaming a successful project is a bad idea. You have blog posts, documentation and history behind the name, don't lose all of that because you think that the term wrapper has a negative connotation. Many popular ruby gems have no meaning or are hard to remember (nokogiri, rspec, hpricot...)

Identify the real problem you want to address: for me that would be to get more contributors. James, Marin and I aren't active anymore and we don't seen to really use RM in a very active manner. The project should live on. I would suggest to find a way to grow a sub community around what we have now. Let people experiment and take the project where they think it makes sense.

At the end of the day, as James said, what this project needs is a vision, not a new name or a better namespacing, these are orthogonal issues.

I wish you all the best,

Sincerely

-Matt On Mar 31, 2013 8:01 PM, "Nick Quaranto" notifications@github.com wrote:

I'd say namespacing should be under Motion::Support. Motion is defined already in RubyMotion's build system and I don't see why we shouldn't stick it under there. (motion-layout and motion-settings-bundle already follow this)

https://github.com/HipByte/RubyMotion/blob/master/lib/motion/version.rb#L24-L26

— Reply to this email directly or view it on GitHubhttps://github.com/rubymotion/BubbleWrap/issues/200#issuecomment-15702625 .

qrush commented 11 years ago

I don't see either of these as issues. I'd also like to hear more from people using BubbleWrap actively in apps on this discussion as well.

Having done a much bigger rename myself (Gemcutter => RubyGems.org), I'm convinced that people will follow code that's good, especially in the Ruby community. It's not hard to update your Gemfile, and being pre-1.0 helps here.

As for the Motion namespace, and "good luck figuring where things come from" ...Is this even a problem with bigger projects like Rails? This sounds like a non-issue. We're not dipping into RubyMotion internals to hack around here. If you're looking at Motion::Support then we can assume there's a gem called motion-support. Motion::Layout, motion-layout. And so on.

I will agree with vision concerns though. It seems what's lacking is a clear owner of the gem/team leader. I lack the bandwidth, or I'd offer. :)

qrush commented 11 years ago

Apparently I'm jetlagged still and thought BubbleWrap was pre-1.0. :flushed:

mattetti commented 11 years ago

I have yet to hear a good argument for the renaming itself behind I don't like the name.

...Is this even a problem with bigger projects like Rails?

Yes, lots of people have no idea what's part of AR, AS, Railties or even Ruby itself and can't find the source code :p Gems don't share core classes, resque doesn't have a ActiveController::Async class.

Gemcutter => RubyGems.org

Is a different use case, it wasn't really a lib being used but a service, documention wasn't as much of an issue and the project renaming choice was to make your project the official version. Gemcutter was confusing to a large amount & the transition made a lot of sense. Google for "bubblewrap http" and you get 10 pages of results...

If you're looking at Motion::Support then we can assume...

You know they say about people who assume ;) Why making new weird conventions when many already exist and are familiar to most developers out there. This discussion really makes me wish Ruby had pushed for more of a real support package...

I will agree with vision concerns though. It seems what's lacking is a clear owner of the gem/team leader.

I think that's the clear issue, let's get someone who wants to tackle the big problems, own the project and once critical issues are resolved, let her/him decide about the naming or other superficial issues. If you don't do that, the core issues will never be solved and we will back to the same misleading conversations in a few months.

On Sun, Mar 31, 2013 at 9:41 PM, Nick Quaranto notifications@github.comwrote:

I don't see either of these as issues. I'd also like to hear more from people using BubbleWrap actively in apps on this discussion as well.

Having done a much bigger rename myself (Gemcutter => RubyGems.org), I'm convinced that people will follow code that's good, especially in the Ruby community. It's not hard to update your Gemfile, and being pre-1.0 helps here.

As for the Motion namespace, and "good luck figuring where things come from" ...Is this even a problem with bigger projects like Rails? This sounds like a non-issue. We're not dipping into RubyMotion internals to hack around here. If you're looking at Motion::Support then we can assume there's a gem called motion-support. Motion::Layout, motion-layout. And so on.

I will agree with vision concerns though. It seems what's lacking is a clear owner of the gem/team leader. I lack the bandwidth, or I'd offer. :)

— Reply to this email directly or view it on GitHubhttps://github.com/rubymotion/BubbleWrap/issues/200#issuecomment-15704120 .

clayallsopp commented 11 years ago

I feel like BubbleWrap should be the one-stop solution for three things:

Anyone have beef with any part of that? Should BW do more, less, or something different than that? (independent of the mechanics of how that code is organized or pulled in)

There's also a consideration to make that if/when RubyMotion is on other platforms, BubbleWrap should continue to be the place folks can trust for platform-independent abstractions.

jimsynz commented 11 years ago

Timely...

The domain bubblewrap.io is going to automatically renew in about 1 month. The cost for this renewal will be $70.00.
mattetti commented 11 years ago

Clay: I think that's exactly what I had in mind when I started this project.

On Mon, Apr 1, 2013 at 11:53 AM, Clay Allsopp notifications@github.comwrote:

I feel like BubbleWrap should be the one-stop solution for three things:

  • Concise abstractions for common patterns (BW::HTTP, BW::Alert in #201https://github.com/rubymotion/BubbleWrap/issues/201 )
  • Smaller extensions to Cocoa classes (NSNotificationCenter#observe, UITableView#plain?)
  • CRuby extensions missing from RubyMotion (String#underscore etc)

Anyone have beef with any part of that? Should BW do more, less, or something different than that? (independent of the mechanics of how that code is organized or pulled in)

There's also a consideration to make that if/when RubyMotion is on other platforms, BubbleWrap should continue to be the place folks can trust for platform-independent abstractions.

— Reply to this email directly or view it on GitHubhttps://github.com/rubymotion/BubbleWrap/issues/200#issuecomment-15730400 .

supermarin commented 11 years ago

@clayallsopp agreed with that. BubbleWrap was the No.1 thing installed when I've started each project. Something essential for RM development.

Other than your points, it could abstract all the widely used (and long) constants, what would also be a benefit when the other platforms jump in.

colinta commented 11 years ago

I've mentioned this before, but I think BubbleWrap is great at the "wrapper" part. It provides such a minimum amount of "inside out" extensions (adding methods to cocoa classes) that I wish they weren't there.

We're focusing on BW's future: I think we must figure out how bubble-wrap and sugarcube work side-by-side. Here's why:

SugarCube does not wrap like BW does, it's all about adding methods to existing classes; we can keep BubbleWrap "clean" of that, and I think that would be a great selling point of it (keeps your classes clean).

Some extensions must stay, though, namely those CRuby extensions.

@colinta colinta.com github.com/colinta

On Apr 1, 2013, at 12:53 PM, Clay Allsopp wrote:

I feel like BubbleWrap should be the one-stop solution for three things:

Concise abstractions for common patterns (BW::HTTP, BW::Alert in #201) Smaller extensions to Cocoa classes (NSNotificationCenter#observe, UITableView#plain?) CRuby extensions missing from RubyMotion (String#underscore etc) Anyone have beef with any part of that? Should BW do more, less, or something different than that? (independent of the mechanics of how that code is organized or pulled in)

There's also a consideration to make that if/when RubyMotion is on other platforms, BubbleWrap should continue to be the place folks can trust for platform-independent abstractions.

— Reply to this email directly or view it on GitHub.

clayallsopp commented 11 years ago

Right, the big difference is that Sugarcube often extends Ruby classes to add Cocoa-specific functionality (i.e. :red.uicolor, [160, 210, 242].uicolor). Obviously Sugarcube has lots of other features (the REPL adjustments are what I see demo'd quite often and have no parallel in BW), but thats how I think of the libraries.

Put another way, BW's wrappers/extensions are roughly Ruby -> Ruby and Cocoa -> Ruby, but BW won't/shouldn't go Ruby -> Cocoa.

That sound sensible, @colinta?

clayallsopp commented 11 years ago

And yknow, maybe most of the ActiveSupport/Ruby -> Ruby extensions should be included in a third library that both BubbleWrap and Sugarcube require as dependencies.

colinta commented 11 years ago

That, to me, would be the perfect candidate for "motion-support" :-)

colinta

On Apr 1, 2013, at 3:19 PM, Clay Allsopp notifications@github.com wrote:

And yknow, maybe most of the ActiveSupport/Ruby -> Ruby extensions should be included in a third library that both BubbleWrap and Sugarcube require as dependencies.

\ Reply to this email directly or view it on GitHub.

jimsynz commented 11 years ago

Like I think I said earlier, I'd like to see the core and standard library implemented first, before we get on to active support.

qrush commented 11 years ago

There's something to be said here for not reinventing these wheels. ActiveSupport and the Ruby stdlib both work in Ruby already. I think RubyMotion should natively support gems and require. If it did, we wouldn't be having this argument.

On Mon, Apr 1, 2013 at 5:43 PM, James Harton notifications@github.comwrote:

Like I think I said earlier, I'd like to see the core and standard library implemented first, before we get on to active support.

— Reply to this email directly or view it on GitHubhttps://github.com/rubymotion/BubbleWrap/issues/200#issuecomment-15739201 .

tkadauke commented 11 years ago

@qrush: While I generally agree with that, I don't believe that is going to happen anytime soon. Also, there are more incompatibilities between MRI and RubyMotion than just a lack of "require", especially when it comes to a support library. One example is the different class hierarchy in RubyMotion, which is relevant when implementing things like Hash#symbolize_keys, which has to be added to NSDictionary to also support hashes returned by Cocoa classes. Things like that make porting ActiveSupport to RubyMotion very invasive. Not to mention the fact that a LOT of things in ActiveSupport are irrelevant for iOS apps.

clayallsopp commented 11 years ago

@qcrush yeah i think everyone agrees that would be ideal, and there's probably a way to shim require to get a portion of the CRuby gems included (see https://github.com/archan937/lock-o-motion), but it will always be impossible to have complete MRI compatibility due to the lack of string-based evals and binding hackery in RubyMotion (plus what @tkadauke said). those are basically hard limits without changing the nature of rubymotion.

to offer an example, something as simple as class accessors (https://github.com/rails/rails/blob/master/activesupport/lib/active_support/core_ext/class/attribute_accessors.rb) would need to be implemented in a custom manner for RubyMotion.

clayallsopp commented 11 years ago

(Didn't mean that to come off as critical or anything, just seems like effort > reward in most cases unless rubymotion supports those missing features) On Apr 1, 2013 6:10 PM, "Thomas Kadauke" notifications@github.com wrote:

@qrush https://github.com/qrush: While I generally agree with that, I don't believe that is going to happen anytime soon. Also, there are more incompatibilities between MRI and RubyMotion than just a lack of "require", especially when it comes to a support library. One example is the different class hierarchy in RubyMotion, which is relevant when implementing things like Hash#symbolize_keys, which has to be added to NSDictionary to also support hashes returned by Cocoa classes. Things like that make porting ActiveSupport to RubyMotion very invasive. Not to mention the fact that a LOT of things in ActiveSupport are irrelevant for iOS apps.

— Reply to this email directly or view it on GitHubhttps://github.com/rubymotion/BubbleWrap/issues/200#issuecomment-15740511 .

colinta commented 11 years ago

On a side note, I don't want anyone to think that BubbleWrap will ever go "unmaintained". I stay VERY silent on this repo, because ya'll have it well in hand, but if the party dies down, I can happily step in as to make sure issues are resolved and so on. :smiley:

kastiglione commented 11 years ago

@qrush Agreed, there's such a vast amount of existing Ruby code, it's a shame to have to waste time building things that already exist. We all make-do with the few limits that RubyMotion has compared to CRuby, I don't see why the same wouldn't be true of support for require and gems even if they had limits.

@tkadauke Good point. I had a look and RubyMotion adds Ruby methods to the Objective-C base classes (NSDictionary), not the Ruby subclasses (Hash). As such, it's probably not a big deal if ActiveSupport does the same since our app's will already be vulnerable to upstream iOS changes. It's also possible to allow integration to be done in a way that allows the developer to choose which classes they want modified for their particular app.

@clayallsopp A couple months back, I spent some time updating ActiveSupport to replace all uses of {class,module}_eval taking a string and rewriting it to use blocks. Note that ActiveSupport doesn't use binding's. Almost all tests passed, with the only couple exceptions being very minor features that I think wouldn't impact RM developers for example, stack trace side effects. Here's the rewrite of attribute_accessors.rb. The branch is here: eval-less. I've been able to use ActiveSupport's inflector and all the core extensions I tried worked as well.

A recent blog post by @tenderlove (Dynamic Method Definitions) advocates for using {class,module}_eval with blocks over string code that needs to be evaluated. As a result, he rewrote one file, core_ext/class/attribute.rb to eval blocks instead of strings. (diff). Previously there was a clear preference to define methods with strings over blocks, but if that's changed, it will be great for RM's use of ActiveSupport.

sxross commented 11 years ago

I have a general concern about the far-reaching gems like SugarCube and BubbleWrap which address so many diverse use cases, not all of them interesting for a particular app. In Objective-C, it's easy to ship a pretty big library or framework, if you will, and be worry-free about the memory impact because the linker will simply discard code that's not referenced.

How does anyone feel about this in RubyMotion. Should we be worried about packaging up monolithic gems like we do with MRI, or should we be approaching this in a more granular manner? Or am I overthinking it?

colinta commented 11 years ago

Bubble wrap is already pretty granular, and the 1.0 release of sugarcube is planned to be broken up like you mention here.

clayallsopp commented 11 years ago

Like @colinta said, BubbleWrap is less of a "monolithic" framework and more of a collection of small modules. Doing a plain require "bubble-wrap" only compiles the core and http modules into your app; anything else needs to be explicitly done.