Provided that the syntax of this is actually like Lua, as in using keywords/tokens rather than square brackets, at symbols, colons, etc, I can see it being absolutely awesome.
Oh and one thing SquidDev, that does looks super neat, although Objective-C like properties are such a must-have. Essentially, that act like values, so, for example:
I'm trying to use keywords as much possible however I kinda want to reduce 'keyword' noise - so there aren't so many new keywords it is impossible to name a variable anything (think variables called klass in Java). I do want to distinguish between properties and fields, I do like C#'s way of doing it:
int Foo { get; private set; } // Implicit property which can only be set inside the class. Generates a backing field called _Foo automagically.
private int bar;
int Bar {
get { return bar; }
set {
Console.WriteLine("Setting bar to " + value)
bar = value;
}
}
I do prefer it to __setText however I'm not sure how that would work in a Lua style syntax. . An alternative would something like Java Beans' property - rewriting access to the field with get/set methods instead - though this wouldn't work if using Tua code outside Tua.
Also metatables/metamethods. Really not sure how to handle them. And Dan replied: wow! Thanks so much for you guys enthusiasm about this.
Yeah that's not bad, although as you said, I'm not so sure if it'd work with Lua, it'd possibly be a bit harder to implement too. At least based on the tiny research I've just done, it appears that JavaBeans requires you do only use functions for properties, or am I incorrect?
I think the most important aspect is to make it optional and also behave like a regular property.
Edit:I was feeling inspired, so I decided to create a fully functional getter and setter OOP example. I'm now really wishing I used this in Bedrock, would've made it sooo much easier.
You can take a look
here, I've commented the crap out of it, but I'm happy to explain anything. The actual usage is about line 180. It's basically just showing how I think it should work and want it to work, and also showing it's quite possible. Now, this code mightn't apply in the slightest when actually making the language, although I don't have a clue as I've no idea how that happens, but it might be helpful.
Here's a quick snippet:
Person = {
name = "Default Name", -- doesn't actually have to be set, but this acts as a default'
-- again, not sure about the naming convention here. the __ looked ugly really, although it did kinda make sense.
setName = function(self, name)
-- for example, let's capitalise the name
-- I'm not sure if returning or setting the name is better than this though (see the comment in __newindex)
self.name = name:sub(1, 1):upper() .. name:sub(2, -1)
end,
getName = function(self)
-- and then tack an underscore on the front for the sake of it
if self.name and #self.name > 0 then
return "_" .. self.name
end
end
}
local oeed = Person:new()
oeed.name = "oeed"
print(oeed.name) -- prints _Oeed
There were a few design choices I was unsure about, but now that I've spent a while making examples I'm a bit more confident with; open to changes though. I think the setName and getName style works well, it's not ugly unlike some of the others, it's really clear what it does and is also really easy to get the hang of. I chose to make it capitalise the first letter (so .name becomes .setName), sure this does allow for collisions, but who's using .name and .Name?
One thing I
did have in Bedrock was detecting when any value changed, I've also added this in. Basically there is a 'global' getter and 'global' setter. It's always called first before the specific one, it's optional naturally. If you return false as the first return value it will run the specific setter, true and it won't. This is a lot more useful than it might seem, most notably in the GUI element example, when you change ANY value (such as the text, background colour, etc) it lets you know and you can then invoke a draw. This means no polling or having to call a draw function!
So yeah, I think it's pretty sweet to be honest. One notably useful example I realised with the GUI stuff, with the American spelling you simply make a setter and getter for them and redirect it to the British version (or vice-versa if you're so inclined). Again, I would've loved to have used this in Bedrock. Although I've been taking a break from CC, if this language does get made I'm totally making another GUI framework (hopefully Dan's gfx API is real to!!!). I've already got a name for it :P/>