GSoC: Change getPos() to Array from tuple

[Ellipse0934]

@aviks , If there are concerns regarding this then I would suggest that you post them here. I will think about them and clarify as needed.

[aviks]

So tell me again why you want to change the return from tuple to Array? What is the benefit? Is it merely that the array is then mutable? My thinking was that the player position is retrieved from an external source, so as far as your program is concerned, it is immutable. Changing your copy of the player position is not going to change the position of the player in game. So in that sense, an immutable tuple makes sense.

Did you have any other concerns?

[Ellipse0934]

I want people to be comfortable. Remember some might never have programmed in their life. This PR helps make it more flexible for them. Vectors are intuitive. If they have trouble understanding the coordinate system they will watch a khanacademy video and return. From that point our syntax needs to be "good" enough for them. I don't see any need for immutable types right now. This will just confuse them. If we don't make it an array people will start doing this all the time:

p = player.getPos();
p = [i for i in p];
player.setPos(p + [7, 8, 9]);

The most common use case is to teleport. There are 2 types of teleport:

1. Absolute teleport

   entrancegate = player.getPos();
   ...
   player.setPos(entrancegate) # does not work right now, next PR perhaps

2. Relative Teleport player.setPos(entrancegate + [17, 0, 0]) The idea is to use displacement vectors for relative teleport which is going to be extremely common. PS: I am experimenting around and building stuff right now. I am myself using the array version as it is much more convenient. TL;DR: The ability to do player.setPos(player.setPos() + [1000, 15, 0]);

[aviks]

Yes, agreed, the ability to do relative transport using the plus operator is useful. However, what you need is element-wise addition, not vector addition. Remember, adding two vectors is actually adding them in vector-space. The current + operator for vectors indeed does element-wise addition, not vector addition, but there is an argument that this is wrong, and it might change in the future.

The canonical way to element-wise operations in Julia is via the . operator, and that is what we should be teaching. I've been teaching Julia to a kid, and I can confidently say that this is easy to understand. In fact, it is possibly easier, since people are not confused by different meanings of +.

To cut a long story short, element-wise operations work for tuples as well.

julia> (1, 2, 3)  .+ (2, 3, 4)
(3, 5, 7)

julia> [1, 2, 3] .+ [4, 5, 6]
3-element Array{Int64,1}:
 5
 7
 9

[Ellipse0934]

That makes sense.

[aviks]

Thanks for raising the issue though. It's worth having a discussion on the design of the library.