Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #5168 > unrolled thread

Call by Result

Back to article view | Back to comp.lang.java.programmer

Contents

  Call by Result Gene Wirchenko <genew@ocis.net> - 2011-06-09 23:03 -0700
    Re: Call by Result Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-06-10 07:33 +0000
      Re: Call by Result Nigel Wade <nmw-news@ion.le.ac.uk> - 2011-06-10 10:03 +0100
        Re: Call by Result Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-06-10 09:47 +0000
        Re: Call by Result Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-10 08:23 -0300
          Re: Call by Result Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-06-10 13:12 +0000
            Re: Call by Result Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-10 15:44 -0300
              Re: Call by Result Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-06-12 16:29 +0000
                Re: Call by Result Silvio <silvio@moc.com> - 2011-06-12 23:00 +0200
                  Re: Call by Result Silvio <silvio@moc.com> - 2011-06-12 23:06 +0200
                  Re: Call by Result Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-06-14 10:52 +0000
                    Re: Call by Result Silvio <silvio@moc.com> - 2011-06-14 17:13 +0200
                      Re: Call by Result Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-14 17:58 -0300
                        Re: Call by Result Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-06-14 21:18 +0000
                          Re: Call by Result Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-14 20:14 -0300
                            Re: Call by Result Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-15 07:13 -0300
                              Re: Call by Result Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-06-15 12:50 +0000
                                Re: Call by Result Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-15 18:52 -0300
                          Re: Call by Result lewbloch <lewbloch@gmail.com> - 2011-06-15 07:06 -0700
                    Re: Call by Result Michael Wojcik <mwojcik@newsguy.com> - 2011-06-15 21:33 -0400
                      Re: Call by Result Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-06-16 11:03 +0000
                        Re: Call by Result "H.J. Sander Bruggink" <sander.bruggink@uni-due.de> - 2011-06-16 13:09 +0200
                          Re: Call by Result Lewis Bloch <lewisbloch@google.com> - 2011-06-16 06:59 -0700
                            Re: Call by Result "John B. Matthews" <nospam@nospam.invalid> - 2011-06-16 23:14 -0400
          Re: Call by Result Gene Wirchenko <genew@ocis.net> - 2011-06-10 11:31 -0700
            Re: Call by Result Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-12 14:27 -0300
        Re: Call by Result Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-06-10 07:20 -0700
        Re: Call by Result Patricia Shanahan <pats@acm.org> - 2011-06-10 09:30 -0700
          Re: Call by Result Gene Wirchenko <genew@ocis.net> - 2011-06-10 11:44 -0700
      Re: Call by Result Gene Wirchenko <genew@ocis.net> - 2011-06-10 11:26 -0700
        Re: Call by Result Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-06-11 15:07 +0000
          Re: Call by Result Abu Yahya <abu_yahya@invalid.com> - 2011-06-11 23:00 +0530
            Re: Call by Result Martin Gregorie <martin@address-in-sig.invalid> - 2011-06-11 19:36 +0000
              Re: Call by Result Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-06-11 21:06 +0000
                Re: Call by Result Martin Gregorie <martin@address-in-sig.invalid> - 2011-06-12 10:53 +0000
                  Re: Call by Result Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-06-12 09:28 -0700
                    Re: Call by Result Martin Gregorie <martin@address-in-sig.invalid> - 2011-06-12 17:48 +0000
                      Re: Call by Result Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-06-12 13:19 -0700
              Re: Call by Result Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-06-11 15:39 -0700
                Re: Call by Result Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-06-12 11:07 +0000
                  Re: Call by Result markspace <-@.> - 2011-06-12 07:02 -0700
                  Re: Call by Result Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-06-12 09:39 -0700
                    Re: Call by Result Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-06-14 10:29 +0000
                      Re: Call by Result Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-06-14 09:14 -0700
                        Re: Call by Result markspace <-@.> - 2011-06-14 09:21 -0700
                          Re: Call by Result Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-06-14 09:53 -0700
                        Re: Call by Result Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-06-14 09:57 -0700
              Re: Call by Result Gene Wirchenko <genew@ocis.net> - 2011-06-12 21:44 -0700
          Re: Call by Result Gene Wirchenko <genew@ocis.net> - 2011-06-12 21:40 -0700
    Re: Call by Result Patricia Shanahan <pats@acm.org> - 2011-06-10 01:30 -0700
      Re: Call by Result Gene Wirchenko <genew@ocis.net> - 2011-06-10 11:45 -0700
    Re: Call by Result Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-10 07:50 -0400
    Re: Call by Result Silvio <silvio@moc.com> - 2011-06-10 15:35 +0200
    Re: Call by Result Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-06-10 13:56 +0000
    Re: Call by Result Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-06-10 07:22 -0700
      Re: Call by Result Gene Wirchenko <genew@ocis.net> - 2011-06-10 11:56 -0700
      Re: Call by Result Gene Wirchenko <genew@ocis.net> - 2011-06-10 11:57 -0700
        Re: Call by Result Patricia Shanahan <pats@acm.org> - 2011-06-10 13:50 -0700
          Re: Call by Result Gene Wirchenko <genew@ocis.net> - 2011-06-12 21:53 -0700
            Re: Call by Result Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-13 07:20 -0300
              Re: Call by Result Gene Wirchenko <genew@ocis.net> - 2011-06-13 08:08 -0700
        Re: Call by Result Wojtek <nowhere@a.com> - 2011-06-11 16:35 -0700
          Re: Call by Result Martin Gregorie <martin@address-in-sig.invalid> - 2011-06-12 11:05 +0000
          Re: Call by Result Gene Wirchenko <genew@ocis.net> - 2011-06-12 21:56 -0700
            Re: Call by Result Wojtek <nowhere@a.com> - 2011-06-14 00:40 -0700
      Re: Call by Result Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-06-11 21:18 +0000
    Re: Call by Result markspace <-@.> - 2011-06-10 08:43 -0700
    Re: Call by Result RedGrittyBrick <RedGrittyBrick@spamweary.invalid> - 2011-06-10 17:01 +0100
      Re: Call by Result Martin Gregorie <martin@address-in-sig.invalid> - 2011-06-10 16:55 +0000
      Re: Call by Result Gene Wirchenko <genew@ocis.net> - 2011-06-10 11:59 -0700
        Re: Call by Result Wojtek <nowhere@a.com> - 2011-06-11 16:24 -0700
          Re: Call by Result Gene Wirchenko <genew@ocis.net> - 2011-06-12 21:59 -0700
            Re: Call by Result Paul Cager <paul.cager@googlemail.com> - 2011-06-13 07:53 -0700
            Re: Call by Result Wojtek <nowhere@a.com> - 2011-06-14 00:43 -0700
    Re: Call by Result Gene Wirchenko <genew@ocis.net> - 2011-06-10 11:55 -0700
    Re: Call by Result Steven Simpson <ss@domain.invalid> - 2011-06-11 09:09 +0100
    Re: Call by Result Cholo Lennon <chololennon@hotmail.com> - 2011-06-16 11:30 -0300
      Re: Call by Result Paul Cager <paul.cager@googlemail.com> - 2011-06-17 02:38 -0700
        Re: Call by Result Gene Wirchenko <genew@ocis.net> - 2011-06-17 12:06 -0700
      Re: Call by Result lewbloch <lewbloch@gmail.com> - 2011-06-17 06:40 -0700
        Re: Call by Result Cholo Lennon <chololennon@hotmail.com> - 2011-06-17 11:43 -0300

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#5331

Michael Wojcik <mwojcik@newsguy.com> wrote:
> In the Verona of functional languages, the ML family are the Montagues
> to the LISP family's Capulets. Or something like that.

:-)

And to which of these two families is Prolog more related to?
It does make lot of use of expression-matching like the MLs,
but seems to be quite different, still.  A distant cousin?

[toc] | [prev] | [next] | [standalone]

#5332

On 06/16/2011 01:03 PM, Andreas Leitgeb wrote:
> Michael Wojcik<mwojcik@newsguy.com>  wrote:
>> In the Verona of functional languages, the ML family are the Montagues
>> to the LISP family's Capulets. Or something like that.
>
> :-)
>
> And to which of these two families is Prolog more related to?
> It does make lot of use of expression-matching like the MLs,
> but seems to be quite different, still.  A distant cousin?
>

Prolog is not a functional language but a logical language and does not 
use matching but unification.

But all programming languages influence each other, so probably all 
programming languages are distant cousins of all other ones :-).

groente
-- Sander

[toc] | [prev] | [next] | [standalone]

#5333

On Jun 16, 4:09 am, "H.J. Sander Bruggink" <sander.brugg...@uni-
due.de> wrote:
> On 06/16/2011 01:03 PM, Andreas Leitgeb wrote:
>
> > Michael Wojcik<mwoj...@newsguy.com>  wrote:
> >> In the Verona of functional languages, the ML family are the Montagues
> >> to the LISP family's Capulets. Or something like that.
>
> > :-)
>
> > And to which of these two families is Prolog more related to?
> > It does make lot of use of expression-matching like the MLs,
> > but seems to be quite different, still.  A distant cousin?
>
> Prolog is not a functional language but a logical language and does not
> use matching but unification.
>
> But all programming languages influence each other, so probably all
> programming languages are distant cousins of all other ones :-).
>

Real programmers can program in FORTRAN in any language.

--
Lew

[toc] | [prev] | [next] | [standalone]

#5338

In article 
<28d61d42-76c3-4a13-8c81-f65c95ab478d@e17g2000prj.googlegroups.com>,
 Lewis Bloch <lewisbloch@google.com> wrote:

> On Jun 16, 4:09 am, "H.J. Sander Bruggink" <sander.brugg...@uni-
> due.de> wrote:
> > On 06/16/2011 01:03 PM, Andreas Leitgeb wrote:
> >
> > > Michael Wojcik<mwoj...@newsguy.com>  wrote:
> > >> In the Verona of functional languages, the ML family are the 
> > >> Montagues to the LISP family's Capulets. Or something like that.
> >
> > > :-)
> >
> > > And to which of these two families is Prolog more related to? It 
> > > does make lot of use of expression-matching like the MLs, but 
> > > seems to be quite different, still.  A distant cousin?
> >
> > Prolog is not a functional language but a logical language and does 
> > not use matching but unification.
> >
> > But all programming languages influence each other, so probably all 
> > programming languages are distant cousins of all other ones :-).

There's a nice family tree here: <http://www.levenez.com/lang/>

I can't help but notice that Oak, the progenitor of Java, has six 
influencing languages, rivaled only by Ruby. Hybrid vigor?

<http://en.wikipedia.org/wiki/Heterosis>

> Real programmers can program in FORTRAN in any language.

I recall writing Fortran in Pascal for a time, and then Pascal in Java. 
More recently, an Ada compiler caught me writing Java.

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

[toc] | [prev] | [next] | [standalone]

#5193

On Fri, 10 Jun 2011 08:23:17 -0300, Arved Sandstrom
<asandstrom3minus1@eastlink.ca> wrote:

[snip]

>This is the kind of thing where "purists" will get a bit bloody. Not to

     Let them scream.  I have other comments elsethread.  In short, if
your favourite way of doing things causes me a bunch of extra work to
use, I am liable to not use it.

>teach you or any other respondent here how to suck eggs, but I'll throw
>in, for general edification of a wider audience, the information that
>we've got this problem both because Java has "pass object reference by
>value" and Strings are immutable. Hence the OP's question.

     Nope.  I simply want to call by result.

>Given that, Andreas' #2 is legit (I agree, Nigel, with your concerns
>regarding #1 and #3), and so are the two suggestions you and Patricia
>have put forth.

     I based my answer on #2.

>I'll accept that returning an object containing both the possible
>modified String and a boolean status is OK. I don't much like it,
>however, for two reasons. It's still the use of a return value for
>operation status, and although that's defensible, there's nothing OO
>about it - it's pure imperative programming. And were we to still pursue
>that approach, unfortunately Java has no elegant means for supporting
>it, unlike Haskell Maybe or Scala Option.

     Well, imperative programming does exist, and I use it.

>The failure of Java to cleanly support the previous approach pretty much
>argues, IMHO, for exceptions. And this is, again IMHO, quite pure. It's

     Nope.  Too complicated.

>basically my business to define what I consider to be failures and
>errors. Myself I see absolutely no problem in arguing that a failure to
>work (parse) is a failure. :-) It's certainly an error in the input to
>be parsed. In any case the OP would hardly be asking for an operation
>success status if it wasn't possible for the method to fail.
>
>Another argument for exceptions here is the OP's
>
>if (!DidItWork)
>    // too bad
>
>bit. I have my doubts as to whether the OP's intended error processing
>consists just of a NOOP and a comment. Assuming that it doesn't, and one
>actually wants to do something productive in the error-handling,
>exceptions are the best way to do it.

     Get real!  It is common in examples to have a comment indicating
what would be done when said code is not particularly relevant to the
example.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#5247

On 11-06-10 03:31 PM, Gene Wirchenko wrote:
> On Fri, 10 Jun 2011 08:23:17 -0300, Arved Sandstrom
> <asandstrom3minus1@eastlink.ca> wrote:
> 
> [snip]
> 
>> This is the kind of thing where "purists" will get a bit bloody. Not to
> 
>      Let them scream.  I have other comments elsethread.  In short, if
> your favourite way of doing things causes me a bunch of extra work to
> use, I am liable to not use it.
> 
>> teach you or any other respondent here how to suck eggs, but I'll throw
>> in, for general edification of a wider audience, the information that
>> we've got this problem both because Java has "pass object reference by
>> value" and Strings are immutable. Hence the OP's question.
> 
>      Nope.  I simply want to call by result.

I know what you said you wanted, Gene. The above chunk of mine that you
quoted provides some context, for the use of any readers who might not
be completely up to speed Java-wise, as to what *any* approach would
have to contend with.

Read a bit more carefully. Thanks.

>> Given that, Andreas' #2 is legit (I agree, Nigel, with your concerns
>> regarding #1 and #3), and so are the two suggestions you and Patricia
>> have put forth.
> 
>      I based my answer on #2.
> 
>> I'll accept that returning an object containing both the possible
>> modified String and a boolean status is OK. I don't much like it,
>> however, for two reasons. It's still the use of a return value for
>> operation status, and although that's defensible, there's nothing OO
>> about it - it's pure imperative programming. And were we to still pursue
>> that approach, unfortunately Java has no elegant means for supporting
>> it, unlike Haskell Maybe or Scala Option.
> 
>      Well, imperative programming does exist, and I use it.

So does everyone. A large percentage, maybe even the majority, of Java
code is imperative.

>> The failure of Java to cleanly support the previous approach pretty much
>> argues, IMHO, for exceptions. And this is, again IMHO, quite pure. It's
> 
>      Nope.  Too complicated.

String resultString = null;
try {
    resultString = GetString(stringToBeParsed);
} catch (Exception e) {
    // too bad
}

is more complicated than what you asked for? Go figure.

>> basically my business to define what I consider to be failures and
>> errors. Myself I see absolutely no problem in arguing that a failure to
>> work (parse) is a failure. :-) It's certainly an error in the input to
>> be parsed. In any case the OP would hardly be asking for an operation
>> success status if it wasn't possible for the method to fail.
>>
>> Another argument for exceptions here is the OP's
>>
>> if (!DidItWork)
>>    // too bad
>>
>> bit. I have my doubts as to whether the OP's intended error processing
>> consists just of a NOOP and a comment. Assuming that it doesn't, and one
>> actually wants to do something productive in the error-handling,
>> exceptions are the best way to do it.
> 
>      Get real!  It is common in examples to have a comment indicating
> what would be done when said code is not particularly relevant to the
> example.

What _are_ you talking about, Gene? Don't be so defensive and prickly.

I know that that commented out code isn't particularly relevant to the
example...or more precisely, _you_ don't think it is. That doesn't mean
I can't make a point about the code that would possibly be there, and
how that fits in with exceptions.

Here's a clue, Gene. For someone who supposedly has been on Usenet
forever, here's something that you obviously never picked up: when
people answer other peoples' posts, they are often not just replying to
the one person, they may be speaking to a wider audience, and phrasing
things accordingly.

AHS

[toc] | [prev] | [next] | [standalone]

#5181

On 6/10/11 2:03 AM, Nigel Wade wrote:
> A fourth way would be to return a class/object containing both the
> boolean and the String. To me, this would be the natural OO way of
> returning more information than a primitive type.
>
> And a 5th way could be to return the String and throw an Exception if it
> did not work. Some purists may argue that failure to work is not
> strictly an exception, but if it gets the job done...

I find Nigel's 4th and 5th suggestions (which are mirrored elsewhere) to 
be the most apparently applicable and idiomatic of those offered so far.

I offer yet another suggestion that I haven't seen yet: pass 
StringBuilder as the argument, and return boolean.  This is essentially 
like Andreas's #2 suggestion, except that it uses a convenient type 
already built into Java for the purpose.

Pete

[toc] | [prev] | [next] | [standalone]

#5188

On 6/10/2011 2:03 AM, Nigel Wade wrote:
...
> And a 5th way could be to return the String and throw an Exception if it
> did not work. Some purists may argue that failure to work is not
> strictly an exception, but if it gets the job done...
>

My view of this is that a method should not be called "getString", or
any variation on that theme, unless its primary purpose is to get a
string. In that case, it should return the string it gets. Any failure
to get the string is an exception relative to its purpose.

Even when programming in C, I regarded the tendency to return a
success/fail flag and treat the main purpose of the function as a side
effect as an unfortunate but necessary ugliness. In Java, I regard it as
pure ugliness, with no justifying necessity.

Some people seem to confuse making something an exception in a
particular interface with regarding it as a whole program failure. That
makes no sense to me. If there is to be any hope of code reuse, method
interfaces must be designed based solely on the method's intended
function, not the overall program design.

Patricia

[toc] | [prev] | [next] | [standalone]

#5195

On Fri, 10 Jun 2011 09:30:58 -0700, Patricia Shanahan <pats@acm.org>
wrote:

>On 6/10/2011 2:03 AM, Nigel Wade wrote:
>...
>> And a 5th way could be to return the String and throw an Exception if it
>> did not work. Some purists may argue that failure to work is not
>> strictly an exception, but if it gets the job done...

>My view of this is that a method should not be called "getString", or
>any variation on that theme, unless its primary purpose is to get a
>string. In that case, it should return the string it gets. Any failure
>to get the string is an exception relative to its purpose.

     Its primary purpose is to get a string.  Where its result is
returned is not so important.  Call by result is compact.

>Even when programming in C, I regarded the tendency to return a
>success/fail flag and treat the main purpose of the function as a side
>effect as an unfortunate but necessary ugliness. In Java, I regard it as
>pure ugliness, with no justifying necessity.

     It is interesting that the so-called ugliness is much shorter
than the try-catch ugliness.  The added verbosity of try-catch does
not add anything to the code.

     I think that using exceptions can bloat one's code all to easily.
I like my code's flow of control to read as a story.  If there are too
many interruptions, it is difficult to see that story.

>Some people seem to confuse making something an exception in a
>particular interface with regarding it as a whole program failure. That
>makes no sense to me. If there is to be any hope of code reuse, method
>interfaces must be designed based solely on the method's intended
>function, not the overall program design.

     The method's intended function is as a subroutine in imperative
code.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#5192

On 10 Jun 2011 07:33:12 GMT, Andreas Leitgeb
<avl@gamma.logic.tuwien.ac.at> wrote:

>Gene Wirchenko <genew@ocis.net> wrote:
>>      I am writing a simple preprocessor.  I have a few spots where a
>> string needs to be parsed.  I want to call something like this:
>>           String ReturnString="";
>>           boolean DidItWork=GetString(ReturnString);
>>           if (!DidItWork)
>>              // too bad
>> It is not acceptable to have a special String value mean failure.  I
>> want the method to be able to return any potential string.
>
>There's three basic ways to do it:

>2) instead of the string, pass a mutable container of a string:
>    String[] stringContainer = new String[1];
>    boolean didItWork = getString(stringContainer);
>    if (didItWork) { /* stringContainer[0] has the string */ }
>
>  and within GetString:
>    public boolean getString(String[] strCont) {
>            strCont[0] = "blah"; return true;
>    }

     This is a kludge but fairly simple.  I did a bit more looking and
found
http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.html
where a simple class is created.  I ended up with

***** Start of Code *****
// Parameters.java
// Experimenting with Parameters
// Last Modification: 2011-06-10



class StringValue
   {
   String Value;
   }

class IntValue
   {
   int Value;
   }



public class Parameters
   {

   public static void main
    (
    String[] args
    )

      {
      IntValue a=new IntValue();
      IntValue b=new IntValue();
      StringValue RetVal=new StringValue();

      a.Value=1;
      b.Value=2;

      System.out.println(
       "a="+a.Value+", b="+b.Value+", RetVal="+RetVal.Value);

      ChangeValues(a,b,RetVal);

      System.out.println(
       "a="+a.Value+", b="+b.Value+", RetVal="+RetVal.Value);
      }

   public static void ChangeValues
    (
    IntValue First,
    IntValue Second,
    StringValue ReturnValue
    )

      {
      First.Value*=2;
      Second.Value++;
      ReturnValue.Value="change";
      }

   }
***** End of Code *****

[snip]


>PS: Surely, someone will soon point out coding-conventions about
>  upper-/lower-casing different kinds of identifiers. I dare to agree
>  in advance.  (Btw., I changed to conformant casing in my examples.) 

     I have used a number of languages.  One of the things that I
dislike about Java is the small letter first style.  It is
particularly bothersome, because my variable naming convention often
has HN-like prefixes.  When I use a prefix, the main part of the name
is initial-capitalised; prefixes are not capitalised.  For example,
"fhIn" is file handle for In.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#5204

Gene Wirchenko <genew@ocis.net> wrote:
> On 10 Jun 2011 07:33:12 GMT, Andreas Leitgeb
><avl@gamma.logic.tuwien.ac.at> wrote:
>>2) instead of the string, pass a mutable container of a string:
>>    String[] stringContainer = new String[1];
>>    boolean didItWork = getString(stringContainer);
>>    if (didItWork) { /* stringContainer[0] has the string */ }
> 
> This is a kludge but fairly simple.  I did a bit more looking and found
> http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.html
> where a simple class is created.  I ended up with

I think "kludge" is not the apt term for mine. "hack" may be a better.
As you pointed out already, it is equivalent to creating such a container-
class, but there's just the tradeoff:
 - accept some ugliness with "[0]"
 - add yet another trivial class to your project or to 
     your library's whole interface.
Maybe I'm a bad Java-programmer, myself, because I'd go for first,
unless there is some domain-related meaning to such a container
class, like e.g. "FooState" which would then likely contain more
than just one field.

>>PS: Surely, someone will soon point out coding-conventions about
>>  upper-/lower-casing different kinds of identifiers. I dare to agree
>>  in advance.  (Btw., I changed to conformant casing in my examples.) 
>
>      I have used a number of languages.  One of the things that I
> dislike about Java is the small letter first style.  It is
> particularly bothersome, because my variable naming convention often
> has HN-like prefixes.

So, actually the method here would be named sGetString(), that's fine
with Java's *case*-conventions (but perhaps not with others...)

[toc] | [prev] | [next] | [standalone]

#5206

On 6/11/2011 8:37 PM, Andreas Leitgeb wrote>
> So, actually the method here would be named sGetString(), that's fine
> with Java's *case*-conventions (but perhaps not with others...)
>

What does the initial "s" signify here?

[toc] | [prev] | [next] | [standalone]

#5220

On Sat, 11 Jun 2011 23:00:08 +0530, Abu Yahya wrote:

> On 6/11/2011 8:37 PM, Andreas Leitgeb wrote>
>> So, actually the method here would be named sGetString(), that's fine
>> with Java's *case*-conventions (but perhaps not with others...)
>>
>>
> What does the initial "s" signify here?

I think its because GW is using a variant of the so-called Hungarian 
Notation which AFAIK is a Microsoft invention, initially applied to C and 
C++. 

The idea is to make the name of a function or method document the type of 
object it returns by prefixing the name with an alphabet soup of 
initials, so a function returning a string might be called 
sMyFunction(). The catch with it is that, if you need to change the type 
of the returned value, you need to change all references to it as well, 
e.g if the function should rather return a pointer to the string you have 
to rename it to psMyFunction() and then hunt through the source file(s) 
changing all references to it as well.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#5223

Martin Gregorie <martin@address-in-sig.invalid> wrote:
> I think its because GW is using a variant of the so-called Hungarian 
> Notation which AFAIK is a Microsoft invention, initially applied to C and 
> C++. 
> The idea is to make the name of a function or method document the type of 
> object it returns by prefixing the name with an alphabet soup of 
> initials, so a function returning a string might be called 
> sMyFunction(). The catch with it is that, if you need to change the type 
> of the returned value, you need to change all references to it as well, 

I wouldn't exactly call that a "catch".  If you change the return type
of a method, you'd f...ing better have a look at all call-sites ;-)
At least, the compiler will help you, if it finds old sGetString() still
referenced somewhere.  Without changing the name along with the return-
type, you *might* not notice all calls, and end up with a runtime-crash.

There's an entirely different catch, however, namely that people might
change the type but *not* the name, and you end up with the same trouble
as without HN, except wrong expectations on seeing sGetString() which
maybe has been changed to return an Integer.

> e.g if the function should rather return a pointer to the string you have 
> to rename it to psMyFunction() and then hunt through the source file(s) 
> changing all references to it as well.

[toc] | [prev] | [next] | [standalone]

#5230

On Sat, 11 Jun 2011 21:06:32 +0000, Andreas Leitgeb wrote:

> 
> I wouldn't exactly call that a "catch".  If you change the return type
> of a method, you'd f...ing better have a look at all call-sites ;-) At
> least, the compiler will help you, if it finds old sGetString() still
> referenced somewhere.  Without changing the name along with the return-
> type, you *might* not notice all calls, and end up with a runtime-crash.
>
Depends what you're doing. I agree if you, say, are changing the return 
value from int to long int, but if you change from returning a string 
value to returning a pointer to an internally allocated string, then the 
amount of un-necessary work can be quite large.
  
> There's an entirely different catch, however, namely that people might
> change the type but *not* the name, and you end up with the same trouble
> as without HN, except wrong expectations on seeing sGetString() which
> maybe has been changed to return an Integer.
> 
Yes, agreed. I've seen that too.

My other objection is three-fold: HN is ugly, it tends to obscure the 
meaning if a function name, and it goes against Kernighan & Pike's naming 
recommendations in "The Practise of Programming", which IMO is essential 
reading for any fledgling programmers regardless of the language they are 
using. 

IIRC the original MS C compilers (along with other pre-ANSI C compilers, 
I should add) weren't nearly as good as their rivals, such as Borland C, 
so I've always wondered if the use of HN was introduced as a way of 
forcing the programmer cover for compiler deficiencies in reporting data 
type mismatches.  


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#5243

On 6/12/11 3:53 AM, Martin Gregorie wrote:
> [...]
> IIRC the original MS C compilers (along with other pre-ANSI C compilers,
> I should add) weren't nearly as good as their rivals, such as Borland C,
> so I've always wondered if the use of HN was introduced as a way of
> forcing the programmer cover for compiler deficiencies in reporting data
> type mismatches.

Whatever you might think of Hungarian notation _or_ Microsoft, since it 
was invented by Charles Simonyi _before_ he ever was entertaining the 
idea of being a Microsoft employee, it is ridiculous to suggest that the 
convention was invented in order to gloss over "deficiencies" in 
Microsoft's compiler, real or imagined.

[toc] | [prev] | [next] | [standalone]

#5249

On Sun, 12 Jun 2011 09:28:47 -0700, Peter Duniho wrote:

> Whatever you might think of Hungarian notation _or_ Microsoft, since it
> was invented by Charles Simonyi _before_ he ever was entertaining the
> idea of being a Microsoft employee, it is ridiculous to suggest that the
> convention was invented in order to gloss over "deficiencies" in
> Microsoft's compiler, real or imagined.
>
I wasn't pointing the finger exclusively at MS - a lot of the early K&R C 
compilers were awful and were certainly deficient in type matching, 
especially for pointer types. Remember, this was the era when almost all 
C compilers consisted of a control program and four separate subsidiary 
programs: macro-processor, C to assembler translator, assembler and 
linker. They often had to be that way because of current memory sizes.

The first versions of MS C dated from that era, so it would be surprising 
if they didn't suffer from the same deficiencies. However, I admit that I 
still don't see any reason for introducing Hungarian notation except as a 
workround for the lack of rigour in the early compilers.

Context: at that point, 1983/4, I taught myself C on 6809 boxes - Windrush 
C on a box with 48K RAM. The first halfway decent C I used was Microware's 
K&R flavour for OS-09/68K (which I still use from time to time). It was 
some time later that I started to use Borland C, with its excruciating 
four memory models plus near and far pointers and non-standard 'standard 
libraries', on a DOS box before moving to the Windows version with WfW 
3.11. The first really good C I met was the DEC VAX flavour - and IIRC 
that was still K&R rather than ANSI.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#5277

On 6/12/11 10:48 AM, Martin Gregorie wrote:
> [...]
> The first versions of MS C dated from that era, so it would be surprising
> if they didn't suffer from the same deficiencies. However, I admit that I
> still don't see any reason for introducing Hungarian notation except as a
> workround for the lack of rigour in the early compilers.

It is certainly more helpful in that context.  But even today, primitive 
types play a wide variety of roles, and yet the types are not only 
(obviously) assignable to same-typed variables regardless of semantic 
differences, languages include implicit conversions as well between 
different primitive types.

The same reasons that motivated Simonyi to create Hungarian notation in 
the first place still exist today, even in modern languages, including Java.

Pete

[toc] | [prev] | [next] | [standalone]

#5226

On 6/11/11 12:36 PM, Martin Gregorie wrote:
> On Sat, 11 Jun 2011 23:00:08 +0530, Abu Yahya wrote:
>
>> On 6/11/2011 8:37 PM, Andreas Leitgeb wrote>
>>> So, actually the method here would be named sGetString(), that's fine
>>> with Java's *case*-conventions (but perhaps not with others...)
>>>
>>>
>> What does the initial "s" signify here?
>
> I think its because GW is using a variant of the so-called Hungarian
> Notation which AFAIK is a Microsoft invention, initially applied to C and
> C++.

If the intent is for it to be a variant, it is so far away from the 
actual Hungarian convention as to make any connection to that convention 
meaningless.

Of course, 99.9% of the people who claim to be using Hungarian are using 
one of these non-Hungarian "variants", hence the wide-spread hatred of 
Hungarian.  It's possible they still wouldn't like the actual Hungarian 
convention, but it'd be nice if they'd at least get educated about it 
before getting all mad about it.

> The idea is to make the name of a function or method document the type of
> object it returns by prefixing the name with an alphabet soup of
> initials, so a function returning a string might be called
> sMyFunction().

In Hungarian, a function would never ever be named "sMyFunction".  It 
might be named something like "StrMyFunction" or "SzMyFunction" or 
"PstMyFunction", etc. depending on the actual return type.  The initials 
are hardly "alphabet soup", except perhaps inasmuch as any name is 
"alphabet soup" (I suppose in some way, even the words "Martin" and 
"Peter" could be called "alphabet soup"…but I'd hardly consider that a 
useful or relevant description).

> The catch with it is that, if you need to change the type
> of the returned value, you need to change all references to it as well,
> e.g if the function should rather return a pointer to the string you have
> to rename it to psMyFunction() and then hunt through the source file(s)
> changing all references to it as well.

Even in the olden days, when IDEs didn't have excellent refactoring 
built in, such a change was hardly a significant problem. 
Search-and-replace has been a broadly implemented feature in editors and 
tools for a very long time.

Besides, it's not like you can go around changing the return type of a 
function and _not_ go visit every place that function was called (except 
possibly those places where the return value is discarded, in which case 
why use a function that returns anything in the first place?).

There are legitimate reasons to decide to use a naming convention other 
than Hungarian, but the question of renaming functions isn't among them.

Pete

[toc] | [prev] | [next] | [standalone]

#5232

Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> wrote:
> In Hungarian, a function would never ever be named "sMyFunction".  It 
> might be named something like "StrMyFunction" or "SzMyFunction" or 
> "PstMyFunction", etc. depending on the actual return type.

The only "difference" seems to be the multichar type prefix and that
the prefix starts with uppercase letter.  Did I miss something?
I guess, even the "Sz" is just the Hungarian(language) version of a
plain "S"(which in Hungarian language would be pronounced like "sh"
if not followed by a "z"). 

I doubt, that the original HN would have essentially more fans than
the MS-variant.

> [...]
> There are legitimate reasons to decide to use a naming convention other 
> than Hungarian, but the question of renaming functions isn't among them.

100% agree

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web