Re: NXC - main method params?
Posted: 19 Feb 2012, 21:47
I disagree with this kind of classification as it doesn't really provide anything useful for the programmer. We shouldn't classify 'tasks' on their input, output and placement, we should rather classify them based on what they do.
Look at most of NXC functions. They take a struct as input (behind the scenes) and do something with it. This would look like this:Now this could easily have been done in a OOP way:Now it is no longer a function, but a method.
But let us return to the function viewpoint. It is a function because it returns a char, but this char have literately no importance so we could just remove this. Now it is a procedure. (Seriously, how many checks whether PointOut() successfully drew on the screen or not?)
Many functions can't just be changed to procedures, but many others can because the return value isn't critical to the purpose of the function.
This draw-a-dot 'task' can be a procedure, function or method by making minor modifications which makes no difference for the programmer which writes it or uses it. Then why should we call them something different? If we have to categories 'tasks', then why not do it in a way so it becomes useful for the people that are actually using the code?
Anyway, this is becoming off topic...
Look at most of NXC functions. They take a struct as input (behind the scenes) and do something with it. This would look like this:
Code: Select all
DrawPointType draw;
draw.Location.X = 5;
draw.Location.Y = 10;
SysDrawPoint( draw );Code: Select all
DrawPointType draw;
draw.Location.X = 5;
draw.Location.Y = 10;
draw.SysDrawPoint();But let us return to the function viewpoint. It is a function because it returns a char, but this char have literately no importance so we could just remove this. Now it is a procedure. (Seriously, how many checks whether PointOut() successfully drew on the screen or not?)
Many functions can't just be changed to procedures, but many others can because the return value isn't critical to the purpose of the function.
This draw-a-dot 'task' can be a procedure, function or method by making minor modifications which makes no difference for the programmer which writes it or uses it. Then why should we call them something different? If we have to categories 'tasks', then why not do it in a way so it becomes useful for the people that are actually using the code?
Anyway, this is becoming off topic...
