Graal Forums

Graal Forums (https://forums.graalonline.com/forums/index.php)
-   NPC Scripting (https://forums.graalonline.com/forums/forumdisplay.php?f=8)
-   -   GraalScript2 (GS2) Coding Conventions (https://forums.graalonline.com/forums/showthread.php?t=86744)

cbk1994 02-12-2010 11:58 PM

Quote:

Originally Posted by WhiteDragon (Post 1555810)
What are you talking about?

There are lots of examples. You have opinions (such as indentation of switch statements) mixed with gospel truths (like a == b for comparison instead of a = b). This makes it unclear to new scripters what is fact and what is personal preference.

I apologize if anyone took offense to my original requests. I think this thread would be a good starting point for a new compilation of coding standards. Much of what is in this thread is very correct, it just needs to be reorganized with some of the more controversial stuff removed.

WhiteDragon 02-13-2010 12:07 AM

Quote:

Originally Posted by cbk1994 (Post 1555863)
There are lots of examples. You have opinions (such as indentation of switch statements) mixed with gospel truths (like a == b for comparison instead of a = b). This makes it unclear to new scripters what is fact and what is personal preference.

I apologize if anyone took offense to my original requests. I think this thread would be a good starting point for a new compilation of coding standards. Much of what is in this thread is very correct, it just needs to be reorganized with some of the more controversial stuff removed.

Okay, I'm glad we have the same central goal then.

I think the problem is where one draws the line between a personal preference and something a non-personal preference.

Technically, it is also a "personal preference" to not put 10,000 lines of whitespace between every function, but that is because it is my "personal preference" to be able to read my script without scrolling down the whole time.

If I only stated "non-personal preferences", I'd just be restating the GS2 grammar. RC already tells you when you screw that up.


So, where I draw the line is if a specific rule can be logically derived from certain core assumptions.


Naturally, a lot of things do come down to opinion here as to what the core assumptions are and which way to go, but the purpose of this thread is not to be the end-all guide for every scenario, but two things:
  1. A clear set of rules for quick reference.
  2. A walk-through to how these rules are derived to know when you can bend them.

Loriel 02-13-2010 12:40 AM

Quote:

Originally Posted by 12171217 (Post 1555837)
I remember reading in a certain release note that it had rewritten the TorqueScript bytecode interpreter from scratch and thus didn't require a lisence or something.

Would be interesting for someone to clear this up.

Stefan said there is no torquescript involved in gs2, he effectively made it from scratch.

Tolnaftate2004 02-13-2010 12:55 AM

Quote:

Originally Posted by WhiteDragon (Post 1555859)
Although that may be valid syntax (can't check right now), I don't see how that would run the function. My guess is that it would just execute:
Storing the function in a temp.suckawhat, which would evaluate to 0(?), then 0 would be stored in temp.example.

If that actually works I may have to hurt someone though since it literally makes no sense.

The engine replaces inline function definitions with a function pointer (e.g., "function_1"). The return value of assignment should be the rvalue, so temp.f = function_1 returns that pointer. It's no mystery why it works. The mystery is why it doesn't work the way one would want it to. :confused:

Probably has something to do with the way normal function are declared.

WhiteDragon 02-13-2010 01:46 AM

Quote:

Originally Posted by Tolnaftate2004 (Post 1555874)
The engine replaces inline function definitions with a function pointer (e.g., "function_1"). The return value of assignment should be the rvalue, so temp.f = function_1 returns that pointer. It's no mystery why it works. The mystery is why it doesn't work the way one would want it to. :confused:

Probably has something to do with the way normal function are declared.

Okay, I just tried it and it worked. That is a leap of logic I didn't make for the assignment operator to return the function pointer.

With this, you can also do:
PHP Code:

someOtherFunction(temp.= function (temp.y) { return temp.1; } ); 


But that is pretty nasty either way :pluffy:.


All times are GMT +2. The time now is 09:28 PM.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2026, vBulletin Solutions Inc.
Copyright (C) 1998-2019 Toonslab All Rights Reserved.