![[de]](/mwf/flags/de.png "Germany")
Almost a year ago, there was a discussion about the introduction of the long ids. At that time, we switched from the old 4-character CLNK IDs to the new variable Clonk IDs. IIRC we agreed that the IDs from the object definitions should have a prefix to distinguish them from (other) variables. But an agreement is worth nothing if nobody implements it. So this is what happened for that:http://bugs.openclonk.org/view.php?id=184
So we have two alternatives now,
1. just drop it or
2. someone is found that implements that
I wouldn't mind a drop btw since it didn't turn out that variables do clash with IDs because the naming scheme for variables always starts with a small letter.
IDs do clash with functions though, still I am not for intrucing the :Id.
It's just a naming convention. You can also replace that ":" by "_" for example (or "ID_").Real namespaces on the other hand.. :)
I'm not going to artificially separate IDs and global constants at this point, but I'd like to allow additional characters in identifiers. Making the namespace bigger is the simplest method to avoid clashes :-)I think we can use :. $ is used by other languages, and disabling string table stuff outside of strings is on the agenda already. Any suggestions for other characters?
![[ca]](/mwf/flags/ca.png "Canada")
Is # used anywhere yet?
§° (Do other keyboards have that?)
Where do we use . by the way?
Personally, I don't like the Idea of using all those special chars in identifiers. I'm used to [a-z0-9_] and I think changing that would have a bad effect on the readability.
Where do we use . by the way?
Personally, I don't like the Idea of using all those special chars in identifiers. I'm used to [a-z0-9_] and I think changing that would have a bad effect on the readability.
> Personally, I don't like the Idea of using all those special chars in identifiers. I'm used to [a-z0-9_] and I think changing that would have a bad effect on the readability.
I agree with you. I think this hasn't been a problem so far, and when allowing more characters in identifiers then we restrict the options we have when introducing new features to C4Script syntax, such as proper namespaces.
How about we only allow ::, but only if preceded and followed by at least one more other character?This would allow identifiers like MyAddon::Clonk. If namespaces are introduced at some later point, it will still be compatible, but point to an identifier within a namespace.
Neither § nor ° are on my keyboard :(Standard US English keyboard I think.
Allowing : in identifiers would create ambiguities with the array slicing syntax:
var array = [1,2,3,4,5,6];
var foo = 5;
var :foo = 3;
array[:foo] // array[3] or array[:5]?
![[pl]](/mwf/flags/pl.png "Poland")
Perhaps make them optional, but proper namespaces.
By default, the namespace would be NameOfModule::NameOfObject, but could be specified to be other.
When not using a namespace in name of object, it first checks in module the mission/map is in, then in modules used by the mission/map, then in main module, and finally in other ones.
This way nobody would even have to write them in order .
As for a prefix, I don't think it would be useful. Just check if the name contains double :'s, perhaps adding a prefix when compiling scripts into bytecode/IR.
Btw, does OC use JIT compilation?
If not, then some of you might find this to be of interest: http://llvm.org/docs/tutorial/
I didn't read it yet, but I intend to.
By default, the namespace would be NameOfModule::NameOfObject, but could be specified to be other.
When not using a namespace in name of object, it first checks in module the mission/map is in, then in modules used by the mission/map, then in main module, and finally in other ones.
This way nobody would even have to write them in order .
As for a prefix, I don't think it would be useful. Just check if the name contains double :'s, perhaps adding a prefix when compiling scripts into bytecode/IR.
Btw, does OC use JIT compilation?
If not, then some of you might find this to be of interest: http://llvm.org/docs/tutorial/
I didn't read it yet, but I intend to.
I have actually already looked at and built LLVM, but the resulting libraries are too large for my taste (we're talking about roughly doubling of the size of the executable).
Well, but you can't say that having all the scripts JIT-ed(and thus much faster) wouldn't be pretty cool :>
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
