Java Syntax Extensions
James Willans
We have put together a document which outlines a proposal for adding
mechanisms to the Java language which allow it to be arbitrarily
extended, such mechanisms would support Language Oriented Programming
(LOP) and Domain Specific Languages (DSLs). The proposal is based on
some work we have been doing with XMF, an open source industrial
strength language, and all the technology required to implement this
mechanism in Java has been validated within XMF. We are interested to
receive feedback on this proposal and any thoughts are most welcome.
You can download the proposal document called "Beyond Annotations: A
Proposal for Extensible Java (XJ)" from:
http://www.ceteva.com/book.html
More details of XMF can be found on the same site.
Kind Regards,
James
Mark Space
> We have put together a document which outlines a proposal for adding
> mechanisms to the Java language which allow it to be arbitrarily
> extended, such mechanisms would support Language Oriented Programming
It's a well written document and very accessible to someone who is not
familiar with DSLs. However, I'm rather against anything that adds too
much complexity to the base language. Your examples, brief as they are,
are pretty complex and rather more difficult to read than they really
need to be. I'm not sure I'd like to actually puzzle out new grammars
and new grammar-specifications every time I open a Java source file. I
can't imagine what trying to specify a full grammar would be like. A
horrid mess, I'm sure.
Rather, I don't think you've given enough thought to frameworks and
libraries, as your paper calls them. Look at languages like Scala and
Jython. They are full independent languages that use the JVM. If you
need a DSL, use a DSL. Don't use Java. Then if you need bindings to
access your DSL functions in Java, or to access the Java API from your
new language, well that's I think that's where some opportunities are
for research.
C++ provides the best counter example why we should not accept your
proposal. C++ is a baroque mess. It tries to be all things to all
people and fails by being too complex to use for a full lifecycle. Java
succeeds by being simple enough to maintain while having enough tools to
get the job done. Let's keep that feature. It's Java's primary strength.
Chase Preuninger
1)Allow static inside of inner classes
2)Anonymous inner classes can use variables other than final ones
3)Operator Overloading
Patricia Shanahan
...
> 2)Anonymous inner classes can use variables other than final ones
What semantics would you expect this to have? Value of the local
variable at the time of construction of the anonymous class instance?
Value of the local variable at the time of reference?
Patricia
Mark Space
> 3 things that I want to see happen with Java are...
>
> 1)Allow static inside of inner classes
This I don't see the value of. How would this be different than simply
declaring a static field in the outer class?
> 2)Anonymous inner classes can use variables other than final ones
Physically I don't see how this would even work. To get a local or
other variable into an anonymous inner class, assign the vale of the
variable to a new final variable of the same type. (Clear as mud,
wasn't that?)
for( int i = 0; i<MAX; i++) {
final int j = i;
addListener( new Listener() { //... use j here..
} );
}
Here, I just make a final int, j, so that I can use it in an anonymous
inner class. You can do this with any other variable. As Patricia
says, if you have some other semantic in mind, you'll have to implement
it yourself.
> 3)Operator Overloading
Ack! Thpfff! *hurl* No way. Worst idea ever. Leave the operators in
the hands of the language writers. That's the best option, because
programmers will go all over the map if allowed free reign to alter the
language. See the first post on this thread.
Roedy Green
<chasepr...@gmail.com> wrote, quoted or indirectly quoted someone
who said :
>2)Anonymous inner classes can use variables other than final ones
That request logically does not make sense, though I agree it is an
nuisance to create the finals. I explain why at
http://mindprod.com/jgloss/nestedclasses.html#ANONYMOUSVISIBILITY
This piece of Java syntax makes me cringe.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
Patricia Shanahan
> Chase Preuninger wrote:
...
>> 3)Operator Overloading
>
> Ack! Thpfff! *hurl* No way. Worst idea ever. Leave the operators in
> the hands of the language writers. That's the best option, because
> programmers will go all over the map if allowed free reign to alter the
> language. See the first post on this thread.
I get very offended by this point of view. I would not choose to use
"+" for string concatenation, or ">>" for data input, the sort of thing
language writers have been known to do. I just want to use arithmetic
operators for arithmetic operations.
I realize that Java will probably never make it as a language for
numerically intense work, but the clunky syntax for complex arithmetic
cannot help.
Patricia
Roedy Green
<chasepr...@gmail.com> wrote, quoted or indirectly quoted someone
who said :
>3)Operator Overloading
I could have strangled Stroustrup and his overloading of the shift
operators in C++ to do I/O. Java has the entire Unicode character
set. There are plenty of unused symbols. There is no need to overload
and confuse the meaning of the currently defined operators with
overloading.
I would like however to define new operators in Java, just as you can
in Forth, but not overloading the primitive operators, using symbols
like Circle Plus.
I find even Java's overload of + for both addition and concatenation
infuriating. see
http://mindprod.com/jgloss/gotchas.html#CONCATENATION
To the mathematician, it sounds like a good idea, but in practice,
e.g. in C++, it primarily becomes a technique for writing
impenetrable code.
see http://mindprod.com/jgloss/umain.html
Mathematicians have dozens of fonts they use to help sort out what you
really mean by (+).
Roedy Green
<chasepr...@gmail.com> wrote, quoted or indirectly quoted someone
who said :
>1)Allow static inside of inner classes
That one I find strange. I don't understand why that restriction is
there. There must be a per-class object anyway for inner classes.
Mark Space
> Mark Space wrote:
>> Chase Preuninger wrote:
> ...
>>> 3)Operator Overloading
>>
>> Ack! Thpfff! *hurl* No way. Worst idea ever. Leave the operators
> I get very offended by this point of view. I would not choose to use
> "+" for string concatenation, or ">>" for data input, the sort of thing
> language writers have been known to do. I just want to use arithmetic
> operators for arithmetic operations.
If I understand you correctly, then in my defense I'll point out that if
operator overloading were part of the language, the offenses would be a
lot worse than using "+" for String concatenation.
I'm sure there are better ways to implement these kinds of conveniences
like a single binary operator for string concatenation, but I'm just
happy that "+" is one of the few overloaded operators that I have to
look out for. I can surely imagine a worst case far worse than that.
Java succeeds, imo, by being a relatively simple, common language that
everyone uses, even if it isn't ideal. I know any program I get in Java
to review or maintain will use operators in exactly the same way. I
have to look out for "+" and maybe a few others, but I know about them
and I can train myself to be aware of them. I can't re-train myself
each time I open a new source file.
As a comparison: as much as I love the preprocessor in C (it was such a
cool idea in 1980), it's a huge mistake. It suffers from the same sorts
of abuses (sometimes worse) as operator overloading.
Patricia Shanahan
...
> Java succeeds, imo, by being a relatively simple, common language that
> everyone uses, even if it isn't ideal. I know any program I get in Java
> to review or maintain will use operators in exactly the same way. I
> have to look out for "+" and maybe a few others, but I know about them
> and I can train myself to be aware of them. I can't re-train myself
> each time I open a new source file.
Given the capabilities of modern IDEs, I don't think it should be up to
the programmer to look for overloaded operators. An IDE could use a
different color for overloaded operators than for language-defined
operators, and a quick option to display the declaration.
Patricia
Arne Vajhøj
> Mark Space wrote:
>> everyone uses, even if it isn't ideal. I know any program I get in
>> Java to review or maintain will use operators in exactly the same
>> way. I have to look out for "+" and maybe a few others, but I know
>> about them and I can train myself to be aware of them. I can't
>> re-train myself each time I open a new source file.
>
> the programmer to look for overloaded operators. An IDE could use a
> different color for overloaded operators than for language-defined
> operators, and a quick option to display the declaration.
I don't like the idea of adding features to a language that assume
a colour coding IDE.
Arne
Arne Vajhøj
> On Mon, 14 Apr 2008 15:14:03 -0700 (PDT), Chase Preuninger
> <chasepr...@gmail.com> wrote, quoted or indirectly quoted someone
> who said :
>> 3)Operator Overloading
>
> I could have strangled Stroustrup and his overloading of the shift
> operators in C++ to do I/O. Java has the entire Unicode character
> set. There are plenty of unused symbols.
Non ASCII operators would create tons of problems for
primitive development environments.
Arne
Arne Vajhøj
> However, I'm rather against anything that adds too
> much complexity to the base language.
> C++ provides the best counter example why we should not accept your
> proposal. C++ is a baroque mess. It tries to be all things to all
> people and fails by being too complex to use for a full lifecycle.
There are even worse examples. C++ actually still lives.
PL/I and Ada95 was even more complex than C++. And even though
they are still used, then they are definitely in decline.
Arne
Lew
> 3 things that I want to see happen with Java are...
>
> 1)Allow static inside of inner classes
Why?
> 2)Anonymous inner classes can use variables other than final ones
There are difficulties with that that you wouldn't want to live with. In
practice, it's not a very egregious restriction for an inner class only to see
final variables.
BTW, that restriction is not limited to anonymous classes.
> 3)Operator Overloading
Ewwwww!
I notice that there are workarounds already in the language for each of these
"features", and that they are all features that allow for looser coding, but
risk more difficulty maintaining code. This is a priority inversion.
--
Lew
Roedy Green
<see_w...@mindprod.com.invalid> wrote, quoted or indirectly quoted
someone who said :
>To the mathematician, it sounds like a good idea, but in practice,
>e.g. in C++, it primarily becomes a technique for writing
>impenetrable code.
>see http://mindprod.com/jgloss/umain.html
oops http://mindprod.com/jgloss/unmain.html
Roedy Green
wrote, quoted or indirectly quoted someone who said :
>Non ASCII operators would create tons of problems for
>primitive development environments.
Good. :-) That would discourage frivolous use, and would encourage
proper tools for writing international code.
Roedy Green
<mark...@sbc.global.net> wrote, quoted or indirectly quoted someone
who said :
>> 1)Allow static inside of inner classes
>
>This I don't see the value of. How would this be different than simply
>declaring a static field in the outer class?
It would restrict the scope to the inner class. It is confusing to
have a variable declared at a broader scope than it is actually used.
It is mildly wicked for the same reason global variables are wicked.
Roedy Green
wrote, quoted or indirectly quoted someone who said :
>I don't like the idea of adding features to a language that assume
>a colour coding IDE.
i do. See http://mindprod.com/project/scid.html
I think the notion of a computer programming specifications purely as
ascii text manipulated with glorified word processors is really
holding things back. It is so sixties.
Patricia Shanahan
> Chase Preuninger wrote:
...
>
> Ewwwww!
>
> I notice that there are workarounds already in the language for each of
> these "features", and that they are all features that allow for looser
> coding, but risk more difficulty maintaining code. This is a priority
> inversion.
>
However, the combination of a very limited set of primitive arithmetic
types and the lack of operator overloading also risks increasing the
difficulty of code maintenance - or forces people to avoid Java for
anything that has non-trivial arithmetic expressions in any types other
than the Java numeric primitives.
Patricia
Ulrich Eckhardt
[about Operator Overloading]
> I could have strangled Stroustrup and his overloading of the shift
> operators in C++ to do I/O.
That wasn't him, I think it was Barry Schwarz that wrote the IOStreams
library which was later in a modified version incorporated into the
standard. Further, the use of '<<' for output wasn't even new there.
> Java has the entire Unicode character set. There are plenty of unused
> symbols. There is no need to overload and confuse the meaning of the
> currently defined operators with overloading.
1. They are already overloaded, as you yourself say below.
2a. Please suggest one of the mentioned Unicode characters to use for adding
two 3D vectors.
2b. Please suggest one for use with 2D vectors.
2c. Tell me how to type that one on a Dvorak keyboard. :/
> To the mathematician, it sounds like a good idea, but in practice,
> e.g. in C++, it primarily becomes a technique for writing
> impenetrable code.
That claim that operator overloading in C++ is mainly a technique that
obfuscates code is in my experience wrong. However, I'd say that at least
80% of all C++ code I have seen is of bad quality, regardless of how it
achieved that quality, which is partly also due to the language itself
being _extremely_ complicated. The price for using a sharp tool is that you
can cut yourself and that is especially true for C++.
Uli
--
Sator Laser GmbH
Geschäftsführer: Michael Wöhrmann, Amtsgericht Hamburg HR B62 932
Martin Gregorie
> Patricia Shanahan wrote:
>> Mark Space wrote:
>>> Chase Preuninger wrote:
>> ...
>>>> 3)Operator Overloading
>>>
>>> Ack! Thpfff! *hurl* No way. Worst idea ever. Leave the operators
>
>> I get very offended by this point of view. I would not choose to use
>> "+" for string concatenation, or ">>" for data input, the sort of thing
>> language writers have been known to do. I just want to use arithmetic
>> operators for arithmetic operations.
>
I'm with you here. I like overloading. Used in moderation it can clarify
what you're doing by making it concise. I remember that the Algol 68 R
graphics package defined a sketch (a drawable but unscaled object),
picture (scaled, ready to output) and overloaded +, so you could write:
sketch disk = circle(0, 0, 30);
sketch frame = rectangle(0, 0, 60, 30);
sketch caption = text(0, -20 "A label);
picture mydrawing = circle + frame + caption;
Works for me, anyway.
>
> As a comparison: as much as I love the preprocessor in C (it was such a
> cool idea in 1980), it's a huge mistake. It suffers from the same sorts
> of abuses (sometimes worse) as operator overloading.
>
Agreed. Some people can make a mess. I knew a programmer who hated curly
brackets, so he always defined:
#define begin {
#define end }
Just so he could write:
int main(int argc, char **argv)
begin
printf("Hello World");
end
--
martin@ | Martin Gregorie
gregorie. |
org | Zappa fan & glider pilot
Martin Gregorie
> PL/I and Ada95 was even more complex than C++. And even though
> they are still used, then they are definitely in decline.
>
Yes, an PL/I is horrible, particularly in the way that it uses exceptions
for EVERYTHING including end of file and has no concept of try/catch
blocks. Sometimes you have to really hunt to find the exception handler
dealing with your problem.
I still think the best of the pre-OO languages was Algol 68.
One (minor) change I'd like to see in Java, though it will never happen,
would be to replace the 'static' keyword with something thats a better
description of its purpose - maybe 'singular' or 'unique' would be better.
'static' is confusing to those of us who write C and are used to 'static'
affecting the variable's lifetime without altering its scope.
Jussi Piitulainen
> Chase Preuninger wrote:
>
>> 2) Anonymous inner classes can use variables other than final ones
>
> That request logically does not make sense, though I agree it is an
> nuisance to create the finals. I explain why at
>
> http://mindprod.com/jgloss/nestedclasses.html#ANONYMOUSVISIBILITY
>
> This piece of Java syntax makes me cringe.
I think it makes perfect sense. (This does not mean that I am asking
for them in Java.)
The obvious implementation would be that the compiler boxes those
local-to-method variables that the inner class instance references,
because they may need to live indefinitely.
Consider code like this, where the method user(Upper) is arbitrary:
int maker() {
int counter = 3;
user(new Upper() { void up() { ++ counter; } })
return counter;
}
It would be compiled as if it had been something like this:
int maker() {
final Box counter = new Box(3);
user(new Upper() {
private final Box b = counter;
void up() { ++ b.contents; }
});
return counter.contents;
}
The Box class would be compiler generated to match the situation at
hand (the contents field is an int). Now the inner class instance may
be live after the maker() call has returned, but that is not a
problem: instead of the forgotten stack frame it refers to the box
that still lives in the heap like any other object.
The programmer can write the latter code now. They need to write the
Box class, too, of course, so there would be a few more lines.
(No, I'm not asking for Java to do this. I'm only saying that if it
wanted, it could. I think.)
Jussi Piitulainen
> Jussi Piitulainen writes:
> >>>2) Anonymous inner classes can use variables other than final ones
>
> was an effort undertaken to /remove/ it from the implementation:
>
> »Guy Steele wrote:
>
> Actually, the prototype implementation *did* allow
> non-final variables to be referenced from within inner
> classes. There was an outcry from *users*, complaining
> that they did not want this!«
>
> http://madbean.com/2003/mb2003-49/
Amusing. Thanks. Yes, Steele should know this very well. I learnt to
think this way when I read about Scheme implementation techniques, and
Steele was one of the original perpetrators.
Lew
> One (minor) change I'd like to see in Java, though it will never happen,
> would be to replace the 'static' keyword with something thats a better
> description of its purpose - maybe 'singular' or 'unique' would be better.
> 'static' is confusing to those of us who write C and are used to 'static'
> affecting the variable's lifetime without altering its scope.
Why should Java be written in terms of C, or any other language? Why
shouldn't Java keywords appeal to former FORTRAN programmers? What makes C so
special that a different language should coddle people who learned it, and
not, say, COBOL?
--
Lew
Lew
> On Mon, 14 Apr 2008 15:54:08 -0700, Mark Space
> <mark...@sbc.global.net> wrote, quoted or indirectly quoted someone
> who said :
>
>>> 1)Allow static inside of inner classes
>> This I don't see the value of. How would this be different than simply
>> declaring a static field in the outer class?
>
> It would restrict the scope to the inner class. It is confusing to
> have a variable declared at a broader scope than it is actually used.
>
> It is mildly wicked for the same reason global variables are wicked.
But the inner class, by being an inner class, is already so tightly coupled to
the outer class, and in certain ways to each particular instance of the outer
class, that comparing this scenario to global variables is specious and
disingenuous.
What confuses me about statics in inner classes is that I wonder if they
shouldn't be scoped to the outer instance. Ridiculous that is, but an inner
class really only lives to help out individual outer-class objects, not the
whole class.
If you need nested classes with static variables and methods then don't make
them inner classes. Then you obviate even the "mild wickedness" of which you
moan.
Static variables themselves are mildly wicked in the first place for the same
reason global variables are wicked.
--
Lew
Andreas Leitgeb
> 3)Operator Overloading
I wouldn't really propose it as free as in C++, but I'd
very much like it, if Java were to overload the arithmetic
operators specifically to BigDecimal and BigInteger, and
also sensible variants with different-typed arguments, like
adding 1, 1L, 1.0 or 1.0f to a BigDecimal, or just the
former two of them to a BigInteger all by use of + operator.
While free use of operator overloading as in C++ is
obviously too sharp a tool for most Java-programmers'
taste, allowing it for well selected standard Java
classes doesn't appear to me to have that downside.
Mark Space
> Given the capabilities of modern IDEs, I don't think it should be up to
> the programmer to look for overloaded operators. An IDE could use a
> different color for overloaded operators than for language-defined
> operators, and a quick option to display the declaration.
Oh you *want* operator overloading? Oh no, I don't agree. Use C++ if
you must overload(*), we have a language that does that already. Your
IDE will already correctly syntax high-light C++ too. Why re-invent the
wheel?
Java has a nice interface for calling external libraries that you can
maintain in C++.
(*) Or some other language. I just looked up a list on Wikipedia. Hey!
Perl 6 has operator overloading! There's a great language to maintain!
I think they threw in the kitchen sink for you too. ;) And some web
programmer said it was really fast! Or use ALGOL! Or Fortran 90! or ...
you get the idea. There are lots of options if you must have operator
overloading. Please don't mess up Java, I like it the way it is.
Mark Thornton
> On Mon, 14 Apr 2008 15:14:03 -0700 (PDT), Chase Preuninger
> <chasepr...@gmail.com> wrote, quoted or indirectly quoted someone
> who said :
>
>> 3)Operator Overloading
>
> I could have strangled Stroustrup and his overloading of the shift
> operators in C++ to do I/O. Java has the entire Unicode character
> set. There are plenty of unused symbols. There is no need to overload
> and confuse the meaning of the currently defined operators with
> overloading.
>
> I would like however to define new operators in Java, just as you can
> in Forth, but not overloading the primitive operators, using symbols
> like Circle Plus.
>
> I find even Java's overload of + for both addition and concatenation
> infuriating. see
> http://mindprod.com/jgloss/gotchas.html#CONCATENATION
>
> To the mathematician, it sounds like a good idea, but in practice,
> e.g. in C++, it primarily becomes a technique for writing
> impenetrable code.
It would be quite proper to overload + for Complex and interval
arithmetic in addition to the existing byte, short, char, int, long,
float and double.
Mark Thornton
Mark Thornton
> Patricia Shanahan wrote:
>
>> Given the capabilities of modern IDEs, I don't think it should be up to
>> the programmer to look for overloaded operators. An IDE could use a
>> different color for overloaded operators than for language-defined
>> operators, and a quick option to display the declaration.
>
> Oh you *want* operator overloading? Oh no, I don't agree. Use C++ if
> you must overload(*), we have a language that does that already. Your
> IDE will already correctly syntax high-light C++ too. Why re-invent the
> wheel?
>
Perhaps because we like other features of Java and dislike some of C++.
The problem with operator overloading is what happens when used by non
mathematicians.
Mark Thornton
Eric Sosman
> On Mon, 14 Apr 2008 15:54:08 -0700, Mark Space
> <mark...@sbc.global.net> wrote, quoted or indirectly quoted someone
> who said :
>
>>> 1)Allow static inside of inner classes
>> This I don't see the value of. How would this be different than simply
>> declaring a static field in the outer class?
>
> It would restrict the scope to the inner class. It is confusing to
> have a variable declared at a broader scope than it is actually used.
Since `static' has nothing to do with scope (this is
Java, not C), I don't see how a scope restriction would
arise.
Of course, as long as we're changing the language we
could change what `static' means at the same time ...
"It's not a new C standard without a new meaning for
the keyword static." -- Peter Seebach
Martin Gregorie
I'm not saying it should be written in terms of any other language, though
it has obvious C antecedents in addition to static - such as &&, || and
the 'main' method.
My objection to Java's use of static is primarily it doesn't really do
what it says. Something else, such as 'singleton' would be more
descriptive. However, I'm not holding my breath for this suggestion to be
implemented: its only intended as a minor innerlekchewal hand grenade.
Arne Vajhøj
> On Mon, 14 Apr 2008 22:36:39 -0400, Arne Vajhøj <ar...@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
>> Non ASCII operators would create tons of problems for
>> primitive development environments.
>
> Good. :-) That would discourage frivolous use, and would encourage
> proper tools for writing international code.
I strongly disagree.
It is a good thing to be able to write Java code in
notepad or vi if necessary.
Arne
Arne Vajhøj
> On Mon, 14 Apr 2008 22:38:18 -0400, Arne Vajhøj wrote:
>> PL/I and Ada95 was even more complex than C++. And even though
>> they are still used, then they are definitely in decline.
>>
> Yes, an PL/I is horrible, particularly in the way that it uses exceptions
> for EVERYTHING including end of file and has no concept of try/catch
> blocks. Sometimes you have to really hunt to find the exception handler
> dealing with your problem.
>
> I still think the best of the pre-OO languages was Algol 68.
Modula-2 looked rather nice also.
Arne
Arne Vajhøj
> Lew wrote:
>> Chase Preuninger wrote:
> ...
>>> 3)Operator Overloading
>>
>> of these "features", and that they are all features that allow for
>> looser coding, but risk more difficulty maintaining code. This is a
>> priority inversion.
>
> However, the combination of a very limited set of primitive arithmetic
> types and the lack of operator overloading also risks increasing the
> difficulty of code maintenance - or forces people to avoid Java for
> anything that has non-trivial arithmetic expressions in any types other
> than the Java numeric primitives.
Operator overloading is very rarely needed. Basically only when you
create custom numeric types. But in that case it really makes
the code much nicer.
So we have two opposite requirements: make custom numeric types
easier or keep the language simple.
At least if they added operators for BigInteger, BigDecimal and Complex
then I would prioritize the simpleness.
But I can understand if people doing numerical stuff has different
priorities.
Arne
Arne Vajhøj
It should not.
But I agree with Martin that static is not so great a word.
The english meaning and its Java meaning are not that close.
Nut it is a rather pointless discussion, because it will
never change.
All C++, Java and C# programmers know what static is.
Arne
Mark Space
> At least if they added operators for BigInteger, BigDecimal and Complex
> then I would prioritize the simpleness.
>
> But I can understand if people doing numerical stuff has different
> priorities.
I'd like to see some kind of specialized language that compiles to
.class files, then use Java for the mundane things like networking, web,
SQL and plain IO.
That would be the best of both worlds, imo. But not trying to import
every grammar under the sun into Java, please never that.
Here's a MATLAB product that compiles to Java .class files, btw.
<http://www.mathworks.com/products/javabuilder/>
This seems to me to be a more useful direction.
Lasse Reichstein Nielsen
> My objection to Java's use of static is primarily it doesn't really do
> what it says.
Sure it does :)
Or rather, what do you think it says it does?
A field, method or class defined without "static" lives in instances
of the class it is defined in. Which object it belongs to, i.e., how
a reference to it is resolved, depends on runtime information. It is dynamic.
A field, method or class defined as static exists at the class level.
A reference is resolved at compile time. I.e., it is static.
It all depends on what you think "static" means.
> Something else, such as 'singleton' would be more descriptive.
Not really. Singleton is a pattern (some would say an anti-pattern,
I'd say it's just a degenerate enum). I.e., it is a recipe for
achieving a specific goal using object oriented modelling.
A traditional singleton will not allow you to change the
singleton instance. A (non-final) static field, would.
/L
--
Lasse Reichstein Nielsen - l...@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Hendrik Maryns
innerlekchewal
Nice, took me a while to figure it out, but then I made this:
http://en.wiktionary.org/wiki/innerlekchewal. I took the freedom to
correct the spelling error.
:-) H.
--
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
Lew
> Martin Gregorie schreef:
>
> innerlekchewal
>
> Nice, took me a while to figure it out, but then I made this:
> http://en.wiktionary.org/wiki/innerlekchewal. I took the freedom to
> correct the spelling error.
Shouldn't a word be in use by more than one person in order to merit inclusion
in the dictionary?
--
Lew
Wojtek
> sketch disk = circle(0, 0, 30);
> sketch frame = rectangle(0, 0, 60, 30);
> sketch caption = text(0, -20 "A label);
> picture mydrawing = circle + frame + caption;
>
> Works for me, anyway.
Masive confustion here.
picture mydrawing.place(circle).place(frame).place(caption);
Makes more sense. Well to me anyways.
I absolutley HATE operator overloading. Because the programmer can make
any symbol do any arbitrary thing. Yes, yes, there are guidelines.
Which every programmer always follows. Right? Right?
So someone is able to write your example as:
picture mydrawing = circle * frame * caption;
picture mydrawing = circle >> frame >> caption;
picture mydrawing = circle << frame << caption;
picture mydrawing = circle \ frame \ caption;
picture mydrawing = circle ^ frame ^ caption;
The only way to figure out what the operator is doing, is to read the
source code of the object.
And yes, a Java programmer can mis-name the methods. But that would be
a deliberate attempt at confusion.
Whereas some of my examples look reasonable.
--
Wojtek :-)
Martin Gregorie
> Martin Gregorie <mar...@see.sig.for.address> writes:
>
>> My objection to Java's use of static is primarily it doesn't really do
>> what it says.
>
> Sure it does :)
> Or rather, what do you think it says it does?
>
I'm referring to static variables, not other uses which more or less do
what they say.
The problem is that declaring a variable as 'static' doesn't really
indicate that its common to all instances of the declaring class as well
as containing a persistent value.
The same argument applies to C, where 'persistent' would be a better
modifier than 'static', because thats really what 'static' means in that
language.
In Java 'static' could usefully be replaced by 'singular' or 'common' to
indicate that the variable is accessible from several class instances.
I think this is something that all language designers have tripped over:
IIRC in Algol 60 the modifier was 'own', which is really obtuse.
Arne Vajhøj
> Arne Vajhøj wrote:
>> At least if they added operators for BigInteger, BigDecimal and Complex
>> then I would prioritize the simpleness.
>>
>> But I can understand if people doing numerical stuff has different
>> priorities.
>
>
> I'd like to see some kind of specialized language that compiles to
> .class files, then use Java for the mundane things like networking, web,
> SQL and plain IO.
>
> That would be the best of both worlds, imo. But not trying to import
> every grammar under the sun into Java, please never that.
There are plenty of languages that can be compiled to Java byte code.
Ada, Python etc.
I believe several of them support operator overload.
And they can use Java classes.
So it is already here.
Arne
Mark Space
> Mark Space wrote:
>> I'd like to see some kind of specialized language that compiles to
>> .class files, then use Java for the mundane things like networking,
>> web, SQL and plain IO.
>>
>> That would be the best of both worlds, imo. But not trying to import
>> every grammar under the sun into Java, please never that.
>
> There are plenty of languages that can be compiled to Java byte code.
>
> Ada, Python etc.
>
I'd consider those general purpose languages. What I mean is a family
of languages for specialized tasks that Java doesn't handle well.
Numerical computation might be one. Certain types of graphical
manipulation or parsing might be others.
I'm just sort of speculating here, no realy plan or idea what, if
anything is needed.
Arne Vajhøj
Well - Fortran was a general purpose language many years ago.
Is Fortress (http://projectfortress.sun.com/Projects/Community) closer
to what you are think of ?
Arne
Mark Space
>
> Well - Fortran was a general purpose language many years ago.
>
> Is Fortress (http://projectfortress.sun.com/Projects/Community) closer
> to what you are think of ?
That just appears to be a general purpose programming language, with
certain features added.
Something like this would consider specialized: