2020-11-25 16:17

Adress the elephant in the room, is Sugar starting to get obese ?

As brought up in (https://github.com/hyperoslo/Sugar/pull/78#issuecomment-220854098), Sugar is growing out of proportion, one can even start to call it obese.

We need to come up with a good strategy to tackle this problem. As I wrote in #78;

I think we need to adress this is a good way, maybe splitting it out in to separate repos where it makes sense and then starting to mark things as deprecated and then remove extract and remove bits and pieces from the Sugar core.

That could be one way of handling it. But we need to find a good middle ground to find what goes into Sugar and what does not. Do we see Sugar as a incubator for future pods, exposing where there could be potential for more components or is it more like the name implies, a syntax sugar for Cocoa and Cocoa Touch were we feel that Apple default implementation is falling short.

Regardless of that, the issue needs solving so, without further ado, discuss peoples!



  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答


  • weixin_39560207 weixin_39560207 5月前

    As seen in other places:

    I think the problem resides in that we are starting to confuse convenience with a sugar. While the first one is just something that is nifty and looks better than what Apple provides, the latter one is something that fixes some tedious work you have to do over and over (dispatch, localize, iPhone size, etc.).

    I think Sugar should be the second one, whereas another pod, could be the first one.

    There is no point on deprecating something if that something will disappear and won't be replaced. Where do you put it then? In some sort of big box and use it if you want? That is weird to me.

    点赞 评论 复制链接分享
  • weixin_39913141 weixin_39913141 5月前

    I agree. I started to notice this fact when #68 was created. I also agree with on convenience vs sugar.

    Beside that, i have concern about supporting Mac OS because in that case all extensions written on UITableView, UICollectionView, UIView, UIImage (basically UIKit) are useless classes and for iPhone SDK user NSTableView+Indexes does not make any sense.

    May be we can use this as boundary if we decide to split sugar into two different pods (convenience vs sugar). So basically,

    Sugar = shared folder Convenience = UIKit and Keyboard extensions.

    Now this division is just a suggestion and can change completely as we discuss this issue.

    Next things is, whatever we decide with Sugar, How are we going to do that, because i guess Sugar is one of our popular project and changes are going to effect other people as well as our own projects and i am not completely sure with deprecating things.

    点赞 评论 复制链接分享
  • weixin_39819661 weixin_39819661 5月前

    I'm not a big fun of small libraries, but sometimes it makes sense, so I would split Sugar even more than shared and convenience. Things like https://github.com/hyperoslo/Sugar/pull/78 or keyboard listeners could be separate pods, Gesture and KeyboardHandler, so people can use them only if it's needed.

    点赞 评论 复制链接分享
  • weixin_39897749 weixin_39897749 5月前

    I think it also comes down to the question of the size of that syntactic thing and how often people really use it. In my opinion - Most of thing that are considered syntactic are extension to Foundation - Keyboard observer and Gesture seems like more convenience wrapper, but making it to another pod should introduce nano libraries 😬 - Hope that dynamic lib loader be faster 😇

    点赞 评论 复制链接分享
  • weixin_39560207 weixin_39560207 5月前

    I see your point, . But I think that is more a snippet or a gist than a pod (ish).

    点赞 评论 复制链接分享
  • weixin_39929254 weixin_39929254 5月前

    I see one problem with splitting them into to many projects, if you need a lot of them, you might run into issues with dynamic frameworks as they will be initialized during startup.

    点赞 评论 复制链接分享
  • weixin_39819661 weixin_39819661 5月前

    Well, everything we're doing is a wrapper around something else. As for dynamic frameworks, I don't know, it's gonna be faster if we keep everything just under projects sources.

    But when you think about it as a set of independent features and move the code out of "universal" library you get some advantages: - it becomes more extensible, so you could add more features and improvements not thinking that it grows out of proportion. - it's easier to test. - you install this thing only if it's needed, so you don't fetch a huge library just to use dispatch and delay.

    点赞 评论 复制链接分享