The purpose of this page is to inform future ZPE/YASS developers of how to write underlying code structures, that is, native methods in Java, and the conventions that have been established.
Conventions
First off, conventions. In ZPE/YASS, a convention is something that should be obeyed at all points of development when trying to make something work the way it should. It is the way in which things are normally done. ZPE/YASS has quite a few of these.
Native method returns conventions
When developing native methods, it is very easy to lose train of though and forget that ZPE variables can indeed store any value or any type. This was the case when ZPE first added images. Images themselves were returned from the native methods and then operated on afterwards. This lead to ZPE becoming far more procedural than object-oriented, and whilst it is a procedular language by origin, it seeks to expand it's object-oriented paradigm further by encouraging the use of objects. As a result of this, native method returns should be one of the types specified as a primitive data type of ZPE. Those are:
- String
- Number
- Boolean
- List
- Function
- Object
If a value, such as a Java BufferedImage
is to be used, wrap the value in a ZPEObject and provide native methods
to access it.
This is a long standing convention that should be obeyed at all ports of call.
Naming conventions
Whilst many programming languages favour camel casing, standard casing or dashed names, ZPE follows the underscore convention for naming. This means when creating a native method, adapting or creating a YASS-based library or producing a keyword, use the underscore convention. The general concensus is that camel casing is faster to write but harder to read. One of the key aims of ZPE/YASS is that the syntax is easy to read.
One such Quora post explains the general feeling that developers get when comparing the two which you can find here.
Naming is not a religion or even a rule for that matter, but for publicly available (such as ZULE) based code, it is an absolute requirement to the use of ZPE/YASS.
Compiling native Java libraries
ZPE/YASS is written in Java. This means it's core can be very easily extended by the use of modules and libraries. With time, this has got much better than when ZPE first introduced them. As a result it is now very easy to produce modular parts to the engine.
These parts, or libraries, must follow conventions too (there is more about how to create these libraries later). The main rule about these libraries is that when compiling them, they should be non-runnable JAR files which inherit or implement the library interface.
You can view a sample in the ZULE repository.
Submitting to ZULE
ZPE 1.7.6 allows you to submit code to the ZULE (ZPE Uploaded Library Extensions) repository straight from the GUI through the ZPE Online service. This feature is available to anyone who is a registered developer. Code on here will be verified by me (Jamie Balfour) before it is officially published.
For code to be successfully accepted, it must first meet all of the conventions and standards outlined in this document.
