User:NXTBoy/Lua Issues

Naming Inconsistencies

Casing on Object and class members seems to be arbitrary. Some members, like Ray.Origin are UpperCamelCase, while others, like Vector3.x, 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, 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 Instances are always of the same capitalization
• Members of lua data objects, such as CFrame and Vector3, are always of the same capitalization

Draconian error handling for absent object properties

Part.ChildThatMayOrMayNotExist current returns an error if ChildThatMayOrMayNotExist 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 function to return a string representing the roblox lua object if the object is of type userdata.

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" 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