<div dir="auto"><div>Touche. This class is strictly IO focused, and basic IO at that. And even within that, the bar should be extremely high for what goes in this class.<div dir="auto"><br></div><div dir="auto">But let me ask -- if many things meet that bar, do you feel there should be a limit for how many enter the class?</div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 21, 2024, 9:41 AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>

  
  <div>
    Agree this is a better name.  <br>
    <br>
    As to the "bucket of what" question, we had a very deliberate target
    in mind: we did *not* want this to become the catch-all "statically
    imported" bucket (which would rapidly become an attractive
    nuisance), so we chose a targeted name to make it clear that this
    was about a narrow set of things that are useful to the specific
    situation of IO from simple programs.  <br>
    <br>
    <blockquote type="cite">
      
      <div dir="auto">SystemIO is the best suggestion thus far. If you
        ever do add anything to this class, you don't tie yourself down
        to the beginner-like name. If one day a useful primitive comes
        to light that is not so Simple, this class might still be the
        best place to put it. Really, this class is at it's best when
        it's a bucket of useful primitives, especially ones that
        complement each other. Not opening the can of worms for "what",
        as we've gone fairly off topic from the original threads intent.</div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Wed, Feb 21, 2024, 3:47 AM
          Stephen Colebourne <<a href="mailto:scolebourne@joda.org" target="_blank" rel="noreferrer">scolebourne@joda.org</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I
          do agree that "Simple" isn't the best prefix here, and "Basic"
          is a<br>
          bit better,<br>
          <br>
          But I personally prefer SystemIO, as it<br>
          (a) links the concept to the existing System class, which they
          will<br>
          likely see or have seen by Googling<br>
          (b) introduces the concept of the "system" that the code is
          running on<br>
          <br>
          ie. I think "System" is a better on-ramp name as it actually
          leads to<br>
          the "real thing"<br>
          <br>
          Yours bikeshedderly,<br>
          Stephen<br>
          <br>
          <br>
          On Tue, 20 Feb 2024 at 21:01, Brian Goetz <<a href="mailto:brian.goetz@oracle.com" rel="noreferrer noreferrer" target="_blank">brian.goetz@oracle.com</a>>
          wrote:<br>
          ><br>
          > I was all ready to dismiss this as just bikeshedding, but
          your clever up-front disclaimer convinced me to hang with you
          :)<br>
          ><br>
          > I think what you are saying here is that we've set a trap
          for ourselves by claiming the word "simple", which, as we've
          seen, is subject to "everyone interprets it in a way to
          support their own preference."  Fair point; naming matters,
          especially when setting direction.<br>
          ><br>
          > I am not as optimistic as you that if we called this
          "BasicIO", whether we wouldn't get the same arguments, but
          your point is taken: the goal here is not simplicity, it is
          about putting in place some very basic IO primitives which can
          be built upon, which do not depend on either other library
          abstractions (Scanner, Console, StringTokenizer), which are
          reasonably symmetric with respect to input and output, and
          which do not require explanation of static fields in order to
          use for the first time.<br>
          ><br>
          > These characteristics serve both students and "scripts",
          in that they address the most basic console IO needs without
          ancillary abstractions.<br>
          ><br>
          ><br>
          ><br>
          > On 2/20/2024 12:39 PM, Eirik Bjørsnøs wrote:<br>
          ><br>
          > Hi,<br>
          ><br>
          > I acknowledge the following is easy to dismiss as just
          bikeshedding, but please hang with me:<br>
          ><br>
          > Is labeling something as "simple" an effective naming
          practice, especially in a pedagogical context like we are
          faced with in this JEP?<br>
          ><br>
          >> simple: adjective<br>
          >> 1. easily understood or done; presenting no
          difficulty.<br>
          >> "a simple solution"<br>
          ><br>
          ><br>
          > First, let me be bold and claim that nothing in
          programming is "easily understood or done; presenting no
          difficulty". Anyone claiming so has clearly lost empathy with
          the beginning learner! ;-)<br>
          ><br>
          > Second, the lable "simple" suggest something about the
          things not fitting into the "simple" bucket. If not simple,
          what are those things? Difficult?<br>
          ><br>
          > Third, "easily understood" very much depends on who is
          trying to understand. It may change over time as the learner
          gains understanding and experience. Simple to Alice might not
          be simple to Bob.<br>
          ><br>
          > ...<br>
          ><br>
          > As any complainer, I'm also too lazy to do the work to
          find a better alternative. But perhaps "basic" could be a
          starting point:<br>
          ><br>
          >> basic: adjective<br>
          >> 1. forming an essential foundation or starting point;
          fundamental.<br>
          ><br>
          ><br>
          > This seems more stable to time, context and experience.
          Something fundamental can be trusted to stay fundamental for a
          while.<br>
          ><br>
          > Thanks (any sorry!),<br>
          > Eirik.<br>
          ><br>
          ><br>
          ><br>
        </blockquote>
      </div>
    </blockquote>
    <br>
  </div>

</blockquote></div></div></div>