Thanks Alex, I look forward to your feedback. It would be great to see (from you or anyone else) - within this thread - suggested improvements/corrections or other topics that should be added, or questions that should be addressed.
I know there are areas that need improvement in a number of areas of the document, but I'm hoping that this will be 'fixed' by making it a shared goal and getting input from others, not by me kludging away in the background. I wanted to get something up that is a starting point only. I do understand the avoidance of the 'swiss army knife' approach to base classes in Flex 4, but had wondered about whether we were focusing on the 19% of functionality that might be useful for 5% of developers (Basic) vs. the 20% of that will suit 80% of developers (e.g. express) -I'm not saying that the pareto relationships there are correct, just using it for 'relative' comparison. But I think it is just a case of getting used to a new way to thinking, which is different to Flex4 (and Flex3). It would be really great if you can lead a thread specifically about this. I also suspect there will be no 'one true way' to make incremental functionality beads either. But documenting the pros and cons of each approach (which we already started in one of the other threads) might provide useful guidance about when to choose which approach (inheritance and/or utility functions etc). I'm looking forward to that discussion because I think I was getting a lot out of the earlier discussion on that already. In the end writing these things in a document is not something I call fun. "I'd much rather be coding". But I do believe that having 'team-sourced' content, as an output of focused list discussions, could make the generation of the document content a much easier process, and that the process itself could help improve decision quality, build consensus, and provide resources that will be useful for team alignment and future reference info for others. I think any one of those reasons is enough for me to stop trying to create more of the content myself! On Sun, Jul 2, 2017 at 3:57 AM, Alex Harui <aha...@adobe.com.invalid> wrote: > Hi Greg, > > Thanks for writing this up. I took a quick read. I'll do a more careful > read next week and have more detailed comments. One thing I wanted put up > for discussion now is the notion of "defaults". Really, I'm trying to get > away from the notion that there is one default we have to decide on. IMO, > that's another old way of thinking from Flex. FlexJS is designed to > support multiple component sets. Express will have different defaults. > MDL has different defaults. The Basic set has a particular design goal > (feature parity with SWF) and thus will have different defaults. There is > often no one right answer, so we build different component sets and folks > will try them and decide for themselves. > > Thoughts? > -Alex > > On 6/30/17, 3:29 PM, "Greg Dove" <greg.d...@gmail.com> wrote: > > >Following on from other discussions, I have made a start on something here > >https://na01.safelinks.protection.outlook.com/?url= > https%3A%2F%2Fcwiki.apa > >che.org%2Fconfluence%2Fpages%2Fviewpage.action%3FpageId% > 3D71013028&data=02 > >%7C01%7C%7C35f519d4ea87431fd80808d4c0078bc3% > 7Cfa7b1b5a7b34438794aed2c178de > >cee1%7C0%7C0%7C636344586020292933&sdata=aj4YiAsUQDGoW5Bf% > 2BQ2wyJxgqmguZ18T > >Zng2jGcWIkY%3D&reserved=0 > > > >In the end this will only work if people want to do it. But I do believe > >that one way of getting everyone on the same page here (and we do have > >clear signs that not everyone is), is to, quite literally, get everyone on > >the same page :). > > > >It is currently half content, half notes. There is more to harvest from > >list discussions I think, some topics have progressed further than when I > >started trying to capture ideas, so please correct any mistakes in the > >definitions or add topics and questions that need 'resolution'/guidance. > > > >I personally would like to see some concrete guidance in the 'How does > >PAYG > >get implemented' section. There were definitely the beginnings of some > >healthy discussions around some of the options for beads for example. > >(DRY, > >inheritance, utility functions etc). > > > >The goal here is to turn any list discussions around > >uncertainties/misunderstandings into something that represents consensus. > >I > >think this should be do-able by simple discussions about specific topics, > >maybe with informal voting if necessary. If there is no consensus then I > >guess PMC could do a formal vote? (I don't know what makes sense here) > > > >Beyond work on the SDK, this type of information (in some form) might also > >be helpful as part of the documentation for 1.0 when we get there, so it > >could save someone time later on as well as being useful in the near term > >(I hope). > >
