print vs Console.writeLine

[jonathandavid]

I forgot to say that the version that throws an exception would be much easier to use if the shortcut syntax for single-line exception handling is available:

x as int
while true
    input 'Enter value:', x
        catch FormatException, print 'Incorrect input. Try again'
        success, break

Finally, I must say that once named parameters are added to Cobra, I'll probably prefer to have a single version of input as a generic function:

ok,x = false,0
while not ok
     x = input<of int>(prompt='enter value', result=out ok)     # writes success flag in "ok"
print 'you entered ',x

x = input<of int>(prompt='enter value', defaultValue=0)         # returns 0 in case of input error

x = input<of int>(prompt='enter value')              # no defautlValue or result, throws
     catch FormatException, print 'there was an error'
     success, print 'value entered ok'

The biggest problem with this approach is that we must specify the type to be read, and that it does not handle input of multiple values.

[Charles]

Taking all this in, my thought is that this is best done with a library, rather than a new statement. I see that you ended up coming to that conclusion yourself in the end.

Even if we had named parameters (outside of object creation), it's not clear that a single method call is best. There are a lot of things going on with input about the behavior as well as the final results. Consequently, a class makes more sense:

"""
This is a *sketch* of a potential class for prompting for input.
"""

class Prompt<of T>

    def init
        _text = ''
        _retryText = ''
        _rawResponse = ''

    ## Setup
    
    pro text from var as String
    
    pro retryOnFail from var as bool
    
    pro retryText from var as String
    
    pro cancelInput from var as String?
        """ When non-nil, this text can be entered by the user to cancel out of the prompt. """
    
    # TODO: add a validation delegate
    
    ## Run
    
    def run as Prompt<of T>
        # ...
        return this
    
    ## Results
    
    get didCancel from var as bool
    
    pro rawResponse from var as String
    
    get response from var as T?


class P

    def main is shared
        prompt = Prompt<of int>( _
            text = 'Enter your age \[c to cancel]: ', _
            retryOnFail = true, _
            retryText = 'Not a valid age.', _
            cancelInput = 'c').run
        if not prompt.didCancel
            trace prompt.response

-- I was bit a surprised that I needed the line continuation character inside the creation of the Prompt. We'll fix that.

-- As you can see, the creation of the prompt is quite explicit about how it will behave, which is great.

-- The multiple properties of the prompt make it easy to explore the results.

-- I'm not positive you could do this with just one class. Maybe this is an abstract class and you need concrete subclasses for each type.

-- Even if it becomes one self-contained class, you still have the option of creating a custom subclass and adding more specs, more results or overriding "run". Try that with a function!

-- There may be other ways to approach this. The sketch above is just my first stab at it. I have other things on my plate, so you can take it from here if you're interested in seeing this fully developed.

-- Hope that helps!

[jonathandavid]

Cool, it had not occurred to me that constructor property initializers could serve as a substitute for named params.

I think I'll give this a try.

[jonathandavid]

As a side note, consider what a lot of typing we'll save when we have a version of "pro from var" that admits an initializer:

class Prompt<of T>
   
   # No init necessary!

   pro text from var = ""                               #  (*)
   pro retryOnFail from var = false               #  (*)
   pro retryText from var = ""                        #  (*)
   pro cancelInput from var as String?
   pro rawResponse from var = ""                  #  (*)
   get response from var as T?

   # same as previous snippet

Also, shouldn't the following:

class Program
   def __init
      pass

be equivalent to:

class Program
   def init is private
      pass

??

[Charles]

As a side note, consider what a lot of typing we'll save when we have a version of "pro from var" that admits an initializer:

class Prompt<of T>
   
   # No init necessary!

   pro text from var = ""                               #  (*)
   pro retryOnFail from var = false               #  (*)
   pro retryText from var = ""                        #  (*)
   pro cancelInput from var as String?
   pro rawResponse from var = ""                  #  (*)
   get response from var as T?

   # same as previous snippet

Yep.

Also, shouldn't the following:

class Program
   def __init
      pass

be equivalent to:

class Program
   def init is private
      pass

??

Well in __foo, the __ becomes part of the name as well so then it's no longer "init".