On 01/18/2012 02:06 PM, Marc Puts wrote:
> Hi Thomas,
>
> On 01/18/2012 11:08 AM, thron7 wrote:
>> members :
>> { //<- on new line, for class-level map
>> foo : function () { //<- on same line, for member functions
>> var bar = function ()
>> { //<- on new line, for "normal" functions
>>
>> ??? - That looks demanding. Also, it would require a whole slew of new
>> config keys, like
>>
>> "open-curly" : {
>> "class-level-map" : ...
>> "property-definition" : ...
>> "functions-member" : ...
>> "functions-other" : ....
>> "loop-if" : ...
>> "loop-while" : ...
>> "loop-switch" : ...
> Yes, that's what I mean.
>
> I don't know how hard this would be to implement; I guess it depends on
> how much information is already available to the pretty printer right
> now.
It's tedious but not hard, a matter of looking for more lexical
contexts, and making the appropriate switches.
> As for the amount of config keys, I see nothing wrong with that, as
> long as each option has a sensible default value. But I'm not hindered
> by any inside knowledge of the generator. :-)
Even with defaults, some people expressed concerns regarding the sheer
number of config keys for the generator (They don't feel comfortable
"wading" through the manual reference for the configuration). Hence I
try to keep the number low, and the keys as generic as possible.
> For my PHP code, I use Zend Studio, which also offers a lot of control
> on the code formatter. See [1] for an example. It might be useful for
> inspiration.
Yes, thanks, that will be helpful.
> Of course, the more control we can get, the better. But I
> only mentioned the braces because the pretty printer already does
> everything else pretty much the way I want! (After disabling docblock
> creation, that is).
Yes, this is another good point. It's probably not too hard to satisfy
like 80% of the expections of all people. But when it comes to
pretty-printing, 80% is often not good enough for people, and then they
reject it alltogether. So this is often an all-or-nothing-at-all case.
So as you cannot please everybody 100% with defaults, the only chance is
to provide the config options that make it possible for everybody to get
Their Exact Style, even if that raises the complexity level of the
pretty-printing considerably (both on the config and implementation level).
But I'm still not sure this is the road to success. The suggestion you
made, with relating the curly braces to the specific context (members
map, members function, property, ...), would have never occurred to
myself. All these can be seen as lexical parent contexts. On the other
side, we handle curlies according to block complexity, so child context
if you will. This is an entirely different criterion. And there is no
way from stopping somebody to come up with new criterions, like wanting
to depend formatting on special comments that precede the code, even
having pretty-print JSDoc tags, to control formatting on each code
location individually. I wonder how this would all end up, how to
resolve precedence issues between matching criteria, and such.
Thanks,
T.
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
