Over the past few days, I have been developing a new documenting/properties language: #ZML
##What is ZML?
ZML is a settings/documenting language. It is easy to read, write, parse, encrypt, and compile*. ZML is purely trying to make the user able to type as many lines as possible, as fast as possible.
What does it look like?
Here’s an example:
string name = John McKellen;
int age = 46;
float money = 120924.4810249;
string initials = J. McK.;
string personal_description = John was a scientist,
he was hooked on LSD;
## This is a rendom comment
## *random
What to use it for?
You could, for example, use it for making a game where you want player to be able to set settings outside the game, or for saving your settings in a separate file.
Easy settings, for if you are making a game where you want player to be able to set settings outside the game.
Or for saving your settings in a separate file.
I was kinda developing this for own use, but decided to post a thread about.
I’m not sure if this is something that I’ve been missing, but I had a quick look at the code etc and I assume that you want some feedback.
You need to be able to escape strings, so that they may contain semicolon and equals sign, etc. I didn’t look how you handle binary data, but hex is usually easier to write, but base64 use less space.
I suppose that declaration of data types may be nice since it tell you how you should write your data, but I would skip that and let the program transform the data to the appropriate data type. You may otherwise get into a situation where the user write a string in your file, but you want it as an integer. (I’ve now more or less transformed this into JSON, without object hierarchy)
Never return HashMap, ArrayList etc from your method calls, use interfaces such as Map and List, especially when you’re writing a framework.
I suppose that you have a test program or something, but a library like this should be tested with JUnit, and I recommend to setup a Maven project instead of Ant, and you should not submit your Eclipse project files. You ant properties file contains local path on your harddrive.
Thanks for some feedback, and yes, I do take it as positive criticism.
Yes, those are indeed necessary, and I will implement them as soon as possible.
I understand your argument, but I don’t think it’s necessary. The type is just a reference point, not changing the actual string value.
When typing int five = 4;, the parser creates a Field containing the type (an object), the name (a string), and the raw value (a string). The value is only determined when the method .getValue() is called. To get the raw string, use method .getRealValue().
What I think you are suggesting is that a user might want different types than the basic data types, and thus parsing the value differently. I was already prepared, and made Type fairly dynamic. You can add your own types and parsers. E.g.:
person john = John McKellen|46;
Woops, forgot to do that! Thanks for pointing out.
Yes, I do have a test program, but I have not used JUnit, just standard logging.
That Ant project was just a test, I didn’t realized it was still there. I will probably make a Maven repo out of it.
The Eclipse project is still there as a remainder of some tests, that almost went horribly wrong.
I don’t know if it’s a good idea to have types in a configuration file, those files are supposed to be editable by non-developer players that might not know the difference between a float and a double…
So i would say you could replace all of them with number and read them as Number objects in java, but then you would have only strings and numbers, and this would make all the type-thing unnecessary.
Another thing: Am i seeing wrong or the repo has no license? If so, this means you are the only one allowed to use the code.
Not to pile on, but what strong advantage does this have over the other config libraries that do similar but are less restrictive re: types? And if you want a type-based config language then what does this provide over the javascript interpretter already built into the VM. (I’ve used it on other dayjob projects before… though we had slightly different requirements.)
I mean the nice thing about your own format is I guess you can do whatever you want with it. It also “feels good” to work on something that is relatively easy and well-defined… (though that’s a trap because it becomes more fun to write frameworks than to actually get real work done on your game). The down side of your own format over something like JSON is that there won’t be any existing editor support anywhere.
@david_bernard_31 Using an existing language is always less fun than your own
@Domenic Yes, you can create your own types, so you can use anything you want.
@RiccardoBlb 1. Types are the main ‘pillar’ of this language. However, you have a good point. I will probably add a “number”, and change “string” to “text”. I will still leave in the data types, in case anyone needs that.
2. Yes, the project had no license. I just wrote a small license for that. Thanks for pointing out.
@pspeed The strong advantage is that anyone could make their own parser, that was one of the goals for the language. Else you have to add code to your program to change/read values correctly. For example, I could add a “color” type by just typing the line: new Type("color", "color", new ColorController()); and create a ColorController class that implements Controller. The language/parser that I have seen get the closest to this was the YAML parser YAML Beans, that automagically transformed .yml to a class.
Not looked at code yet.
Just a question came to my mind.For encryption purpose are you using standard encryption methods or the interface allows anyone can have his own encryption method?
I have not yet implemented encryption and compilation,
but I am planning to do encryption by just adding/subtracting the key.
The formula for encryption is: x = c + k, where ‘x’ is the encrypted char, ‘c’ is the original char, and ‘k’ is the key.
Encrypting “hello” will result in “Jgnnq”.
It is very basic encryption, but already it’s almost unbreakable.
Maybe I will use a harder encryption formula, like x = c*k-1.
You can do a lot with encryption, so I will search an easy and effective method.
Your question made me think about using an interface, which might be more fun. I could also make like a Encryptor interface, with a encrypt() and/or decrypt() function. Then you could make code like:
new Encryptor() {
public String encrypt(String s) {
//Etc.
}
public String decrypt(String s) {
//Etc.
}
}
Yes, you should put the encryption in an interface.
Java has a lot of different encryption methods that are built in. Encryption is a higher school of programming and math, and there are a quite amount of doctors and professors only doing that kind of work; just saying
I guess that happens to me all the time. But to my defend: I just want something I can program mainly during my train ride to the company I work and back home. Instead read a books. And I like programming better than play games
Finishing things is hard
Anyway this language looks pretty similar to YAML btw. (I had to define a config recently in YAML for the company). I do not yet see the real benefit as YAML looks also pretty human readable…
Is it just me or am I missing something? What’s the benefit of this again??? Config file parsers have been done a million times. Personally I have never needed anything beyond a simple key value pair file for non technical end users to configure … and if the end users is technical at any level then there are a ton of options … all mature, all extremely easy to use … and all supported and tested for 1-2 decades. Why re-invent the wheel here??
My experience with using YAML was great, but parsing it was very frustating. First of all, you have no idea what parser you need, and the parsers you can find are really old (thus making it’s productivity suspicious). I also can’make my own parser, because of stuff like this:
--- !<tag:clarkevans.com,2002:invoice>
invoice: 34843
date : 2001-01-23
bill-to: &id001
given : Chris
family : Dumars
address:
lines: |
458 Walkman Dr.
Suite #292
city : Royal Oak
state : MI
postal : 48046
ship-to: *id001
product:
- sku : BL394D
quantity : 4
description : Basketball
price : 450.00
- sku : BL4438H
quantity : 1
description : Super Hoop
price : 2392.00
tax : 251.42
total: 4443.52
comments:
Late afternoon is best.
Backup contact is Nancy
Billsmer @ 338-4338.
I find that using these indents for values within values is too complicated to parse. Thus ZML only has one line-“dependant” aspect, which is the comment (## at the start of a line ignores the whole line). If you want, you could also type the whole file in one line.
This makes no sense to me. For a well established format, parsers reach a state of indefinite stability and require no further changes. I have a JSON parser that’s like 10 years old or more and hasn’t need a single change in 8 years because it reads all JSON perfectly.
It’s the parsers that have updates all the time that you need to worry about.
This is also strange. I’m not sure why indents are better/worse than any other delimiter as far as parsing goes. If leading spaces are significant then they’d get a lexer token like any other special character(s).
YAML’s pretty easy. I think someone could parse each line with a single regex even and pull everything they’d need out of the groups.
