Pass Object Variables Directly to init

[oahmad04]

What if we could replace this:

class Person

    var name as String
    var age as int
    var ID as String
    var group as String

    cue init(name as String, age as int, ID as String, group as String)
        .name, .age, .ID, .group = name, age, ID, group
        .callSomeMethod

With this:

class Person

    var name as String
    var age as int
    var ID as String
    var group as String

    cue init(.name, .age, .ID, .group)    # A dot means assign the argument to the object variable of that name
        .callSomeMethod

Less typing . There are many cases where the only reason you even need to write an init is to assign values to object variables.

[kobi7]

hi oahmad04, I like your suggestions they're very creative.
I had a similar idea, based on a feature I saw in another language.
which is: implicit ctors, by explicitly specifying which fields are necessary to be initialized.
to borrow your example:

class Person

    var name as String :required
    var age as int :required
    var ID as String
    var group as String

will create

cue init(name as String, age as int)
    base.init
    .name,.age = name,age

if you provide your own ctor, with the same types and arity (number of arguments) then it will overwrite the baked one.

[oahmad04]

I like that even more. To make it more Cobra-like:

var name as String is required
var age as int is required
var ID as String
var group as String

hi oahmad04, I like your suggestions they're very creative.

Thank you

[oahmad04]

To show how this might look if we want additional arguments (not just for object variables):

class Person

    var name as String is required
    var age as int is required

    cue init(ID as String, group as String)

        .callSomeMethod(ID, group)

Is the equivalent of:

class Person

    var name as String
    var age as int

    cue init(name as String, age as int, ID as String, group as String)
    
        .name, .age = name, age
        .callSomeMethod(ID, group)

[kobi7]

it makes sense what you did right there, maybe the example is not so fitting.
However I normally find that a constructor is for what the object really needs to function,
so I prefer to make another method 'load', 'initialize', 'prepare' or something similar, where I can add more data.
that way it is easier to just get a simple ("naked") object, for unit testing for example.

So the point is that fields that aren't required shouldn't go to a ctor.
if you want other ctors, and this feature is accepted, then an error could be issued, that a required field is not set, after the ctor is finished.

if you write your own code, you want everything explicit, and no extra surprises.
but baked in conveniences are good.

that's my current "practice" regarding this issue.

But I don't have much experience so maybe members can share their opinions wrt pragmatism.
Thanks for raising the discussion since I think it's a nice feature to have.

[hopscc]

silent action at a distance .... how clear is that ?

fm Python PEP-20 # 2
" Explicit is better than implicit."

[cathalgarvey]

A chip-in from a first-poster.

In Coffeescript, if memory serves, the syntax is;

Code: Select all

<initialiser method>(@var1, @var2)
    <method body, no need to assign var1/var2>

So, like using the dot-syntax for arg/param names, using "@" (which in coffeescript is bound to "this") means "assign this to self, don't require me to explicitly do so".

I like this format far more than marking vars in the class definition. That's because marking vars, as a syntax, sort of imposes a variable order upon me, and limits my ability to overload my initialisers. I'd rather always decide which params to receive on a method including my initialisers, but the dot-syntax avoids the ugly "this.this = this" stuff.

So, to cut to the chase, +1 for:

cue init(.name, .age, .ID, .group)    # A dot means assign the argument to the object variable of that name

[kobi7]

I like this format far more than marking vars in the class definition. That's because marking vars, as a syntax, sort of imposes a variable order upon me, and limits my ability to overload my initialisers. I'd rather always decide which params to receive on a method including my initialisers, but the dot-syntax avoids the ugly "this.this = this" stuff.

good point, i hadn't thought of that.

so basically do you guys suggest two kinds of cue init, one with a body, and one without (this dot notation)?
or how would one go about not removing functionality, since sometimes you would (for example) check the variables for a certain range, or do a little computation with them before assigning,use a static method from somewhere else, or actually a myriad of possibilities...

[oahmad04]

so basically do you guys suggest two kinds of cue init, one with a body, and one without (this dot notation)?
or how would one go about not removing functionality, since sometimes you would (for example) check the variables for a certain range, or do a little computation with them before assigning,use a static method from somewhere else, or actually a myriad of possibilities...

I just imagined I would use "pass" if a body isn't needed. If you do want to modify the argument before assigning it to an object variable, maybe the dot notation isn't the best idea (it would probably be too confusing).