registerFunc->e2function

[Unsmart]

I'm bored out of my mind, have nothing to do, so I thought I might change the registerFunction to e2function in the E2/core. This is how things are as of now:

E2 func list:

bone
debug
console
files
bitwise
wirelink
weapon

register function list:

angle
array
compat
selfaware
player
entity
vector2
vector

I think using the e2function is a lot cleaner, adds DESCRIPTIVE variables (and readable by E2 helper) names to the code, not that *@#$%ing rv1,rv2 which was driving me crazy when I tried to edit some code in E2.


Permission from devs? As starting and the edits getting denied wouldn't be nice......



----
Im talking about this:
http://wiki.garrysmod.com/?title=Wir...nsion_Tutorial


Atm Im working on remaking angle.lua
edit: 2/3 of angle.lua done, testing in SP

at devs:
why the heck you complicate your lives like that? math.ceil etc is way faster I bet

e2function angle ceil (angle a)
	--original code:
        --local p = a[1] - a[1] % -1
	--local y = a[2] - a[2] % -1
	--local r = a[3] - a[3] % -1
	--return {p, y, r}
	
         --my code:
	local p = math.ceil(a[1])
	local y = math.ceil(a[2])
	local r = math.ceil(a[3])
	return {p,y,r}
end

also:

e2function angle angnorm(angle a)
	return {(a[1] + 180) % 360 - 180,(a[2] + 180) % 360 - 180,(a[3] + 180) % 360 - 180}
end

Calling destructors for all Expression2 chips.
Reloading Expression2 extensions.
entities/gmod_wire_expression2/core/angle.lua:175: PP syntax error: Function names may not start with a number.
:13777: '=' expected near 'void'
Calling constructors for all Expression2 chips.
Done reloading Expression2 extensions.

[Syranide]

Sure, as long as the code behaves the same way, I'd say it's a plus.
However, as for using math.ceil, it is way slower, but it seems that if you alias all the math-functions locally (within the file) then the difference is less noticeable and the code readability becomes preferable. I believe we already do this in some extension, vectors I think.

[feha]

Register function is easyer to understand though, but as it let you make stuff understandable in e2 editor I see why it is better. And about descriptive variables, its not hard, myself I always use a local function for the code, and then registerFunction to give you a function to use it with. This makes it possible to use several syntaxes XD.

[Unsmart]

Register function is easyer to understand though, but as it let you make stuff understandable in e2 editor I see why it is better. And about descriptive variables, its not hard, myself I always use a local function for the code, and then registerFunction to give you a function to use it with. This makes it possible to use several syntaxes XD.

how can rv1.....rv100 op1 etc be more understandable? e2function has many pluses, it even drops out he 1st two lines (rv+op)

[feha]

I didnt mean the variables are more understandable, thats one of the reasons I use local functions for the actual code.

registerFunction had a more understandable syntax though, as you just gave it types, and then kinda copypasted 2 lines from other funtions and sent right variable into right part of local function.
e2function requires you to figure out that it is the function for making functions (bad name), understand that you have to write void number or whatever for return/variable types, instead of the right letter (N,E,V...).
It also makes you wonder what part is name, as there is a space between name and (), aswell as the Blah: variable is way more confusing as it is unlike the others, only is known as "this".

[TomyLobo]

@unsmart:
I have a converter here that automatically translates a whole file.
The main problem is giving the arguments names afterwards
after using the converter, you end up with rv1 rv2 rv3 everywhere

Parts of array.lua were left untranslated intentionally, so it's easier to make them generic later on.
The inability to make a generic function is actually the only disadvantage of e2function over registerFunction.

@feha:
the type name you write is the same name you use when declaring a variable in E2
[highlight=E2]@persist X:vector4
X=foo()
=> e2function vector4 foo()[/highlight]

The main point is that e2function syntax is easier to read, which is a large plus when it comes to spotting and fixing problems. If you don't name your variables like data types, you should not have any problems telling which is which
We (which is Syranide and me) also discussed a "var:type" syntax, but dropped it in favor of the C-style type notation we have now.
Among the reasons was that the gmod wiki uses C-style type notation.
They use pictures instead of the type names now, but it is quite apparent here:
http://wiki.garrysmod.com/index.php?...te&oldid=27118

"function for making functions"
e2function is not a function, it is a keyword and part of a language construct.
registerFunction, on the other hand, is a function.

"there is a space between name and ()"
No, there usually is not.
If you ever see that somewhere, that is because the author chose to put it there.
It is entirely optional.

"kinda copypasted 2 lines from other funtions"
If copypasting is your thing...
I kinda like to write what I want the function to do and minimize the clutter of boilerplate code around it.

[feha]

I know what it is, what I meant was that it might be confusing for ppl who expect the function in lua code to look a bit like it does in wiki, meaning lots of 1-letter words and some 2-letter.

About not having var:type I think actually is quite good, however, even though I cant find a better way to do the : variable, I cant say the current is "good" :P. but then again, everything has limitations...

I think of the e2function as a functino to create e2 functions, as even though it is not an actuall lua function, it works as a function in the way you input arguments:
e2function (return, vartype:functionname(var type name...)
actuall code
end)
Where you just made the thing reading those "functions" capable of (and probably required to) reading it without the first (and therefor last) ()

I did not know that the space is optional though :P, good to know.

The copypaste part is like, everytime I make a regiserFunction, I just copypaste the 2 rows and fill with the number of args I need. A bit easyer then writing it all the time XD. And I know the e2function is better as it skips that, my point is that it is more confusing for people new to all this, hence why I did not understand it at all when I made my first e2 function (weld).


Also, that converter could help me alot, I have been planning of turning my constraint functions into e2function, but its so damn much. About the varaibles staying as rv# dont really matter to me, as the actual code is in a local function.

But is there any guide of how to add the description? Is it anyway to make it for a group of e2functions, or is it needed with 1 line each?

[TomyLobo]

[highlight=Lua]e2function return_type this_type:name(arg_type arg_name)
code
end[/highlight]

Syranide and actually planned to change the docs to list full type names
but that'd require us to change all of the existing docs and make some major layout changes.

yeah for some reason some people understand "copy paste here, insert coin here, push button, receive bacon" better than just learning what those things mean.
Also, did you check out the tutorial I wrote?
Wire Expression2 Extension Tutorial

I didn't quite get the last paragraph you wrote

[feha]

Heard of ctrl+r XD, would make changing stuff very easy XD.

And the reason copypasting is easyer to understand is because when I started there was no actuall guide. I checked in the e2 wiki for one, seems there is one now though, and I didnt think of searching on the gmod wiki instead :P. So all I could do to learn was reading others code, and then e2function were very confusing...

And for last paragraph, I meant the e2helper got descriptions, and I therefor wonder how you make those, I heard its e2function that got support for it, but never found the actuall code.

[TomyLobo]

well currently there is e2doc and there is e2helper descriptions
e2doc is for generating wiki documentation
e2helper descriptions are client-side. there still is no good way to get descriptions to the client, except making a client-side module solely for the descriptions