A 'new' hope

[Chasm]

I've been thinking about how I don't really like instantiation and I think I got it kind of sorted out.

Why remove the 'new' keyword anyway? Isn't it all about readability? And readability's the one thing that 'new' provides?

variable = Something() # In any language which allows CamelCase functions, this could be an assignment of a return value.
variable = new Something() # A hundred percent clear that this instantiates.

But of course, if it was only for this, that would be a weak reason to include new. My take on the thing is purely a thing of consistency. All the time I hear this great stuff about how 'useless parentheses can be omitted' and then you wonder why the code doesn't compile.

As I posted in my pretty-much first post on here, this is confusing:

variable = Something # variable is of the type 'Type'
variable = Something() # Finally, an instance.

If I wanted to omit the parentheses and instantiate at the same time:

variable = new Something # Parentheses can be omitted, 'new' makes it obvious that I want an instance of Something and not its type

Please consider this. Not only does it play to your 'make it more verbal' style ('not' instead of '!', 'and' instead of &&, etc.), I think it really lends itself to the consistency of requiring parentheses only when they actually do something.

[nerdzero]

Interesting point you bring up. Looking at Cobra through .NET eyes, I actually agree with you. However, since Cobra has mostly Python-like syntax, the way it works now avoids one of the most common mistakes I always make when writing Python code.

Unlike C# or VB, in Python, you instantiate objects without a 'new' keyword like this:

Code: Select all

variable = Something()

And so it is in Cobra. But, in Python, if you forget the parenthesis when calling a method that takes no arguments, you get a reference to the function instead of actually calling it.

Code: Select all

oops = someFunction

Sometimes you want this, but at least for me, most of the time I do not and for whatever reason I always forget those friggin' parenthesis (that and those damn colons). Somehow I rarely forget the parenthesis when creating objects though. I don't know why this is but I'm glad Cobra can kind of read my mind in this regard.

So, yeah I agree it's not consistent, but I think with the forced naming convention where types are PascalCase and variables/methods are camelCase, it's a good balance between readability and "writability".

There are cases though where a 'new' keyword would really improve readability. When you assign a type to a variable or refer to a nested class and then instantiate an object from those, things can get confusing. Here's a snippet from the addin code that does this:

for phaseType in _phaseTypes
    params.phases.add(phaseType(compiler))
params.phases.add(.CustomBindImplementationPhase(compiler, fileToBind))

If there was a 'new' keyword, it would look like this:

for phaseType in _phaseTypes
    params.phases.add(new phaseType(compiler))
params.phases.add(new .CustomBindImplementationPhase(compiler, fileToBind))

That's a little clearer but I'm happy to give up 'new' in 99% of the other cases.

[Chasm]

Thanks a lot for your point of view, though I kind of disagree with the C#/Python parallels.

Now, I know I'm new here and all, but I think it's a fallacy to constantly refer to Cobra in terms of .NET and/or Python. I think we should simply look at the merits of the language on its own and modify it as such. Cobra is not like Python in a lot of aspects anyway, so it's not really fair to judge 'new' as in 'python doesn't have it'.

# Give me Something - not an instance of Something, but its type. This makes logical sense to me
variable = Something

# Give me new Something - give me an instance, a new object.
variable = new Something

No chance of ever making an error with parentheses, because typing variable = new Something() would be syntactically correct, just redundant.

I really hope I'm doing a good job at presenting the idea, I'd hate to sound confrontational - I'm just passionate about this

[nerdzero]

Yeah, I don't think anyone can refute that it makes sense and is clear. I'm probably just used to seeing it in its current form more than anything else. It would be a pretty significant change though to existing Cobra code which we also can't ignore.

[Charles]

Cobra is biased towards Python syntax because I found Python syntax to be very productive compared to other languages. I have enough actual experience with it to feel confident in that statement and also in my assessments of where deviations would make sense.

Generally when considering Cobra syntax, I'll look at Python, C# and occasionally Ruby, as well as considering ideas independently on their own merit.

Chasm, your examples are all lacking in argument passing. Plenty of classes expect arguments when creating instances, like so:

p = Point(x, y)
c = Customer(name)

Adding "new" won't contribute much to those cases. And Cobra doesn't CamelCase methods which must always be referenced through dot (.) or underscore (_). Once you get used to seeing .foo and _foo for members then SomeClass() really looks like SomeClass to you and not a method. Just give it a bit of time.

[Chasm]

I am used to it, it is no longer confusing to me. That doesn't change the fact that it's inconsistent and not very logical..

# This is still much more logical than forcing a useless pair of parentheses that break the 'no useless parentheses convention'.
variable = new Something(foo)

I'm sad that you won't consider this, that's pretty much the only problem I have with the language. More so that there are no ultra-big projects having their whole codebase in Cobra that would be broken and it would be relatively cheap to change it.


Just to clarify, I really respect you guys, but I really feel I have quite a strong argument here. C'mon, stop saying you don't like it. You would get used to it quickly AND it would be completely consistent! What a deal, no? And I'd buy all of you a beer.

[Charles]

First, let me point out that syntax can rarely be 100% logical, especially in a feature rich language. I accept some imperfection in syntax (while at the same time striving for perfection).

Second, I still prefer the more succinct "Point(x, y)" which has worked well in practice. It will remain.

As a side note, there's always something a newcomer would like to change, but it often varies between them. An acquaintance of mine wanted automatic conversion of values so that this type of thing would work:

s = '54'
x = s + 5
assert x == 59

I explained the problems with this including the fact that converting strings to int can be very application specific regarding rules that treat whitespace, punctation, decimal places (does '0.7' get rounded or truncated or error? is '5.0' okay?), etc. He still wanted it.

In the future, please feel free to continue bribing with beer though. Eventually we'll hit an agreement...

[Chasm]

Hahaha, alright. I'll continue my dark plans to overthrow the compiler and defenestrate the useless parentheses. One day, 'new', one day.

[hopscc]

For a contrary position,
try this:
New considered harmful
or a google search for same - there's quite a lot on this topic
New considered harmful.

You can actually do something similar to your argument for what you want now with this
( the syntax isnt quite the same but gets the same point across...)

variable = Something.new
# or with args
variable = Something.new(a,b,c)

Its called a Factory pattern or Factory method pattern and some say its preferable to direct instantiation in all circumstances...

Its quite simple to write all your code to use and present Factory constructors rather than exposed ctors/initializers - purely a design choice not specifically a language one....

Q for thought: Why do you have to know/worry/distinguish between instantiation ( a 'new' something ) rather than a something?

Most mainstream OO languages use a 'new' for instantiation vs just invocation - So the from familiarity argument is a common one.
Once you go away from that though ( and support Type references) you then need to distinguish between a Type and a Type instantiation
(precluding strict naming orthoganality - Type vs Type.new). In cobras case it uses an empty invocation syntax ('()') even though it
violates the 'fewer/simpler no parentheses' presumption.

FWIW one of my small pleasures in converting C# code to cobra is the removal of all the 'new' keywords and how just doing that simplifies and clarifies the code ( well that and removing {}) .
(Try the cool-aide its real good )

Chasm - if u have a moment take a quick look at this wiki/doc page
Method Invocation and Class construction
Its in a real parlous state now but leaving that aside for a moment , As someone coming to cobra clean
what would you think could be written on there to clearly distinguish between instantiation syntax vs Type referencing (pretty much anything considering my first point) and address your concerns?

[Chasm]

Whoa, that's a lot to take in - I had no idea that 'new' is hated. I'll have to read up on this, so give me some time.

I really like variable = Something.new, though. Why even include those ugly (), if .new solves the problem?