Over at my Curlr blog I have added some suggestions for improving the quality of Curl code by enforcing some coding standards.
At the moment in a Curl file containing a class definition, class-side and instance-side expressions can occur willy-nilly.
Some developers have the idea that if a field is only referenced in one method, then declare that field where the method is declared. And declare class-side variables wherever you will.
As Curl still lacks a refactoring browser, this generous approach to coding-as-scripting can and does add to maintenance headaches.
I particularly like my own idea of {i-attributes } and {d-attributes } as those declared once -and-only-once as requiring to be initialized in a constructor or not.
These are not substantive changes such as adding co-expressions or generators as found in ICON and UNICON or becoming more truly multi-paradigm as is distributed OZ. What they address are some of the needs of PITL. In a large codebase, it is important to be able to grasp the intention at a glance so as to move on in confidence (no obvious issue there, so look elsewhere) when refactoring code without the craftsman’s tool.
What I have proposed is not a restriction, but rather only an option to be enforced as a tighter compiler-directive than stringent? is at present.
While never a big fan of UML, I have opted to suggest rational? = true for this meta-level view of Curl class code.
Sometime ago I suggested that a macro for SCURL file headers was overdue. I now have that suggestion:
{curl-class }
What this will mean is that when the header is found, that SCURL file may only contain one Curl class and only a Curl class (no stray globals, proc’s and other flotsam-and jetsam.)
Call it “Curl with class”. || humor
