http://forum.starling-framework.org/topic/going-to-request-pull-on-changes-also-private-needs-to-be-changed-to-protected The Starling Framework Community en-US Sat, 18 May 2013 16:27:32 +0000 http://bbpress.org/?v=1.0.3 q http://forum.starling-framework.org/search.php http://forum.starling-framework.org/topic/going-to-request-pull-on-changes-also-private-needs-to-be-changed-to-protected#post-29806 Fri, 12 Apr 2013 16:02:38 +0000 esDot 29806@http://forum.starling-framework.org/ <p>+1 Private just makes extending the framework a complete chore, when otherwise it would be extremely simple. </p> <p>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. </p> http://forum.starling-framework.org/topic/going-to-request-pull-on-changes-also-private-needs-to-be-changed-to-protected#post-29789 Fri, 12 Apr 2013 14:27:52 +0000 divillysausages 29789@http://forum.starling-framework.org/ <p>+1 for this request. I can understand why you'd do it, but from our perspective:</p> <p>1) We can either always use the master, and code around it, which can be pretty hard, or<br /> 2) Use our own branch, then every time the master is updated (which is pretty often), merge the changes, which can be a pain.</p> <p>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 </p> http://forum.starling-framework.org/topic/going-to-request-pull-on-changes-also-private-needs-to-be-changed-to-protected#post-11761 Wed, 12 Sep 2012 11:38:17 +0000 Daniel 11761@http://forum.starling-framework.org/ <p>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!</p> <p>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. </p> http://forum.starling-framework.org/topic/going-to-request-pull-on-changes-also-private-needs-to-be-changed-to-protected#post-11719 Tue, 11 Sep 2012 17:55:52 +0000 dlots 11719@http://forum.starling-framework.org/ <p>+1 as stated in the OP </p> http://forum.starling-framework.org/topic/going-to-request-pull-on-changes-also-private-needs-to-be-changed-to-protected#post-11106 Thu, 30 Aug 2012 16:02:24 +0000 MarcelKlammer 11106@http://forum.starling-framework.org/ <p>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.</p> <p>So the only thing, that happens here: We have to work around the private accessors, instead of easily extend the frameworks classes.<br /> Please rethink about it, it would really help other developers extend the frameworks classes. </p> http://forum.starling-framework.org/topic/going-to-request-pull-on-changes-also-private-needs-to-be-changed-to-protected#post-6964 Tue, 29 May 2012 00:15:46 +0000 dlots 6964@http://forum.starling-framework.org/ <p>k, sounds good. </p> http://forum.starling-framework.org/topic/going-to-request-pull-on-changes-also-private-needs-to-be-changed-to-protected#post-6961 Mon, 28 May 2012 23:40:23 +0000 MacShrike 6961@http://forum.starling-framework.org/ <p>Omg. injection/service location binding?<br /> I'm really gonna ask for a book on flash programming for my birthday.<br /> &lt;img src=&quot;http://forum.starling-framework.org/my-plugins/bb-smilies/default/icon_biggrin.gif&quot; title=&quot;:D&quot; class=&quot;bb_smilies&quot; /&gt; </p> http://forum.starling-framework.org/topic/going-to-request-pull-on-changes-also-private-needs-to-be-changed-to-protected#post-6955 Mon, 28 May 2012 23:10:57 +0000 Daniel 6955@http://forum.starling-framework.org/ <p>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.</p> <p>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.</p> <p>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. </p> http://forum.starling-framework.org/topic/going-to-request-pull-on-changes-also-private-needs-to-be-changed-to-protected#post-6884 Sun, 27 May 2012 21:57:33 +0000 dlots 6884@http://forum.starling-framework.org/ <p>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. </p> <p>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.</p> <p>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.</p> <p>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. </p>