From: Bob H. <ha...@st...> - 2006-05-03 01:29:53
|
Miguel wrote: >>I also realized this is important for loadInLine, so I implemented it as >> >> > >Good point. > > > >>set defaultLattice {a b c} >> >> > >Bob, > >I am not familiar with the changes that you previously made to the >compiler for defining 3D point constants in the draw code. So, it is not >clear to me what syntax you proposed using. > >So, I am somewhat concerned about using { curly braces } in this context >... because I think that we will need them for something else. > > > Well, it was your suggestion to use braces, because, as you say, () and [] are taken. What are you thinking you would want braces for? >( Parentheses ) and [ square brackets ] are already taken, so there are >not too many pairs of "bracketing" characters left. > >Q: Is there a big advantage to using { curly braces } in this context? Or >could you just use 'set defaultLattice a b c' or 'set defaultLattice n' >and use the argument count to distinguish between the two? > > > While the braces are not necessary in this context, I've found that they are very helpful in general to distiguish xyz triples. Which is more readable: moveto 2.0 {34.5, 45.6, 67.4} 35. 200 or moveto 2.0 34.5 45.6 67.4 35. 200 ? It's actually very nice in terms of documentation to refer to an "xyz" coordinate rather than just three numbers. It's better programmatically, because one can identify right from the "{" that a coordinate is coming. So that allows much better control. Within any triple such as this, there isn't any significant reason to constrain someone to floats or integers, so that makes it more user-friendly. Who cares if one writes {0 0 0} or {0.0 0.0 0.0} for example. Really, I don't care what is used, but I've been using braces now for two months, and they work great. It's hard for me to imagine a context where we would want braces that would lead to an ambiguity in relation to this. Re the compiler -- you have bob200603 local, right? If not, download it so you can do some quick comparisons. (Are you using something like Eclipse, which allows super-fast comparisions across projects locally?) Let's see, in terms of the compiler, {} show up as follows: private boolean compileCommand(Vector ltoken) { ... if (tok == Token.leftbrace || tok == Token.dollarsign) return true; // $ or { at beginning disallows expression checking, similar to color parameter [x.....] ... That's it. Nothing else in the compiler. Then, in Eval, you will see at times something like the following: if (statement[1].tok == Token.leftbrace) { //center { x y z } Point3f pt = getCoordinate(1); viewer.setNewRotationCenter(pt); return; or case Token.leftbrace: // {X, Y, Z} Point3f pt = getCoordinate(i); i = pcLastExpressionInstruction; if (isAxisAngle) { if (axesOrientationRasmol) pt.y = -pt.y; rotAxis.set(pt); isAxisAngle = false; } else { points[nPoints++].set(pt); } break; etc. Then the getCoordinate() method allows a certain amount of freedom -- commas or not, integers or floats. So a lot of what would have been tedious checking for three numbers turned into simple "if a coordinate is coming, get it" at the EVAL stage and a bit more "natural" freedom for the user. My point is simply that you can make this difficult (modify Compiler) or keep it simple (add it into Eval). The compiler is a really nice piece of work, and it's very important for expressions, but I don't see any real need to parse through all these at compile time. Just my opinion. Bob >Miguel > > > >------------------------------------------------------- >Using Tomcat but need to do more? Need to support web services, security? >Get stuff done quickly with pre-integrated technology to make your job easier >Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >http://sel.as-us.falkag.net/sel?cmd_______________________________________________ >Jmol-developers mailing list >Jmo...@li... >https://lists.sourceforge.net/lists/listinfo/jmol-developers > > |