If you could add anything you want

[John Gagon]

If you could add anything you wanted to the java language, what would
it be?

I'd predict some would say the non-imperative stuff ie: closures or the

LISP like abilities to work almost purely functionally or do macros.
Some might get smart as say "everything dot NET (dot NYET) has".

There is one thing that would be a nice compiler check that would
prevent some
stupid coding organizationally and that might be some better
information hiding
and this is rather original and with all such things, they may not be
the best ideas and so that's why I bounce it here:

Example:

(public*) package com.mycomp.mysoft.persistence
ignores
com.mycomp.mysoft.services,
com.mycomp.mysoft.web;


private package com.mycomp.mysoft.business
knows
com.mycomp.mysoft.persistence,
com.mycomp.mysoft.services;

* the default

This could have been a java swing example just as easily. Anyhow,
pardon me since it's been ten years but IIRC, C++ had friend and other
features that seemed to work like this but perhaps that is more a class
or type-grained feature.

Perhaps the reverse could also be asked and that is, what would you
remove from the java language if you could or what is the biggest
mistake. (Originality being more interesting here IMHO). i.e.: I know
the way that the way package and protected work in terms of visibility
is often criticized.

Thank you (in advance) for any corrections to conceptual mishaps here I
might have too.

John Gagon
Struggling Software Engineer

 

[VisionSet]

If you could add anything you wanted to the java language, what would
it be?

Extending the OO paradigm from just classes to package structures. They
could be so much more than simple name spaces.

 

[Oliver Wong]

If you could add anything you wanted to the java language, what would
it be?

I wrote about this before: Syntactic sugar for "final from now on". I.e.
instead of:

<code>
String myFinalValue;
{
String temp;
for (Foo f : bar) {
if (f.someCondition);
temp = f.toString();
break;
}
}
if (temp == null) {
myFinalValue = "";
} else {
myFinalValue = temp;
}
}

new AnonymousClass() {
public void method() {
system.out.println(myFinalValue);
}
}
</code>

something like

<code>
String myFinalValue = "";
for (Foo f : bar) {
if (f.someCondition);
myFinalValue = f.toString();
break;
}
}
finalize myFinalValue;

new AnonymousClass() {
public void method() {
system.out.println(myFinalValue);
}
}
</code>

- Oliver

 

[John Gagon]

Extending the OO paradigm from just classes to package structures. They
could be so much more than simple name spaces.

Yes, this would be very cool. I'm just thinking about the possibilities
of this and eliminating duplication, abstracting with packages and
doing more with various kinds of dependencies. Those dependencies could
be externally defined for example or there could be some further
constraint on all classes in those packages placed in there. It's
boggling but I can see already it would be very useful.

 

[John Gagon]

I wrote about this before: Syntactic sugar for "final from now on". I.e.
instead of:

<code>
String myFinalValue;
{
String temp;
for (Foo f : bar) {
if (f.someCondition);
temp = f.toString();
break;
}
}
if (temp == null) {
myFinalValue = "";
} else {
myFinalValue = temp;
}
}

new AnonymousClass() {
public void method() {
system.out.println(myFinalValue);
}
}
</code>

something like

<code>
String myFinalValue = "";
for (Foo f : bar) {
if (f.someCondition);
myFinalValue = f.toString();
break;
}
}
finalize myFinalValue;

new AnonymousClass() {
public void method() {
system.out.println(myFinalValue);
}
}
</code>

- Oliver

I see, so you basically prevent further assignments with a compiler
check and it would eliminate potential side effects. A "single"
assignment declaration (but delayed) might be useful too like a
finalize_after_assignment String myvar; (but it would be some single
short keyword)

John

 

[Eric Sosman]

John Gagon wrote On 05/12/06 11:28,:

If you could add anything you wanted to the java language, what would
it be?

An antidote for Eternal September.

 

[Roedy Green]

An antidote for Eternal September.

http://www.answers.com/topic/eternal-september

All time since September 1993. One of the seasonal rhythms of the
Usenet used to be the annual September influx of clueless newbies who,
lacking any sense of netiquette, made a general nuisance of
themselves. This coincided with people starting college, getting their
first internet accounts, and plunging in without bothering to learn
what was acceptable. These relatively small drafts of newbies could be
assimilated within a few months. But in September 1993, AOL users
became able to post to Usenet, nearly overwhelming the old-timers'
capacity to acculturate them; to those who nostalgically recall the
period before, this triggered an inexorable decline in the quality of
discussions on newsgroups. Syn. eternal September. See also AOL!.

 

[alexandre_paterson]

If you could add anything you wanted to the java language, what
would it be?

The one and only true Design by Contract, as defined by its inventor.

This should imply also *removing* all those unnecessary gotos from
the language (ie the over-abused and misused exceptions) and leave
exceptions, well, for really exceptional conditions (in Eiffel that
happens only when some part breaks a contract).

I've been following closely stuff like JML, Nice, etc. and more
recently Contract4J.

But real DbC integrating nicely in my IDE and having that IDE
reporting possible broken contract in real-time would be gorgeous
(that can be seen on demos of Microsoft's Spec# "specsharp"
research language and it is *really* impressive).

Link to an overview here (works fine under OpenOffice):

http://research.microsoft.com/~leino/papers/SpecSharp-MPI-SS.ppt


For the moment I'm stuck with IntelliJ IDEA's @NotNull Java 1.5
annotation... It's already a good addition to the language (some
would say it's just a fix for a language defect

http://www.jetbrains.com/idea/features/newfeatures.html#nullable

I can't wait being able to specify real contracts on my abstract
data types!

Of course YMMV,

Alex

 

[John Gagon]

http://www.answers.com/topic/eternal-september

All time since September 1993. One of the seasonal rhythms of the
Usenet used to be the annual September influx of clueless newbies who,
lacking any sense of netiquette, made a general nuisance of
themselves. This coincided with people starting college, getting their
first internet accounts, and plunging in without bothering to learn
what was acceptable. These relatively small drafts of newbies could be
assimilated within a few months. But in September 1993, AOL users
became able to post to Usenet, nearly overwhelming the old-timers'
capacity to acculturate them; to those who nostalgically recall the
period before, this triggered an inexorable decline in the quality of
discussions on newsgroups. Syn. eternal September. See also AOL!.

An obscurely guised dig at the OP, namely myself then or perhaps just a
statement of affairs in general...

John Gagon

 

[Ed]

If you could add anything you wanted to the java language, what would
it be?

An accessor level between package-private and public, so that a class
could be visible not to the whole system, but just a group of packages:
http://www.edmundkirwan.com/servlet/fractal/frac-page56.html

..ed

 

[Kent Paul Dolan]

This should imply also *removing* all those
unnecessary gotos from the language (ie the
over-abused and misused exceptions) and leave
exceptions, well, for really exceptional
conditions (in Eiffel that happens only when some
part breaks a contract).

Umm, that in itself would be one of my wishes:
remove exception handling hell by allowing
exceptions to propogate upward unhandled (untried,
uncaught) and unremarked by redundant "throws ...",
or unrelayed by rethrowing, (but warn at compile
time that such is the case) and at the top level to
default to an exception dump, stackdump and hard
error exit.

This would cater for writing the base "added value"
code _before_ doing the exception code, rather than
having handling exceptions explicitly a requirement
for compilation or testing. It is way maddening to
have simple-in-concept code cluttered by try...catch
sets, throws declarations, rethrowing, and all the
messes they make out of variable scoping, before the
main intellectual product code can be tested at all.

The second one would be to decouple class names from
file names to reduce the proliferation of space
wasting tiny files in a typical large application
suite. If other languages can use symbol tables and
linkage editors to cross-link compiled files, and
have done so for decades, Java can probably do the
trick as well.

It is even nastier to navigate a directory with a
thousand individual class files in it, than to edit
a single file with those thousand class definitions
in it.

Probably file level encapsulation should allow up to
a whole package in a single file, rather than merely
a class, an interface, or an exception declaration,
as now.

Third, allow separation of declaration and
implementation, as Ada does. This isn't quite the
same thing as declaring a Java intreface and then
separately implementing it one or several times,
because in Ada, the implementation of a declaration
is unique.

The Ada style allows the whole software suite
interface to be declared and compiled, cleaned up,
and debugged, before a stick of implementation is
written. This allows much more robust large system
architecting.

FWIW

xanthian.

 

[Kent Paul Dolan]

This should imply also *removing* all those
unnecessary gotos from the language (ie the
over-abused and misused exceptions) and leave
exceptions, well, for really exceptional
conditions (in Eiffel that happens only when some
part breaks a contract).

Umm, that in itself would be one of my wishes:
remove exception handling hell by allowing
exceptions to propogate upward unhandled (untried,
uncaught) and unremarked by redundant "throws ...",
or unrelayed by rethrowing, (but warn at compile
time that such is the case) and at the top level to
default to an exception dump, stackdump and hard
error exit.

This would cater for writing the base "added value"
code _before_ doing the exception code, rather than
having handling exceptions explicitly a requirement
for compilation or testing. It is way maddening to
have simple-in-concept code cluttered by try...catch
sets, throws declarations, rethrowing, and all the
messes they make out of variable scoping, before the
main intellectual product code can be tested at all.

[I'd even suggest that a "try{}" _not_ define a scope
of variable visibility, but instead variables declared
within it have scope the next surrounding scope. An
explicit limited scope can easily be created with an
extra set of brackets "try{{}}", but the current scope
rules mean that to be seen in the catch(){} or after the
try/catch, the variables must be declared before the
try, conflicting with the best practice that variables
be declared where they are first used.]

The second one would be to decouple class names from
file names to reduce the proliferation of space
wasting tiny files in a typical large application
suite. If other languages can use symbol tables and
linkage editors to cross-link compiled files, and
have done so for decades, Java can probably do the
trick as well.

It is even nastier to navigate a directory with a
thousand individual class files in it, than to edit
a single file with those thousand class definitions
in it.

Probably file level encapsulation should allow up to
a whole package in a single file, rather than merely
a class, an interface, or an exception declaration,
as now.

Third, allow separation of declaration and
implementation, as Ada does. This isn't quite the
same thing as declaring a Java intreface and then
separately implementing it one or several times,
because in Ada, the implementation of a declaration
is unique.

The Ada style allows the whole software suite
interface to be declared and compiled, cleaned up,
and debugged, before a stick of implementation is
written. This allows much more robust large system
architecting than the Java style does.

FWIW

xanthian.

 

[John Gagon]

An accessor level between package-private and public, so that a class
could be visible not to the whole system, but just a group of packages:
http://www.edmundkirwan.com/servlet/fractal/frac-page56.html

.ed

That seems like it would go hand in hand with the restricted packaging.
Cool.

John Gagon

 

[John Gagon]

An accessor level between package-private and public, so that a class
could be visible not to the whole system, but just a group of packages:
http://www.edmundkirwan.com/servlet/fractal/frac-page56.html

You know, I just read through your website and downloaded the analysis
tool. I find it's fairly helpful. I use a lot of metrics, LoD and PMD
and CPD etc etc and this is another one I'll use as well. Other kinds
of tools like execution coverage/dead code analysis/test coverage and
profiling etc I tend to go crazy on this kind of stuff. I tend to
really like objective statistics and code reviewing.

Does your tool, if used then guarantee certain metrics? (I could guess
but I'd rather know if you intended to cover any or unintentionally
resolved any)

BTW, I did notice a few missing words (I tend to do that) here and
there in the article. I can provide correction if you like and I like
the code examples. I was hoping to look at source for examples of how
your facades and singletons looked but I noticed you have it
obfuscated. I'm about ready to run it on some code now. Unfortunately,
one of my modules I wrote not long ago got a 0.58 but one of my other
older pieces had a 0.72. (I haven't done any other metrics on them
yet). I'm somewhat perfectionist.

John Gagon

 

[Kent Paul Dolan]

If you could add anything you wanted to the java language, what would
it be?

Without a doubt, automation of the present mess
requiring programmers to divert GUI updating code
to the Event Handling Thread. This is so awful a
misfeature when left to the programmer as to make
Java GUI programming nearly intolerable, by seeding
insidious bugs into completely normal looking code
where this need hasn't been recognized as applying.

xanthian.

 

[Hendrik Maryns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Oliver Wong schreef:

I wrote about this before: Syntactic sugar for "final from now on".
I.e. instead of:

Indeed, a situation where I have thought a few times: I’d like Eiffel’s
once functions here.

H.
- --
Hendrik Maryns

==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFEaEPqe+7xMGD3itQRAs3bAJ9SG02Aje5/3fVB7IzFI+pLYyR7iQCeP0e/
NzfEgd+v3Vgt/s5qGyhxANs=
=SXru
-----END PGP SIGNATURE-----

 

[Hendrik Maryns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kent Paul Dolan schreef:

This should imply also *removing* all those
unnecessary gotos from the language (ie the
over-abused and misused exceptions) and leave
exceptions, well, for really exceptional
conditions (in Eiffel that happens only when some
part breaks a contract).

Umm, that in itself would be one of my wishes:
remove exception handling hell by allowing
exceptions to propogate upward unhandled (untried,
uncaught) and unremarked by redundant "throws ...",
or unrelayed by rethrowing, (but warn at compile
time that such is the case) and at the top level to
default to an exception dump, stackdump and hard
error exit.

This would cater for writing the base "added value"
code _before_ doing the exception code, rather than
having handling exceptions explicitly a requirement
for compilation or testing. It is way maddening to
have simple-in-concept code cluttered by try...catch
sets, throws declarations, rethrowing, and all the
messes they make out of variable scoping, before the
main intellectual product code can be tested at all.

[I'd even suggest that a "try{}" _not_ define a scope
of variable visibility, but instead variables declared
within it have scope the next surrounding scope. An
explicit limited scope can easily be created with an
extra set of brackets "try{{}}", but the current scope
rules mean that to be seen in the catch(){} or after the
try/catch, the variables must be declared before the
try, conflicting with the best practice that variables
be declared where they are first used.]

You obviously did nut understand what Alexandre was suggesting. Read up
on error management in Eiffel. It really means removing the /whole/
exception system. But this of course will not happen.

Third, allow separation of declaration and
implementation, as Ada does. This isn't quite the
same thing as declaring a Java intreface and then
separately implementing it one or several times,
because in Ada, the implementation of a declaration
is unique.

The Ada style allows the whole software suite
interface to be declared and compiled, cleaned up,
and debugged, before a stick of implementation is
written. This allows much more robust large system
architecting than the Java style does.

You don’t believe in the single-source principle?

H.
- --
Hendrik Maryns

==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFEaEVTe+7xMGD3itQRAiE0AJ49GbAH/ek4UTXd4Jlna/6CuHaHHACfW9aq
wvwf4ZI17f52GP+q86o8nag=
=3kCM
-----END PGP SIGNATURE-----

 

[Kent Paul Dolan]

Kent Paul Dolan schreef:

Notice, for the current purposes, that the above
quite specifically _does_ leave an exception system
in place, just not the current one.

Umm, that in itself would be one of my wishes:
remove exception handling hell by allowing
exceptions to propogate upward unhandled
(untried, uncaught) and unremarked by redundant
"throws ...", or unrelayed by rethrowing, (but
warn at compile time that such is the case) and
at the top level to default to an exception dump,
stackdump and hard error exit.
This would cater for writing the base "added
value" code _before_ doing the exception code,
rather than having handling exceptions explicitly
a requirement for compilation or testing. It is
way maddening to have simple-in-concept code
cluttered by try...catch sets, throws
declarations, rethrowing, and all the messes they
make out of variable scoping, before the main
intellectual product code can be tested at all.
[I'd even suggest that a "try{}" _not_ define a scope
of variable visibility, but instead variables declared
within it have scope the next surrounding scope. An
explicit limited scope can easily be created with an
extra set of brackets "try{{}}", but the current scope
rules mean that to be seen in the catch(){} or after the
try/catch, the variables must be declared before the
try, conflicting with the best practice that variables
be declared where they are first used.]

You obviously did not understand what Alexandre
was suggesting.

Umm, I read what he _wrote_, not what some prior
agenda of mine wanted him to have written. Did you?

Read up on error management in Eiffel. It really
means removing the /whole/ exception system. But
this of course will not happen.

I'm not particularly interested in turning Java into
Eiffel. Something about Eiffel, perhaps merely that
it wasn't made freely available early enough, maybe
its politics, perhaps its intellectual difficulty,
has kept it from becoming popular, it remains more
in the "minor languages" crowd, than in the
"languages you need to know to find employment"
crowd.

Java in contrast has taken the software industry by
storm, despite being proprietary. Turning Java into
Eiffel would presumably destroy the popularity of
Java as well.

I don't have any particular problems with an
exception system. I'll grant that it can be abused
into a "goto" system, in Alexander's words, but,
used with proper discipline, it provides well for a
"what to do when you can't go on" system that lets
you handle problems "paragraph by paragraph" rather
than "phrase by phrase".

What gives me hives is an exception system that
forces me to handle an exception twelve layers deep
in the stack twelve times to get it to the top level
of the application, in the case where I really do
want just to drop dead if the case occurs, but
someone else might want to cater for the exception
somewhere half-way in-between. What gives me the
grippe is an exception system that won't _let_ me
use something that might, someday, "throw", without
wrapping the invocation in tedious grunge that makes
my code too ugly to comprehend. Those are the parts
of Java's exceptions I would like to see fixed. I
have zero problems with a compilation system that
insists on warning about unhandled exceptions, so my
management has some way to impose quality control on
my code, I just have _huge_ problems with a
compilation system that refuses to _compile_ code
with unhandled propagation of exceptions _at all_.

You don't believe in the single-source principle?

The "single source principle" I know says "don't
replicate code, refactor to make it a callable
routine instead". Ada doesn't violate that
principle, it merely allows the declaration and the
implementation of a method to reside in separate
source files, a dandy idea, allowing one to create
and review an interface uncluttered by its
implementation details. In terms of commercial
software, this allows that implementations need not
even be delivered as source code, if one is of that
"closed source" school, while catering that
declarations _can be and are_ delivered as source
code, much like C/C++ header files are.

[Nor am I a "language theorist", chained to some
family of inviolable language design principles; I'm
a practicing applications programmer, since 1961,
and what I'm interested to find in a language's
design isn't inflexibility for the sake of principle,
but stuff that helps me do that job well and
efficiently, a true fan of Larry Wall and Perl.]

xanthian.

 

[Hendrik Maryns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kent Paul Dolan schreef:

Kent Paul Dolan schreef:

Notice, for the current purposes, that the above
quite specifically _does_ leave an exception system
in place, just not the current one.

Umm, that in itself would be one of my wishes:
remove exception handling hell by allowing
exceptions to propogate upward unhandled
(untried, uncaught) and unremarked by redundant
"throws ...", or unrelayed by rethrowing, (but
warn at compile time that such is the case) and
at the top level to default to an exception dump,
stackdump and hard error exit.
This would cater for writing the base "added
value" code _before_ doing the exception code,
rather than having handling exceptions explicitly
a requirement for compilation or testing. It is
way maddening to have simple-in-concept code
cluttered by try...catch sets, throws
declarations, rethrowing, and all the messes they
make out of variable scoping, before the main
intellectual product code can be tested at all.
[I'd even suggest that a "try{}" _not_ define a scope
of variable visibility, but instead variables declared
within it have scope the next surrounding scope. An
explicit limited scope can easily be created with an
extra set of brackets "try{{}}", but the current scope
rules mean that to be seen in the catch(){} or after the
try/catch, the variables must be declared before the
try, conflicting with the best practice that variables
be declared where they are first used.]

You obviously did not understand what Alexandre
was suggesting.

Umm, I read what he _wrote_, not what some prior
agenda of mine wanted him to have written. Did you?

Hm, ok maybe you’re right. I indeed read his suggestion as abolishing
all exceptions.

I'm not particularly interested in turning Java into
Eiffel. Something about Eiffel, perhaps merely that
it wasn't made freely available early enough, maybe
its politics, perhaps its intellectual difficulty,
has kept it from becoming popular, it remains more
in the "minor languages" crowd, than in the
"languages you need to know to find employment"
crowd.

Java in contrast has taken the software industry by
storm, despite being proprietary. Turning Java into
Eiffel would presumably destroy the popularity of
Java as well.

I don't have any particular problems with an
exception system. I'll grant that it can be abused
into a "goto" system, in Alexander's words, but,
used with proper discipline, it provides well for a
"what to do when you can't go on" system that lets
you handle problems "paragraph by paragraph" rather
than "phrase by phrase".

Agree with all that.

What gives me hives is an exception system that
forces me to handle an exception twelve layers deep
in the stack twelve times to get it to the top level
of the application, in the case where I really do
want just to drop dead if the case occurs, but
someone else might want to cater for the exception
somewhere half-way in-between. What gives me the
grippe is an exception system that won't _let_ me
use something that might, someday, "throw", without
wrapping the invocation in tedious grunge that makes
my code too ugly to comprehend. Those are the parts
of Java's exceptions I would like to see fixed. I
have zero problems with a compilation system that
insists on warning about unhandled exceptions, so my
management has some way to impose quality control on
my code, I just have _huge_ problems with a
compilation system that refuses to _compile_ code
with unhandled propagation of exceptions _at all_.

But not sure about this. I will comment no further, as I do feel that
it makes code ugly often now, but I am not sure I’d find your system better.

The "single source principle" I know says "don't
replicate code, refactor to make it a callable
routine instead". Ada doesn't violate that
principle, it merely allows the declaration and the
implementation of a method to reside in separate
source files, a dandy idea, allowing one to create
and review an interface uncluttered by its
implementation details. In terms of commercial
software, this allows that implementations need not
even be delivered as source code, if one is of that
"closed source" school, while catering that
declarations _can be and are_ delivered as source
code, much like C/C++ header files are.

The single source principle I know says: ‘put everything that concerns
one unit/class/module into one file’. Under everything I understand
documentation, interface, implementation, specification, contract, ...
Then along with compilers the suitable tools should be delivered to
extract the appropriate view. Which is what happens reasonably well
with Javadoc, but I agree there might be a need for a tool to abstract
the interface view of a class without having to define a Java interface
for it. (Again, see Eiffel(Studio) for more different views.)

[Nor am I a "language theorist", chained to some
family of inviolable language design principles; I'm
a practicing applications programmer, since 1961,
and what I'm interested to find in a language's
design isn't inflexibility for the sake of principle,
but stuff that helps me do that job well and
efficiently, a true fan of Larry Wall and Perl.]

Hm, we certainly differ in that

H.

- --
Hendrik Maryns

==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFEaYnde+7xMGD3itQRApVDAJ9fGOeQXkS9M72sAZAnAtS3xjAu5QCfTILX
bXK5FuJJJsBCIi3KEd0W+88=
=5Suy
-----END PGP SIGNATURE-----

 

[Ed Kirwan]

You know, I just read through your website and downloaded the analysis
tool. I find it's fairly helpful. I use a lot of metrics, LoD and PMD
and CPD etc etc and this is another one I'll use as well. Other kinds
of tools like execution coverage/dead code analysis/test coverage and
profiling etc I tend to go crazy on this kind of stuff. I tend to
really like objective statistics and code reviewing.

Does your tool, if used then guarantee certain metrics? (I could guess
but I'd rather know if you intended to cover any or unintentionally
resolved any)

Hi, John,

I'm not entirely sure what you mean by, "Guarantee certain metrics." Do
you mean, "Are the tool's metrics guaranteed to be correct?" Well, we
use them in our work, and I know of two other shops that use them; but
would I sign an iron-clad, financially-punitive contract declaring that
the tool is free from all bugs and so the metrics are guaranteed to be
correct for all inputs?" Sadly, I would not. To date, however, there
have been few major complaints.

I get the feeling, however, that this is not what you meant.

BTW, I did notice a few missing words (I tend to do that) here and
there in the article. I can provide correction if you like

I would be delighted to receive your corrections. Engineering has
withered my English language skills to the point where they must cart
around their own bottled oxygen with them, and still they wheeze and
splutter at the slightest grammatical exertion; I would appreciate any
comments you have. It's rare indeed that anyone volunteers so
surprisingly important a service.

and I like

the code examples. I was hoping to look at source for examples of how
your facades and singletons looked

Excellent point. I should make the source examples available as
downloads. Examples, in fact, are probably not enough; so as a gesture
of appreciation for your offer above, I'll open-source a full
application with a fractal index of a perfect 1.0. Give me a couple of
weeks to cobble together a program description; I'll post notification here.

but I noticed you have it

obfuscated. I'm about ready to run it on some code now. Unfortunately,
one of my modules I wrote not long ago got a 0.58 but one of my other
older pieces had a 0.72. (I haven't done any other metrics on them
yet). I'm somewhat perfectionist.

I'm fortunately unafflicted by perfectionism: I hear it can be tiresome.

As with all metrics and as I'm sure you're aware, metrics should be
viewed with healthy caution. I'm not sure how much value can be gleaned
from pouring code that was designed without the fractal class
composition in mind into the Fractality code analyser because there are
many different methodologies that people use to maximise the OOness of
their system.

A fractal index of 0.58 does indeed suggest that a module was not,
"Programmed to an interface repository," and did not, "Eliminate
descendant dependencies;" but if these concepts were not used in the
construction of that module, then we're viewing the code from an angle
not considered by the designer: it's then perhaps no surprise that it
looks a little askew, but that doesn't imply that the code is poorly
designed; it's just designed in a way unfamiliar to an unbending code
analyser.

If, however, a module is designed from scratch with the fractal class
composition in mind, and yet still scores badly in Fractality, then we
can ask some drilling questions.