Howdy! [EMAIL PROTECTED] wrote: > In testing the migration from 0.6.5 to 0.7(pre), I had two failures, and some > problems for which I provide suggestions/requests... > > [...] > > Generally, the migration went well.
Thanks Derrell for being such an "early bird" ;-) and the news on quite successful auto-migration. While it's expected to work in principle, it's not thoroughly tested yet. Any feedback like yours is appreciated and for sure we are going to ask for much more feedback before 0.7 ... > I did find, though, that it restructured > the code *style* which I found quite annoying. I don't think that there is > any reason that if I nicely structure an array or object, or put my braces at > the beginning of the "next" line, that the migration should move things around > and "unstructure" or "restructure" it. Braces movement seems most prevalent > with the construct method, but I saw it elsewhere as well -- particularly with > my nicely indented structured arrays and objects. Sigh, nobody seems to read the official information. :-( The fact that the automatic migration to 0.7 will modify the style of existing code is being communicated very explicitly on the roadmap since months http://qooxdoo.org/about/roadmap#release_0.7 Of course, it is for technical reasons, not because we force anyone to use the consistent coding style that the framework is suggesting. Only the real JavaScript parser (syntax tree) allows for the migration power that is now available to almost auto-migrate existing code. Simple regexes for instance are not sufficient. To retain the individual coding style would be extremely difficult and time-consuming, if not impossible. Sure that doesn't help you much. Sorry for modifying your individually indented code. :-( Other projects that involve many developers without individual control of the coding style, though, might even profit from the consistent style that a migration to 0.7 introduces. > The style generated by the > migration is, like in traditional qooxdoo source, mixed, not consistent. No, that should not be the case. Work on that might not be completely finished, though. Anyway, it's rather an argument for a coding style unification, right? Given the many developers and contributors of the framework, qooxdoo 0.7 is expected to have an extremely consistent coding style. Much more consistent and full of (at least preliminary) Javadoc comments than any release before. > It took me a couple of hours to fix up the code style again, and that was on > only a few of days worth of development. I expect that those with large > projects needing migration will find themselves with quite a bit of manual > labor ahead of them if they care about maintaining a consistent code style, or > one that doesn't exactly match what the migration is creating. Sure, that assumption is reasonable and it has already been communicated. I am not sure why you spent so much time at such an early stage of the migration tools for adjusting your code, given that it seemed to be working just fine after migration. It might not be unlikely that the migration in the next few days/weeks and at the time of the release will be different than it is now. Sincerely hope you didn't do a lot of premature coding style retro-fitting. :-( If people care for their very individual placements of line breaks, braces, etc. (which is perfectly ok, of course) they might not want to use the offered automatic migration in the first place. They could still do the migration by hand, which might even be faster than reintroducing some arbitrary individual coding style. > Since the migration appears to be "rewriting" much of the code, I suggest that > there be a flag (or set of flags, similar to what the "indent" program > provides) to allow the migration to maintain a consistent style agreeable to > the developer. If nothing else, then a "braces at end of line" vs "braces at > beginning of next line" option would be quite helpful, and arrays and objects > should not be restructured. To be precise, it is not expected to "rewrite" any code. As explained, it might be output with a (slightly) different style for indentation, braces and the likes. Other than that, it will obey the new OO syntax for 0.7, of course. The coding style should rather be a question of personal taste, not readability or accessibility. Your suggested configuration options are certainly a good idea (it came up before) but has been dropped for the current development in favor of a working migration tool. qooxdoo's code parser and constructor certainly makes a general code unifier, code beautifier, pretty printer possible, that would allow for many custom configurations. IDEs like Eclipse for instance could be used as orientation for an almost complete set of individual coding styles configuration options (see Preferences/Java/Code Style/Formatter). This area of development would definitely need contributors to accomplish such a configurable custom coding style. Volunteers!? Given that it is possible to auto-migrate existing applications with just a few (if not single) shell command(s) and almost no manual action like in your quite successful case, I think it's a fair compromise to have the code style modified in a consistent way. Again, if that is a no-go for someone, the migration to 0.7 could still be done manually. YMMV. A lot of stuff still is in its early stages, so any feedback and particularly contribution is very welcome, Andreas ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ qooxdoo-devel mailing list qooxdoo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
