Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simple way to "copy" args #19

Open
squito opened this issue Dec 27, 2013 · 4 comments
Open

Simple way to "copy" args #19

squito opened this issue Dec 27, 2013 · 4 comments

Comments

@squito
Copy link
Contributor

squito commented Dec 27, 2013

Sumac should provide some simple way to copy "matching" args from one arg instance to another. This should also handle dervied values, not just the direct string arguments. eg.:

trait DbArgs{
  var user: String = _
  var password: String = _
  var host: String = _
  var port: Int = _
  var _connection: Option[Connection] = None
  def connection = {
    //initialize _connection if need be
  }
}

when that is copied, it should somehow know that it should also copy _connection.

I have no idea how to do this right now. maybe it will require extra annotations on _connection, or implementing some method which returns some kind of handle on _connection, I dunno ...

@Mortimerp9
Copy link
Contributor

I was thinking about this and what we discussed on chat about the
initialisation of connection.

Instead of assuming sumac will call a setter that will know how to build a
connection, with a special arg, there could be something like a constructor
that sumac knows about and calls when the parsing/validation is done.

Validation does this already I guess, it's just a question of giving
guidelines on how to use it properly for this, in particular with the
ordering of calls (all real validations should be called before the
"constructor" validator).

When copying, it would be the same thing, copying would eventually call the
"constructor" (that's where validation might not be reused, unless you want
to run twice all validations when copying).

On Fri, Dec 27, 2013 at 8:22 PM, imranr [email protected] wrote:

Sumac should provide some simple way to copy "matching" args from one arg
instance to another. This should also handle dervied values, not just the
direct string arguments. eg.:

trait DbArgs{
var user: String = _
var password: String = _
var host: String = _
var port: Int = _
var _connection: Option[Connection] = None
def connection = {
//initialize _connection if need be
}}

when that is copied, it should somehow know that it should also copy
_connection.

I have no idea how to do this right now. maybe it will require extra
annotations on _connection, or implementing some method which returns
some kind of handle on _connection, I dunno ...


Reply to this email directly or view it on GitHubhttps://github.com//issues/19
.

@squito
Copy link
Contributor Author

squito commented Dec 27, 2013

I don't see a simple way to do that, which doesn't end up requiring the user to do a bunch of boilerplate. Eg., you could have a Builder type, which takes all the string args, and then when Builder.build is called, it turns itself into a connection. But, then what types would the user specify in their args? I worry it might get more confusing in the end.

But maybe you had something else in mind? maybe a little code example would help me to understand ...

@Mortimerp9
Copy link
Contributor

I was thinking of something like this:

trait DbArgs{
  var user: String = _
  var password: String = _
  var host: String = _
  var port: Int = _
  var connection: Option[Connection] = None

 @Constructor
 private def build() {
      _connection = Try{DB.openConnection(host, port, password, user)} toOption
  } 
}

When sumac is done parsing, validating and setting the vars, it calls the method in the object that is tagged with @Constructor. However, that might create problems with inheritance, another solution is to have a addConstructor in the same way as there is addValidation and guaranteeing that Constructor functions are called after Validation functions, but not specifying any guarantee on the order within the set of constructors.

@squito
Copy link
Contributor Author

squito commented Jan 1, 2014

I am totally confused ... how does this solve the copying problem? it seems like it would create another connection, as opposed to copying the existing one.

as for solving the initialization problem -- functionally you are proposing two-stage validation, but with some syntax to guide the user on how they should use the different stages, right? I wonder if two stages actually solve the problem, or if it just kicks it down the road a little further. maybe we need some way to define an order for validation, but I can't think of any nice syntax for that ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants