Argument scope

Discussion in 'Java' started by Stefan Ram, Dec 2, 2010.

  1. Stefan Ram

    Stefan Ram Guest

    Here is an idea for a new scope in Java (could be
    used in other languages as well):

    void fill
    ( final int color
    { final int RED = 1;
    final int GREEN = 2;
    final int BLUE = 3; })
    { /* ... */ }

    Now one can call this as, for example:

    fill( GREEN );

    But one does not need to write

    fill( Class.GREEN );

    or so anymore.

    The scope of the identifier »GREEN« is only the
    argument expression corresponding to the parameter
    »color«. So GREEN is not recognized here:

    final int i = GREEN; fill( i ); /* not supported */

    If »Beta« is an interface, one can also write:

    void fill( final int color import Beta ){ /* ... */ }

    , to »import« the constants of the interface Beta for
    this purpose.

    Or, we could have an import for Enum types:

    void test( final enum Day import ){ /* ... */ }

    , so that one then can write

    test( MONDAY )

    instead of

    test( Day.MONDAY )

    .
    Stefan Ram, Dec 2, 2010
    #1
    1. Advertising

  2. Stefan Ram

    Tom Anderson Guest

    On Thu, 2 Dec 2010, Stefan Ram wrote:

    > Here is an idea for a new scope in Java (could be
    > used in other languages as well):
    >
    > void fill
    > ( final int color
    > { final int RED = 1;
    > final int GREEN = 2;
    > final int BLUE = 3; })
    > { /* ... */ }
    >
    > Now one can call this as, for example:
    >
    > fill( GREEN );
    >
    > But one does not need to write
    >
    > fill( Class.GREEN );
    >
    > or so anymore.


    I'd quite like that. Ages ago, i had the idea of being able to write:

    class Paintbucket {
    public static final int GREEN = 1;
    public void fill(int colour) {...}
    }

    Paintbucket p;
    p.fill(.GREEN);
    // ^ leading dot indicates use of receiver scope

    Static imports have made both our ideas somewhat redundant, though.

    I also want a SmallTalk-inspired 'call this method on the same object as
    the last statement' construct, which i'd also do with a leading dot:

    BufferedWriter invoiceWriter;
    invoiceWriter.writer(total);
    ..newLine();
    ..write(tax);
    ..newLine();

    tom

    --
    Remember when we said there was no future? Well, this is it.
    Tom Anderson, Dec 2, 2010
    #2
    1. Advertising

  3. Stefan Ram

    Arne Vajhøj Guest

    On 02-12-2010 01:42, Stefan Ram wrote:
    > Here is an idea for a new scope in Java (could be
    > used in other languages as well):
    >
    > void fill
    > ( final int color
    > { final int RED = 1;
    > final int GREEN = 2;
    > final int BLUE = 3; })
    > { /* ... */ }
    >
    > Now one can call this as, for example:
    >
    > fill( GREEN );
    >
    > But one does not need to write
    >
    > fill( Class.GREEN );
    >
    > or so anymore.
    >
    > The scope of the identifier »GREEN« is only the
    > argument expression corresponding to the parameter
    > »color«. So GREEN is not recognized here:
    >
    > final int i = GREEN; fill( i ); /* not supported */
    >
    > If »Beta« is an interface, one can also write:
    >
    > void fill( final int color import Beta ){ /* ... */ }
    >
    > , to »import« the constants of the interface Beta for
    > this purpose.
    >
    > Or, we could have an import for Enum types:
    >
    > void test( final enum Day import ){ /* ... */ }
    >
    > , so that one then can write
    >
    > test( MONDAY )
    >
    > instead of
    >
    > test( Day.MONDAY )


    There are actually two questions:
    1) is this a feature that is useful?
    2) is this feature so useful that it is worth adding
    to the complexity of the language?

    I would tend to say YES and NO.

    Arne
    Arne Vajhøj, Dec 2, 2010
    #3
  4. On Thu, 02 Dec 2010 21:39:59 +0000, Tom Anderson wrote:

    > I also want a SmallTalk-inspired 'call this method on the same object as
    > the last statement' construct, which i'd also do with a leading dot:
    >
    > BufferedWriter invoiceWriter;
    > invoiceWriter.writer(total);
    > .newLine();
    > .write(tax);
    > .newLine();


    Another case where Clojure comes to the rescue:

    (with-open [wr (BufferedWriter. source)]
    (doto wr
    (.write total)
    (.newLine)
    (.write tax)
    (.newLine)))

    It even has the same dot-method syntax. But Lisp parenthesization, so
    (.write tax) instead of .write(tax).

    As you can see, Clojure also has a handy shortcut for

    BufferedWriter wr = new BufferedWriter(...);
    try {
    ...
    } finally {
    wr.close();
    }

    and indeed it's easy to make a (with-open ...) like construct to scope
    and release resources in general. It's like having C++'s RAII back, only
    without the icky rest of C++. :)
    ClassCastException, Dec 3, 2010
    #4
  5. Stefan Ram

    Lew Guest

    ClassCastException wrote:
    > Another case where Clojure comes to the rescue:
    >
    > (Clojure is the greatest shit since sliced bread)
    >
    > It even has (really groovy shit).
    >
    > As you can see, Clojure also (excels at saving the universe)
    >
    > and indeed it's easy to make (everything beautiful) in general.
    > It's like having C++'s RAII back, only without the icky rest of C++. :)


    But it is not Java.

    Personally, I call "RAII" "RRID".

    My personal "rescue" is just to type the extra lines of code. What, I'm going
    to sprain my finger? At least I don't tar roofs for a living. That's an
    honorable profession - those guys actually work for a living.

    --
    Lew
    Oh, you proselyte, you!
    Lew, Dec 3, 2010
    #5
  6. ClassCastException <> wrote:
    > Another case where Clojure comes to the rescue:


    If lisp-style is the rescue, I'd rather stay captured. :)
    (Just my personal taste, not a judgement on clojure)

    Btw., I do like Tom's suggestion ".addMeToo();", although
    I think there could be cases where it wouldn't be obvious
    to the reader of some code, which reference would really
    be re-used. Also, it might impede insertion of trace-
    logging code, as the following ".something()" would then
    pick up the tracer object, instead.

    If an object were designed for sequences of void method-calling,
    then it should have its methods return "this", instead, so one
    could do ref.callThis().callThat().callAnother(). ...
    Andreas Leitgeb, Dec 3, 2010
    #6
  7. On Fri, 03 Dec 2010 00:03:09 -0500, Lew wrote:

    > ClassCastException wrote:
    >> Another case where Clojure comes to the rescue:
    >>
    >> (Clojure is the greatest shit since sliced bread)
    >>
    >> It even has (really groovy shit).
    >>
    >> As you can see, Clojure also (excels at saving the universe)
    >>
    >> and indeed it's easy to make (everything beautiful) in general. It's
    >> like having C++'s RAII back, only without the icky rest of C++. :)


    Since you wrote the parenthesized expressions above, I take it you're a
    convert? ;-)

    > Personally, I call "RAII" "RRID".


    "Resource Release Is Destruction"?

    > My personal "rescue" is just to type the extra lines of code. What, I'm
    > going to sprain my finger? At least I don't tar roofs for a living.
    > That's an honorable profession - those guys actually work for a living.


    One principle of sound software engineering is to try to specify each
    fact in exactly one place -- cuts down on copy-paste errors and things
    getting out of sync, not to mention saving typing, making code shorter
    and more readable, and avoiding forgetting something the nth time you
    reinvent wheel X.

    Java lets you go pretty far with that with method and object
    abstractions, but without macros and first-class functions it can not
    quite get all the way there. Hence the repeated boilerplate Java code is
    rife with, specifying over and over again how to "grab a stream, process
    it, and then close it in an exception-safe manner" or "iterate over a
    list removing some elements".

    The with-open macro in Clojure addresses the former, however, and higher-
    order functions combined with first-class functions and anonymous lambdas
    take care of the latter. (The expression (remove #(= 0 %) foo) for
    example returns a list that's a copy of foo with all the zeros removed;
    if foo was (0 3 7 0 8) it gives (3 7 8) as its output. Clojure encourages
    copying-with-modification in preference to in-place modification and
    other thread-safe practices, though there are ways to do in-place
    modification and you can even use the mutable java.util collections if
    you really want to.)

    As for how Java it is, it runs on the JVM, compiling to bytecodes; and
    can use everything in Java's class library (except, IIRC, annotations,
    support for which is forthcoming); so one might argue it's 2/3 Java.
    (Others might argue that it's Java++. :))
    ClassCastException, Dec 3, 2010
    #7
  8. On Fri, 03 Dec 2010 08:16:56 +0000, Andreas Leitgeb wrote:

    > Btw., I do like Tom's suggestion ".addMeToo();", although
    > I think there could be cases where it wouldn't be obvious to the reader
    > of some code, which reference would really be re-used.


    Clojure solves that too. :)

    (doto x
    (y z)
    (w foo))

    operates everything on x. If there's more than one possible referent
    there'll be more dotos, and then you know to pay attention to the
    parenthesis nesting level.

    > Also, it might impede insertion of trace- logging code, as the
    > following ".something()" would then pick up the tracer object, instead.


    Decorator pattern to the rescue? Wrap the object itself in a decorator
    that logs some of the method calls, then punts to the wrapped object.
    Then the decorator grabs the .something() as well.

    (Clojure version would be to wrap the function whose uses you want to
    log, e.g. (def f #(binding [*out* log-out] (println "f" %1 %2) (f %1 %
    2))) which will append "f x y\n" to log-out on the way to calling the
    original f if you now call (f x y).

    > If an object were designed for sequences of void method-calling, then
    > it should have its methods return "this", instead, so one could do
    > ref.callThis().callThat().callAnother(). ...


    I think there's a pattern name for this, too, and it's commonly employed
    with factory objects.

    FooFactory.withThis().withExtraSauce(42).withThat("quux").create();

    and the like.
    ClassCastException, Dec 3, 2010
    #8
  9. Stefan Ram

    Stefan Ram Guest

    Stefan Ram, Dec 3, 2010
    #9
  10. Stefan Ram

    Lew Guest

    Lew wrote:
    >> ClassCastException wrote:
    >>> Another case where Clojure comes to the rescue:
    >>>
    >>> (Clojure is the greatest shit since sliced bread)
    >>>
    >>> It even has (really groovy shit).
    >>>
    >>> As you can see, Clojure also (excels at saving the universe)
    >>>
    >>> and indeed it's easy to make (everything beautiful) in general. It's
    >>> like having C++'s RAII back, only without the icky rest of C++. :)


    ClassCastException wrote:
    > Since you wrote the parenthesized expressions above, I take it you're a
    > convert? ;-)


    I was making fun of you. I expect to find you in an airport dressed in
    saffron robes selling flowers to support Clojure.

    Don't get me wrong - I find Krishna devotees to a person to be gentle,
    sincere, deeply spiritual people.

    Not so programming-language proselytes who pitch their off-topic spiel at the
    merest hint of a whiff of a waft of aroma of possible relevance.

    I do find it amusing, though.

    --
    Lew
    Lew, Dec 4, 2010
    #10
  11. On Fri, 03 Dec 2010 19:28:47 -0500, Lew wrote:

    > Lew wrote:
    >>> ClassCastException wrote:
    >>>> Another case where Clojure comes to the rescue:
    >>>>
    >>>> (Clojure is the greatest shit since sliced bread)
    >>>>
    >>>> It even has (really groovy shit).
    >>>>
    >>>> As you can see, Clojure also (excels at saving the universe)
    >>>>
    >>>> and indeed it's easy to make (everything beautiful) in general. It's
    >>>> like having C++'s RAII back, only without the icky rest of C++. :)

    >
    > ClassCastException wrote:
    >> Since you wrote the parenthesized expressions above, I take it you're a
    >> convert? ;-)

    >
    > I was making fun of you. I expect to find you in an airport dressed in
    > saffron robes selling flowers to support Clojure.
    >
    > Don't get me wrong - I find Krishna devotees to a person to be gentle,
    > sincere, deeply spiritual people.
    >
    > Not so programming-language proselytes who pitch their off-topic spiel
    > at the merest hint of a whiff of a waft of aroma of possible relevance.
    >
    > I do find it amusing, though.


    Don't I get some bonus points for dissing C++?
    ClassCastException, Dec 4, 2010
    #11
  12. Stefan Ram

    Lew Guest

    ClassCastException wrote:
    > Don't I get some bonus points for dissing C++?


    Of course. You even get bonus points for promoting Clojure. I am not against
    the language by any means.

    --
    Lew
    Lew, Dec 4, 2010
    #12
  13. Stefan Ram

    BGB Guest

    On 12/1/2010 11:42 PM, Stefan Ram wrote:
    > Here is an idea for a new scope in Java (could be
    > used in other languages as well):
    >
    > void fill
    > ( final int color
    > { final int RED = 1;
    > final int GREEN = 2;
    > final int BLUE = 3; })
    > { /* ... */ }
    >
    > Now one can call this as, for example:
    >
    > fill( GREEN );
    >
    > But one does not need to write
    >
    > fill( Class.GREEN );
    >
    > or so anymore.
    >
    > The scope of the identifier »GREEN« is only the
    > argument expression corresponding to the parameter
    > »color«. So GREEN is not recognized here:
    >
    > final int i = GREEN; fill( i ); /* not supported */
    >
    > If »Beta« is an interface, one can also write:
    >
    > void fill( final int color import Beta ){ /* ... */ }
    >
    > , to »import« the constants of the interface Beta for
    > this purpose.
    >
    > Or, we could have an import for Enum types:
    >
    > void test( final enum Day import ){ /* ... */ }
    >
    > , so that one then can write
    >
    > test( MONDAY )
    >
    > instead of
    >
    > test( Day.MONDAY )
    >
    > .
    >


    in certain other languages, this is closer to the default behavior for
    enum...

    enum Color { RED=1, GREEN=2, BLUE=3 };

    Color x;
    x=RED;

    with the compiler essentially figuring out what was meant by this
    (nevermind a few semantic subtleties here...).



    now, it may come as a bit if controversy here, but there are many common
    tasks which prove a bit more awkward in Java than in its main
    competitors (C, C++, C#, ...).

    ability to most easily and efficiently express ideas is not one of the
    high points of the language.

    not that it is all that bad, but in a few ways they took the "thow the
    baby out with the bathwater" strategy to language design (IOW, throwing
    out many language features deemed "complicated" or "unsafe" at the cost
    of making the language more awkward to use), and then tried apparently
    to build elaborate class libraries to try to mask over some of the
    weaknesses in the core language.

    now, in everything there are costs and benefits...


    yes, C is a little crufty, and many practices traditionally associated
    with it are a subject of criticism (such as aversion to GC, or
    overuse/abuse of pointer arithmetic, or for that matter coding practices
    that don't scale well). these are not, however, inherent in the language.

    yes, C++ is absurdly complex...

    and yes, C# is mostly just a Java knock-off with some more C++ style
    syntax and semantics reintroduced (nevermind traditional C-style
    features re-introduced in different ways, such as via 'delegate' and 'ref').


    I am torn at times...

    I like the power of expression and fine level of control of C.
    I like some of the added abstraction over the system of Java (and VM
    architecture has some merits, although I disagree some with the
    traditional overall architecture of the JVM).

    I personally feel C# is a well designed language, but admittedly, I have
    less warm and fuzzy feelings about .NET in general. (for my uses, .NET
    was theoretically better, but I suspect more practically would have been
    a worse investment).

    ok... I am not so much of a fan of C++ though, its only real merit being
    that it is close to C and has a good feature-set, but is at the same
    time also a complex mess of cruft which I would rather not bother with
    so much.


    I guess this is why, although probably in the end somewhat pointless, I
    tend to end up implementing my own compilers, languages and pieces of VM
    technology.

    even if implementations are only half-assed, at least I can do them my way.


    although, I also tend to prefer trying for compatibility and standards
    conformance where possible/reasonable, as in the end, the world already
    has too many "YetAnotherLanguage" running on "YetAnotherVM" setups...

    little is gained by more of the same...

    hence, the current use of JVM architecture as a base.


    and even if in the end all this is pointless and no one cares or
    benefits, really why does this need to matter?


    or such...
    BGB, Dec 4, 2010
    #13
  14. Stefan Ram

    BGB Guest

    On 12/3/2010 5:28 PM, Lew wrote:
    > Lew wrote:
    >>> ClassCastException wrote:
    >>>> Another case where Clojure comes to the rescue:
    >>>>
    >>>> (Clojure is the greatest shit since sliced bread)
    >>>>
    >>>> It even has (really groovy shit).
    >>>>
    >>>> As you can see, Clojure also (excels at saving the universe)
    >>>>
    >>>> and indeed it's easy to make (everything beautiful) in general. It's
    >>>> like having C++'s RAII back, only without the icky rest of C++. :)

    >
    > ClassCastException wrote:
    >> Since you wrote the parenthesized expressions above, I take it you're a
    >> convert? ;-)

    >
    > I was making fun of you. I expect to find you in an airport dressed in
    > saffron robes selling flowers to support Clojure.
    >
    > Don't get me wrong - I find Krishna devotees to a person to be gentle,
    > sincere, deeply spiritual people.
    >
    > Not so programming-language proselytes who pitch their off-topic spiel
    > at the merest hint of a whiff of a waft of aroma of possible relevance.
    >
    > I do find it amusing, though.
    >



    hmm, yes, maybe I can be accused of this, grr...

    although, admittedly, I don't believe as much in some "one true
    language" so much as in the ideal of knocking down some of the walls
    between them, many of which I feel are likely artificial and deliberate
    (and others due to laziness or disinterest...).

    "why should my new fancy language and VM have any reason to interop with
    archaic C cruft?", or, "this language is so great that it doesn't need
    interop, only everyone to see its greatness and adopt it as the one true
    language", or, ...

    I really dislike this sort of thinking (well, among other things, ...).


    well, and trying to find decent ways to battle other long-lived problems
    (namely, trying to find solutions which hopefully don't introduce more
    problems than they solve).


    the ideal solution may well be more in what things one doesn't see.

    or such...
    BGB, Dec 4, 2010
    #14
  15. Stefan Ram

    Tom Anderson Guest

    On Fri, 3 Dec 2010, Andreas Leitgeb wrote:

    > ClassCastException <> wrote:
    >> Another case where Clojure comes to the rescue:

    >
    > If lisp-style is the rescue, I'd rather stay captured. :) (Just my
    > personal taste, not a judgement on clojure)
    >
    > Btw., I do like Tom's suggestion ".addMeToo();", although I think there
    > could be cases where it wouldn't be obvious to the reader of some code,
    > which reference would really be re-used.


    That's my main worry about it. Perhaps we should instead steal something
    from Delphi:

    BufferedWriter out;
    with (out) {
    write("foo");
    newLine();
    write("bar");
    newLine();
    }

    Which basically redefines the implicit target of invocations inside its
    scope from 'this' to something else. It's a little wordier.

    Going back to the original idea, perhaps you could mark the receiver:

    StreamHolder holder;
    [holder.getBufferedWriter()].write("foo"); .newLine(); .write("bar"); .newLine();

    Although if the rule is otherwise that it's the leftmost term of the
    top-level expression (not sure i'm expressing that right), then you could
    just use normal parentheses there.

    > Also, it might impede insertion of trace- logging code, as the following
    > ".something()" would then pick up the tracer object, instead.


    True. The 'with' form avoids that too. But then i think this notation is
    intended for small runs of tightly-coupled operations, where you probably
    wouldn't want to log in between them. Still, it would be bound to trip
    someone up sooner rather than later.

    > If an object were designed for sequences of void method-calling, then it
    > should have its methods return "this", instead, so one could do
    > ref.callThis().callThat().callAnother(). ...


    A construction which i hate with a burning passion. Why on earth does the
    append method of a StringBuffer return a StringBuffer? In what sense does
    that method evaluate to a StringBuffer? How does that have any semantic
    meaning? It's a perversion of the normal rules of method design to
    accomodate a particular usage, which is unacceptably awful. The syntaxes
    were kicking around are ways of enabling that compact style without
    needing to pervert the design of code.

    tom

    --
    Now I am thoroughly confused. -- Colin Brace sums up RT3090 support
    in Linux
    Tom Anderson, Dec 5, 2010
    #15
  16. Stefan Ram

    Stefan Ram Guest

    Tom Anderson <> writes:
    >Although if the rule is otherwise that it's the leftmost term of the
    >top-level expression (not sure i'm expressing that right)


    This (if I understood it correctly) is often called
    »leftmost outermost«, as in:

    http://google.to/search?q="leftmost outermost redex"

    .
    Stefan Ram, Dec 5, 2010
    #16
  17. Stefan Ram

    Lew Guest

    Tom Anderson wrote:
    > Perhaps we should instead steal something from Delphi:
    >
    > BufferedWriter out;
    > with (out) {
    > write("foo");
    > newLine();
    > write("bar");
    > newLine();
    > }
    >
    > Which basically redefines the implicit target of invocations inside its
    > scope from 'this' to something else. It's a little wordier.


    This is a great idea. It's no wordier than anything else in Java. OTOH it's
    not backward compatible.

    So the question becomes - how much value does this syntactic sugar provide,
    and is it worth a language change? Is it worth two (or three) extra lines of
    code and a language change to save a net negative fifteen characters?

    --
    Lew
    Lew, Dec 5, 2010
    #17
  18. Stefan Ram

    BGB Guest

    On 12/5/2010 5:28 AM, Tom Anderson wrote:
    > On Fri, 3 Dec 2010, Andreas Leitgeb wrote:
    >
    >> ClassCastException <> wrote:
    >>> Another case where Clojure comes to the rescue:

    >>
    >> If lisp-style is the rescue, I'd rather stay captured. :) (Just my
    >> personal taste, not a judgement on clojure)
    >>
    >> Btw., I do like Tom's suggestion ".addMeToo();", although I think
    >> there could be cases where it wouldn't be obvious to the reader of
    >> some code, which reference would really be re-used.

    >
    > That's my main worry about it. Perhaps we should instead steal something
    > from Delphi:
    >
    > BufferedWriter out;
    > with (out) {
    > write("foo");
    > newLine();
    > write("bar");
    > newLine();
    > }
    >
    > Which basically redefines the implicit target of invocations inside its
    > scope from 'this' to something else. It's a little wordier.
    >


    the above syntax I think exists in several other languages, such as
    JavaScript and C# IIRC.

    in my thinking, access rights should be preserved, so "with()" should
    still not give access to any private or protected fields, ... (but, then
    again I guess a proper JVM would enforce this restriction anyways).


    admittedly, I would also like get/set support and structs, ... (if/when
    I get around to finishing my Java compiler, I may support these as
    language extensions...). at present it is a lower priority due to both
    using standard compilers, and also having several other languages I also
    make use of (my VM core also handles C and BGBScript at present).


    get/set (AKA: properties) would just be syntax sugar, and probably with
    a defined mapping to actual methods (probably "getX()"/"setX()" or
    "get_x()"/"set_x()").

    structs are still under some debate, mostly WRT how exactly to represent
    and handle them in the VM (several related mechanisms were implemented).
    I am now leaning towards handling them similar to normal Objects, with
    them differing mostly in that they will use pass-by-value semantics.

    likely implementation (current idle thinking):
    they will be implemented as classes, which will be marked final and
    likely inherit from "bgb/vm/Struct" (or "java/lang/struct", but this is
    non-standard and "java/lang" is Sun/Oracle turf...);
    potentially, semantics could be handled explicitly in the bytecode
    (allowing potential standard-JVM compatibility).

    hence, Struct would contain several special/magic methods:
    "Z_clone()", copy struct;
    "Z_set()", assign struct (copies all fields into a target struct of same
    type);
    "Z_free()", called when struct goes out of scope (likely no-op in
    standard JVM).

    (or "_Clone()", "_Set()", ... it is an open issue).


    issues:
    the above design would allow plain Java code (IOW: a standard compiler)
    to access structs (possibly good), but plain Java would not necessarily
    preserve correct semantics (bad).

    a general-purpose "Z_clone()" and "Z_set()" would be expensive in a
    standard JVM (would likely need to use reflection to implement them),
    but are the most efficient for my VM (which would handle them
    internally). struct types could overload these methods (to allow more
    efficient handling by a standard JVM), but mine would likely ignore them
    in this case (extending "Struct" will tell the VM that they are structs).

    likely methods will be passed copies of structs (copy-in-caller), and
    the called method will themselves be responsible for freeing them.

    ....


    > Going back to the original idea, perhaps you could mark the receiver:
    >
    > StreamHolder holder;
    > [holder.getBufferedWriter()].write("foo"); .newLine(); .write("bar");
    > .newLine();
    >
    > Although if the rule is otherwise that it's the leftmost term of the
    > top-level expression (not sure i'm expressing that right), then you
    > could just use normal parentheses there.
    >


    I don't like the above so much...


    >> Also, it might impede insertion of trace- logging code, as the
    >> following ".something()" would then pick up the tracer object, instead.

    >
    > True. The 'with' form avoids that too. But then i think this notation is
    > intended for small runs of tightly-coupled operations, where you
    > probably wouldn't want to log in between them. Still, it would be bound
    > to trip someone up sooner rather than later.
    >


    yeah...

    I like with() more...


    >> If an object were designed for sequences of void method-calling, then
    >> it should have its methods return "this", instead, so one could do
    >> ref.callThis().callThat().callAnother(). ...

    >
    > A construction which i hate with a burning passion. Why on earth does
    > the append method of a StringBuffer return a StringBuffer? In what sense
    > does that method evaluate to a StringBuffer? How does that have any
    > semantic meaning? It's a perversion of the normal rules of method design
    > to accomodate a particular usage, which is unacceptably awful. The
    > syntaxes were kicking around are ways of enabling that compact style
    > without needing to pervert the design of code.
    >


    possibly, but it is not that terrible/unusual...
    basically, this sort of thing at least allows some vague approximation
    of FP coding styles, where not every task is ideally suited to an
    OO-based design.


    admittedly, I would rather also be able to do some more C-like stuff in
    Java as well, but alas...


    for my uses, I was actually partly considering (as an extension) the
    possibility package-scoped functions (technically, they would likely
    exist inside special "hidden" classes), as well as idle thoughts about
    handling partial classes (which are possible in my VM core, but lack any
    good way to express them either in Java or in the way packages/classes
    are managed).

    technically, as implemented, "java/lang/String" is implemented using the
    same basic mechanism I would use for partial classes, since the class
    needs to exist before running the classloader, which is needed to load
    String, the result being that a stub version of the class is created (by
    the VM), and then the proper class is loaded and forced in on top of it
    (basically, the classes merge at this point).


    or such...
    BGB, Dec 5, 2010
    #18
  19. Stefan Ram

    Lew Guest

    BGB wrote:
    > admittedly, I would also like get/set support and structs, ... (if/when


    What do you mean by "structs"?

    --
    Lew
    Lew, Dec 6, 2010
    #19
  20. "Lew" <> wrote in message
    news:idhr76$j6b$...
    > BGB wrote:
    >> admittedly, I would also like get/set support and structs, ... (if/when

    >
    > What do you mean by "structs"?


    I'd guess it's a C or C++-like struct: an object all of whose fields are
    public. (In C++, that may be a default rather than a uniform rule. I
    honestly don’t recall.)
    Mike Schilling, Dec 6, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Paul Opal
    Replies:
    12
    Views:
    927
    Paul Opal
    Oct 11, 2004
  2. ann
    Replies:
    13
    Views:
    648
    Patricia Shanahan
    Sep 13, 2005
  3. Steven T. Hatton
    Replies:
    9
    Views:
    458
  4. Xah Lee
    Replies:
    0
    Views:
    2,221
    Xah Lee
    Feb 26, 2009
  5. Replies:
    0
    Views:
    155
Loading...

Share This Page