Usage of :=

Monkey Forums/Monkey Beginners/Usage of :=

okee(Posted 2014) [#1]
Just getting to grips with monkey and notice the use of := in various places
Just wondering what the meaning is

I assume its a shortcut for declaring a variable and assigning a type ?
Does it's usage vary when using strict ?


therevills(Posted 2014) [#2]
I assume its a shortcut for declaring a variable and assigning a type ?

You are correct, for example:
Local str:String = "Hello"
Local str:="Hello"

Local i:Int = 232
Local i:= 232

Local j:=GetPlayerX()

Method GetPlayerX:Float()
    Return x
End


Does it's usage vary when using strict ?

It shouldn't.

I actually like to declare the type as it makes it more readable and you dont have to go searching to check the return type of a method etc.


okee(Posted 2014) [#3]
Thanks therevills, very helpful


Raul(Posted 2014) [#4]
i didn't know about that...wow


MaxPower(Posted 2014) [#5]
Seeing ThereVills example.
He has Local i := 232 does that automatically make it an INT,so you don`t need Local i:int = 232.

soz just reread example depends whats to the right of :=


ziggy(Posted 2014) [#6]
Seeing ThereVills example.
He has Local i := 232 does that automatically make it an INT,so you don`t need Local i:int = 232.

soz just reread example depends whats to the right of :=

Yes, and it is resolved at compile time. It's data type inference. http://en.wikipedia.org/wiki/Type_inference
I found it very handy when properly used.


Gerry Quinn(Posted 2014) [#7]
I don't use it, but to be honest I think it's out of habit, and a lot of the time the code is shorter and just as clear.


therevills(Posted 2014) [#8]
and a lot of the time the code is shorter and just as clear.


Local blah := GetPlayer().GetPowerUp().GetBoostAmount().GetLight()


What is blah? ;)


Gerry Quinn(Posted 2014) [#9]
You have a point! But that's not really my coding style, and besides, the answer is still that it's whatever you expect light to be.


muddy_shoes(Posted 2014) [#10]
The real fun begins when you combine this syntax decision with Monkey's (non-Strict) default Int typing and warning-free implicit type conversion.

Local a := 3.14159 'All's fine

Local b = 3.14159 'You dun goofed all biblical with pi. How could you make such an obvious mistake?

It's pretty much a booby-trap in the language design.


Samah(Posted 2014) [#11]
To be honest I think it's just plain horrible. IMO don't get yourself into the habit of using it.


Gerry Quinn(Posted 2014) [#12]
I don't think that's really a problem, muddy. You can use Strict and :=, and the problem doesn't arise. Indeed, even with non-strict. I'm not sure there's really an issue, unless you're saying the absence of : is hard to notice.


muddy_shoes(Posted 2014) [#13]
Yes, that's exactly what I'm saying. Strict isn't the default and a simple flubbed keystroke will result in your float precision being silently lopped off. If it's not in the forefront of your mind to look for that exact issue you can likely read the assignment multiple times without spotting the problem.


Gerry Quinn(Posted 2014) [#14]
Maybe the := is a bad choice. I think in some languages there is <= but ofc that is already syntax in Monkey.

In any case, whatever my temptation to use :=, I have never been tempted to drop Strict. Even though I forget to declare every second void function as void!


muddy_shoes(Posted 2014) [#15]
It's not really the := that's the bad guy here, just the combination of that with the non-Strict default behaviours. The decision to make the fast and loose mode the default seems an invitation to trouble for new users.


Samah(Posted 2014) [#16]
Just drop the Strict keyword and make it default. If you really want to keep it, make a LazyBastard keyword. :)


Gerry Quinn(Posted 2014) [#17]
Agreed, Samah.

Mark could also have considered using == as that is very visible and is not syntax - but that means equality in so many languages that it might be a questionable choice.

Maybe <== which is unmissable, but three characters is a lot.


Shinkiro1(Posted 2014) [#18]
I think it depends on the scenario you are using it in.

Local sourceListDataSource:SourceListDataSource = New SourceListDataSource

vs
Local sourceListDataSource:= New SourceListDataSource


I don't think the first one adds any readability to the code.


therevills(Posted 2014) [#19]
@Shinkiro1 - yeah that's the only usage I like about the := operator (instantiating the object) , its nearly like the diamond operator for Java...


Samah(Posted 2014) [#20]
Diamond operator is the other way around, but yes it's a similar example of type inference.


therevills(Posted 2014) [#21]
Diamond operator is the other way around


its nearly like the diamond operator


;)


Gerry Quinn(Posted 2014) [#22]
I think the biggest issue is that := is actually nice for instantiation, but I am not comfortable about mixing it with the spelled-out version for general assignments. Maybe I should try it out and see if the mixture looks okay.

It's kind of similar to why I don't use the end-tags (e.g. name% instead of name:Int) to indicate primitive types. And again, I could always apply the logic that it's legitimate for primitive declarations to be different from object declarations. In fact one could argue that it's BETTER, because it creates a visible distinction between primitives and objects!