A 'new' hope

[Charles]

I'm heading out soon to meet nerdzero, the author of the Cobra MonoDevelop/XamarinStudio support. Some quick thoughts:

-- The ability to reference classes directly such as:

classes = [Circle, Square, Rectangle]
...

Was inspired by at least Python and possibly also Smalltalk (if memory serves me right). Classes are first class objects that can be referenced directly. It's also consistent with the fact that you can write "SomeClass.someMethod" in which case the item on the left hand side is a reference to a class.

It's like the class name is a readonly variable pointing/referring to the class object.

-- I still don't see the advantage of adding 3 "new"s here:

outline = Rectangle(Point(0, 0), Size(10, 20))

-- kirai84's post about consistency is off in a couple ways. "val2 = someMethod" seems to imply that in his proposal methods can now be referenced without a . or _ though it's not clear if he intended that or not. Also, he doesn't cover the case of calling or instantiating a local variable that is referring to a class, and the same for referring to a method. Or maybe that's what he meant with "someMethod" and has not covered the other case of naming the method directly. Also, when trying to put all the cases together, please include ones that have arguments as well as no arguments.

-- I've noticed over the years that there is no perfectly consistent syntax that is also a good syntax.

-- I've noticed over the years that there is no perfect syntax for a non-trivial language. There are always a couple odd rules (or more if you have failed to minimize them).

[kirai84]

-- kirai84's post about consistency is off in a couple ways. "val2 = someMethod" seems to imply that in his proposal methods can now be referenced without a . or _ though it's not clear if he intended that or not. Also, he doesn't cover the case of calling or instantiating a local variable that is referring to a class, and the same for referring to a method. Or maybe that's what he meant with "someMethod" and has not covered the other case of naming the method directly.

My bad, I meant "val2 = .someMethod".

Also, when trying to put all the cases together, please include ones that have arguments as well as no arguments.

They are the same as with empty parenth (that is as they are now).
Anyway I won't probably be a Cobra user so I won't add any tickets myself. Just thinking aloud.

[Chasm]

Anyway I won't probably be a Cobra user

With all due respect, isn't it unfair to try and influence syntax that you're not even going to use yourself?

[basmith]

At first, I liked the idea of 'new', being a developer of the C++/Java/C# lineage. I like Python, but haven't used it much.

As I understand it, you more or less have two possible syntactic scenarios in the context of Cobra:

sm = SuperMan #instanciate
sm = SuperMan.getType #typeref

or

sm = new SuperMan #instanciate
sm = SuperMan #typeref

(I'd like to vote for a typeof-style operator if one doesn't exist, IMO it makes visual code-scanning quicker... )

I was thinking about the circumstances under which one would instantiate versus typeref, and it occurred to me that you will generally instantiate considerably more often than you will typeref.

Outside of other potential factors, the decision to use the former vs the later as idiomatic syntax would probably rest upon diminishing verbosity; this would favor pushing syntax/grammar onto the typeref scenario rather than onto the instanticate scenario. That is to say, it is probably "better" to type .getType on a few occasions, than it is to type new on many occasions.

[hopscc]

almost:
Currently

sm = SuperMan()  #instantiate note trailing empty ()
smref = sm.getType #  using .Net library  typeRef on instance
smref = sm.typeOf  #   cobra builtin  - typeRef on instance 

smref = SuperMan   #typeref on Type Name
# smref = SuperMan.getType also works but is redundant

vs

sm = new SuperMan #instantiate (ick)
sm = SuperMan.new  #instantiate -  can do now if structure code using Factory creation
sm = SuperMan          # instantiate (proposed - drop empty ())
smref = ref SuperMan # typeRef on TypeName - cf reference to a method name :   smMethdRef= ref sm.method

The point about increased verbosity for diminishing frequency of use is a reasonable one
against which we have a body of existing code,
several years of acquired habits/familiarity and (for the same acquirees) no great dis-satisfaction with the status quo.

I think there is only one prefix (unary) named operator in cobra ( ref).
Instead, the tendency/architectural-choice has been to remove that need or to build/extend or overlay methods onto instances or Classes as method-like calls ....

[basmith]

I did realize about the parenthesis vs lack-of scenario after posting, but my post was in the void awaiting approval so I couldn't make any adjustments.

I think Ruby has a few scenarios like this; there, parentheses are optional much of the time, but calling something with neither parameters nor parentheses can (in a few specific situations) result in different behavior vs calling with empty parentheses. I believe SuperMan.new is idiomatic instance construction in Ruby, avoiding the unadorned-call-becomes-typeref scenario.

[Chasm]

I believe SuperMan.new is idiomatic instance construction in Ruby, avoiding the unadorned-call-becomes-typeref scenario.

And we would like to see it implemented as the default way to create objects, right basmith?

[Charles]

I think there is only one prefix (unary) named operator in cobra ( ref).

all any not old ref

[basmith]

And we would like to see it implemented as the default way to create objects, right basmith?

Personally speaking, if there was going to be a specific syntax/grammar, I prefer the keyword/operator-style to the method-style.

[Charles]

I prefer this style:

outline = Rectangle(Point(0, 0), Size(10, 20))