Cobra Forums

Posted: **Sat Jan 04, 2014 5:10 pm**

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.

Posted: **Sat Jan 04, 2014 11:21 pm**

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.

Posted: **Sun Jan 05, 2014 3:18 am**

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

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

Thank you

Posted: **Sun Jan 05, 2014 3:35 am**

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)

Posted: **Sun Jan 05, 2014 5:20 am**

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.

Posted: **Tue Jan 07, 2014 2:28 am**

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

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

Posted: **Thu Jan 09, 2014 6:17 pm**

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

Posted: **Sun Jan 12, 2014 9:48 am**

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...

Posted: **Sun Jan 19, 2014 5:47 pm**

kobi7 wrote: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).

Cobra Forums

Pass Object Variables Directly to init

Pass Object Variables Directly to init

Re: Pass Object Variables Directly to init

Re: Pass Object Variables Directly to init

Re: Pass Object Variables Directly to init

Re: Pass Object Variables Directly to init

Re: Pass Object Variables Directly to init

Re: Pass Object Variables Directly to init

Re: Pass Object Variables Directly to init

Re: Pass Object Variables Directly to init