Starling Forum

1. 

   dlots
   

   Senior Bird
   Joined: Dec '11
   Posts: 84

   Why are all the internal members all private? This makes it impossible to chnage functionality without being forced to stay up to date with master which is a waste of time for testing changes.

   I would like to push a change of unrelated changes(scrollRect, static variable unique names to work with haxe) but would also like to change all privates to protected. Would you accept a change of private to protected? There is absolutely no reason to indiscriminately use private in an open source project.

   Having private members destroys any possibility for fast testing with dependency injection/service location binding. You're forced to do it with git branches instead because you're forced to changing core files. It definitely needs to be changed.

   Perhaps you prefer (protected) accessors. Accessors are slower, and probably shouldn't be used in a core library in performance critical (main loop) parts and having accessible protected members adds an additional level of flexibility when needed. A possibly mutated value of public accessor is not what is always needed in a member access.

   Posted 12 months ago #
2. 

   Daniel
   

   Primary Feather
   Joined: Jan '10
   Posts: 2,461

   I totally understand what you mean, but I did this on purpose. As soon as I make all of those objects "protected", just about everybody will use and access them. This makes it extremely difficult for me to change any code later, because so much existing code will break if I do.

   For that reason, I decided to keep this stuff private. Advanced developers like you can use Git branches to change it, but will think twice before doing so, because it's an extra effort. And that's good, because the less you use these internal implementation details, the less code will break when I change them.

   When you look at the original Flash API, you won't find many protected members, too. For exactly the same reason! The difference with OS software is that you can use them nevertheless.

   Posted 12 months ago #
3. 

   MacShrike
   

   Expert Bird
   Joined: Apr '12
   Posts: 194

   Omg. injection/service location binding?
   I'm really gonna ask for a book on flash programming for my birthday.
   

   Posted 12 months ago #
4. 

   dlots
   

   Senior Bird
   Joined: Dec '11
   Posts: 84

   k, sounds good.

   Posted 12 months ago #
5. 

   MarcelKlammer
   

   Novice Bird
   Joined: Dec '11
   Posts: 8

   I've to say that I disagree. Whenever you change the API, we have to change our extensions, too. We have to take your Starling code, review it and change our code accordingly.

   So the only thing, that happens here: We have to work around the private accessors, instead of easily extend the frameworks classes.
   Please rethink about it, it would really help other developers extend the frameworks classes.

   Posted 8 months ago #
6. 

   dlots
   

   Senior Bird
   Joined: Dec '11
   Posts: 84

   +1 as stated in the OP

   Posted 8 months ago #
7. 

   Daniel
   

   Primary Feather
   Joined: Jan '10
   Posts: 2,461

   Yes, Marcel, when I change the API, you have to change your extensions -- that is exactly the point! When I made all those properties "protected", the API would be much bigger (because those were part of the API then), which means changes would happen much more often, still!

   That said, I'm not totally against making something protected -- there are cases where it does make a lot of sense! I can make changes on a per-issue basis, of course, when I think it would be useful.

   Posted 8 months ago #
8. 

   divillysausages
   

   Hatchling
   Joined: Apr '13
   Posts: 2

   +1 for this request. I can understand why you'd do it, but from our perspective:

   1) We can either always use the master, and code around it, which can be pretty hard, or
   2) Use our own branch, then every time the master is updated (which is pretty often), merge the changes, which can be a pain.

   Normally, you extend classes to add additional functionality, or to help integrating into a current framework. Having everything protected makes this pretty hard, and sometimes because of the architecture of Starling, we need to resort to horrible hacks unless we want to support our own branch

   Posted 1 month ago #
9. 

   esDot
   

   Expert Bird
   Joined: Sep '11
   Posts: 180

   +1 Private just makes extending the framework a complete chore, when otherwise it would be extremely simple.

   If updates break our modifications so be it, it's our job to maintain our sub-classes. Typically at some stage in development you lock down your Starling version anyways and stop pulling updates.

   Posted 1 month ago #

RSS feed for this topic

Reply

You must log in to post.