A 'new' hope

[hopscc]

'hated' probably isnt the right characterisation - nonOptimal maybe...

The obvious answer is that some/most
- dont see () (on construction) as ugly
- () vs .new isnt a 'problem'

Kool-aid again

A friend of mine whose job was architecture once said
"Architecture/Design is attitude

Architecture you 'like' is because you agree with the attitude for what you see as the significant parts and can (at a minimum) tolerate it for the parts you dont agree with...
The interesting thing is no one agrees on 'significant parts' and 'tolerate'".

[hopscc]

I thrashed a bit on the wiki page mentioned above..
Have a look and see if its of any benefit.

[Chasm]

I still have to finish reading all of it (from the c2 link), but why don't we just remove the (), then? Isn't a unified and clean way of doing things better than multiple differing ways that don't offer any unique benefits? Forgive me if I sound like a broken record here, I just have a difficult time understanding both your positions here.

Cheers

[hopscc]

but why don't we just remove the (), then

I guess I dont think you've made your case (yet)
See para under 'the obvious answer' 2 posts back. (dont see the need)

Just to get it laid out specifically and clearly and in one place:
Q. Exactly what is the unified and clean way of doing things (construction?) you are desiring/proposing ?
- ( remove requirement for empty '()' from no-arg constructor calls) (only) ??
??

Q. What is this providing that we dont have?
- (Some added benefit of more consistency to a perceived 'No useless parentheses rule/convention')??
-??

Q. What drawbacks might this have?

Re unique benefits:
If do this how would you then distinguish between a no-arg constructor call and a static ref to the same type ?

ci = MyClass # was MyClass() - no arg constructor call
cref = MyClass # (suitably embellished ) reference to Type MyClass

How would you distinguish (visually -reading code) instance construction from a method call (if thats still desirable)?

Maybe its just familiarity/previous language exposure but earlier you posted this

variable = Something() # In any language which allows CamelCase functions, this could be an assignment of a return value.

Actually this is assignment of a return value,
The return value is that returned from invocation of a Type name which in Cobra (Python and others) is the newly constructed Type instance
other languages do construction differently (with additional kruft^b^b^b^b^b keywords - not necessarily wrong just differently).

Arguably, it is more consistent to have a method-like, parentheses-using invocation for both construction and method invocation rather than
demanding a special keyword for one of them (or having keywords for both of them)

Code: Select all

c = new MyClass(x)  # construction (keyword is 'new' not 'construct')
value = call c.method # method call  -  keyword is 'call'


Ralph Waldo Emerson anybody?

[kirai84]

The most consistent would be

val1 = someMethod()          # Method call.
val2 = someMethod            # Same as above.
met = ref someMethod         # Method ref.

obj1 = SomeClass()            # Instantiation.
obj2 = SomeClass              # Same as above.
cls = ref SomeClass           # Class ref.

[Chasm]

And here's where I disagree.

Code: Select all

val2 = someMethod           # Method call
met = ref someMethod     # Method ref
obj2 = SomeClass.new      # Object construction

I would disallow empty parentheses completely and just keep the .new. The references et cetera would be unchanged.

Benefits? Well, less ways to do the same exact thing, clear separation of method invocation and object construction, (arguably) cleaner syntax..

[hopscc]

val1 = someMethod()          # Method call.    =as Currently
val2 = someMethod            # Same as above. =as Currently
met = ref someMethod      # Method ref.   =as Currently

obj1 = SomeClass()            # Instantiation. =as Currently
obj2 = SomeClass              # Same as above.  = new,  precludes  obj2 = SomeClass as ref to SomeClass 
cls = ref SomeClass           # Class ref.   = allows ref to class of SomeClass

Good call: Cant really argue with that re consistency
The only (small)quibble I have to that is that then ref ( meaning reference-to) can generate either a ref-to-method or ref-to-class which may or may not be seen as confusing.

Kirai84: You see no benefit to more strongly differentiating (visually) between method call and Object instantiation?

x = .aMethodCall
o = Object()
# vs proposed
x = .aMethodCall
o = Object

Chasm:
The .new syntax is purely design choice - you can do this now.

I have to say that personally I dont have any problem with the current syntax but them I'm poisoned/enured by exposure..

Would you find it acceptable if the compiler accepted these but didnt mandate it?

i.e we could (and maybe should) add capability to accept 'ref Type' and do the right thing without any other effect,

# step 1
cls = ref SomeClass 
# same as 
cls = SomeClass #currently

suppressing (current) behaviour of
forcing () on no-arg object instantiation (changing bare Typename to be instantiation )would need some prior behaviour indication (compiler switch or compiler directive - like 'legacy-one-default-initializer')..

# step 2
# or cobra -constructorParanthesesConsistance ...
@CtorParenthesesConsistancy # or something
... 
cls = ref SomeClass
o  = SomeClass

And youd have to convince Charles ( who likes just-one-way as much as possible)

I think the 'ref Type' capability at least should be an enhancement ticket...

[kirai84]

The only (small)quibble I have to that is that then ref ( meaning reference-to) can generate either a ref-to-method or ref-to-class which may or may not be seen as confusing.

It would only be confusing if there were constructor (as a method) refs, but i guess there's not.

Kirai84: You see no benefit to more strongly differentiating (visually) between method call and Object instantiation?

x = .aMethodCall
o = Object()
# vs proposed
x = .aMethodCall
o = Object

I see no benefit to this because:

a) instantiations are already distinguishable due to class name capitalization;
b) I see no benefit in distinguishing at all, it gives nothing;
c) I prefer colorization to be minimal, but that's me.

"Object.new" illustrates the ethereal nature of such differentiation.

.......
I think the 'ref Type' capability at least should be an enhancement ticket...

It'd be nice.

[hopscc]

If you make an enhancement ticket for it a patch will come. (no timescale)

[Chasm]

I can live with syntax that I don't have a personal crush on, but the inconsistencies with parentheses should be solved. Also, why don't classes need the ref keyword? Seems to me like a good way to avoid confusion with instantiation.