Hi Olaf, you're right. This change is not for free. We should make a good job on classification. In the other hand think that we are trying to setup an scenario that will be there for every 1.x releases. So once we make all this changes they'll be fixed since 1.0 means stability and we have to live with mostly 99% we've done. That 1% can still change, since we can have good reasons to make some change, but that change will be clearly unique and will appear clearly in release notes of a 1.x version.
Think that this is normal in every 1.0 release. We live it in many other projects, and is normal to live it in Royale in our way to 1.0 If we don't clean our house before the great release, then our visitors, could notice the dust piled up under the carpet ;) Thanks 2018-05-29 20:15 GMT+02:00 Olaf Krueger <[email protected]>: > > I agree that beads could use organization. > > My understanding of these beads is that in the best case, they could be > applied to various actors (DRY). > Even if it's probably a good idea to organize those beads, isn't there also > a danger to end up with more chaos? > > Imagine if somebody implements an "AwesomeBead" which provides whatever > feature related to a TextField. So he assigns the bead to e.g. to > "beads.awesome.textfield". > Later somebody other implements a "TextArea" component and it turns out > that > the "AwesomeBead" also works with the new "TextArea". > So, to make this clear we maybe want to move the "AwesomeBead" to > "beads.awesome"... but this would break any others apps. > In the worst case, this "AwesomeBead" would be just copied to > "beads.awesome.textarea". > > I am not so experienced with the Royale code base as all of you. > I just want to mention that such organisation probably only works if such > bead classification/assignments don't change and the membership of all > those > beads is really clear. > > Just a thought... > > Olaf > > > > > > -- > Sent from: http://apache-royale-development.20373.n8.nabble.com/ > -- Carlos Rovira http://about.me/carlosrovira
