User:NXTBoy/Lua Issues: Difference between revisions
>NXTBoy No edit summary |
m Text replacement - "</code>" to "</SyntaxHighlight>" |
||
Line 1: | Line 1: | ||
== Naming Inconsistencies == | == Naming Inconsistencies == | ||
Casing on Object and class members seems to be arbitrary. Some members, like <code>Ray.Origin</ | Casing on Object and class members seems to be arbitrary. Some members, like <code>Ray.Origin</SyntaxHighlight> are UpperCamelCase, while others, like <code>Vector3.x</SyntaxHighlight>, are lowerCamelCase. At present, there seems to be no logic behind this whatsoever, and its leads to messy and error-prone code. The there are the members like <code>Instance.getChildren</SyntaxHighlight>, which are valid in both casings with no clear documentation on which one is deprecated. | ||
Instead, a convention should be adopted. This could take the form of: | Instead, a convention should be adopted. This could take the form of: | ||
* Members of <code>Instance</ | * Members of <code>Instance</SyntaxHighlight>s are always of the same capitalization | ||
* Members of lua data objects, such as <code>CFrame</ | * Members of lua data objects, such as <code>CFrame</SyntaxHighlight> and <code>Vector3</SyntaxHighlight>, are always of the same capitalization | ||
== Draconian error handling for absent object properties == | == Draconian error handling for absent object properties == | ||
<code>Part.ChildThatMayOrMayNotExist</ | <code>Part.ChildThatMayOrMayNotExist</SyntaxHighlight> current returns an error if <code>ChildThatMayOrMayNotExist</SyntaxHighlight> does not exist. It would be generally easier to handle if a nil value were simply returned. To aid new scripters, a warning could be issued in the command bar. This should be extended toward every object that currently throws a error when an unset value is retrieved. | ||
== Inability to type check Vector3s, Rays, CFrames, etc == | == Inability to type check Vector3s, Rays, CFrames, etc == | ||
Line 22: | Line 22: | ||
print(object.TYPE == Ray.TYPE) --Safe even if object doesn't have a TYPE member. In this case, though, it should | print(object.TYPE == Ray.TYPE) --Safe even if object doesn't have a TYPE member. In this case, though, it should | ||
</pre> | </pre> | ||
This would allow custom user-made objects to follow exactly the same standard. The second would be to extend the built in <code>type</ | This would allow custom user-made objects to follow exactly the same standard. The second would be to extend the built in <code>type</SyntaxHighlight> function to return a string representing the roblox lua object if the object is of type userdata. | ||
== (Lack of) Modularity == | == (Lack of) Modularity == | ||
Line 33: | Line 33: | ||
* Create a new type of script called LibraryScript | * Create a new type of script called LibraryScript | ||
* When the place loads, run ALL the scripts in the library service on both the client and the server. Would be good if global variables could be synced as well | * When the place loads, run ALL the scripts in the library service on both the client and the server. Would be good if global variables could be synced as well | ||
* When a script requires a library, add a <code>require "geometry.MyAwesomeNewVector"</ | * When a script requires a library, add a <code>require "geometry.MyAwesomeNewVector"</SyntaxHighlight> to the top. This will delay the scripts execution until the corresponding library is loaded. If all libraries in the ScriptLibraryService have been loaded, and it is still not found, then error |
Revision as of 03:12, 27 April 2023
Naming Inconsistencies
Casing on Object and class members seems to be arbitrary. Some members, like Ray.Origin</SyntaxHighlight> are UpperCamelCase, while others, like
Vector3.x</SyntaxHighlight>, are lowerCamelCase. At present, there seems to be no logic behind this whatsoever, and its leads to messy and error-prone code. The there are the members like
Instance.getChildren</SyntaxHighlight>, which are valid in both casings with no clear documentation on which one is deprecated.
Instead, a convention should be adopted. This could take the form of:
- Members of
Instance</SyntaxHighlight>s are always of the same capitalization
- Members of lua data objects, such as
CFrame</SyntaxHighlight> and Vector3</SyntaxHighlight>, are always of the same capitalization
Draconian error handling for absent object properties
Part.ChildThatMayOrMayNotExist</SyntaxHighlight> current returns an error if ChildThatMayOrMayNotExist</SyntaxHighlight> does not exist. It would be generally easier to handle if a nil value were simply returned. To aid new scripters, a warning could be issued in the command bar. This should be extended toward every object that currently throws a error when an unset value is retrieved.
Inability to type check Vector3s, Rays, CFrames, etc
At present, there is no easy way to tell what type a parameter is if it is one of the Roblox lua types. The standard trick of comparing metatables doesn't work because they're all set to something along the lines of "Metatable protected".
There would be two ways I can see to implement a fix to this. The first would be to simply add this:
Ray.TYPE = {} -- Create unique pointers, i.e. through table declarations
CFrame.TYPE = {}
Vector3.TYPE = {}
local object = Ray.new(...)
print(object.TYPE == Ray.TYPE) --Safe even if object doesn't have a TYPE member. In this case, though, it should
This would allow custom user-made objects to follow exactly the same standard. The second would be to extend the built in type</SyntaxHighlight> function to return a string representing the roblox lua object if the object is of type userdata.
(Lack of) Modularity
Currently, modularizing a script is much harder than it should be. There are a couple of things that hinder this:
- LocalScripts vs Scripts - If one wants a utility function to exist on both the client and the server, then two identical scripts must be created, and put in different types of Script in different places. Clearly, this is bad for maintainability
- No tidy way to require a library be loaded before running a script
In my opinion, the solution to this would be:
- Create a service in DataModel for storing library scripts, sorted hierarchically into "Packages"
- Create a new type of script called LibraryScript
- When the place loads, run ALL the scripts in the library service on both the client and the server. Would be good if global variables could be synced as well
- When a script requires a library, add a
require "geometry.MyAwesomeNewVector"</SyntaxHighlight> to the top. This will delay the scripts execution until the corresponding library is loaded. If all libraries in the ScriptLibraryService have been loaded, and it is still not found, then error