![[de]](/mwf/flags/de.png "Germany")
One thing that I don't like in OC is the
1. the splitting into Objects, Effects, Particles, Players
2. that there are not enough object types (for every helper object)
maybe we could solve the problem through a real object oriented programming.
If you want to see examples (object oriented script language with operator overloading) just look at http://gwx.bitfarmclan.de/hg/
I think, a modern Game should have a modern script language.
1. the splitting into Objects, Effects, Particles, Players
2. that there are not enough object types (for every helper object)
maybe we could solve the problem through a real object oriented programming.
If you want to see examples (object oriented script language with operator overloading) just look at http://gwx.bitfarmclan.de/hg/
I think, a modern Game should have a modern script language.
...what? - is what I thought first, well:It is more or less planned(?) (at least?) to be able to represent players via proplists and access player attributes that way. For particles and effects: I don't know whether changes there would help a lot. If you think so, why?
Having proper effect-local variables would certainly make effect programming a bit easier.
Well, indeed.But that could even be changed without changing the OOP system. For example the effect-functions could not get "pTarget" and "iEffectNumber" but get "pEffect" which is a proplist with all the necessary informations. pEffect["number"] and pEffect["target"] for example. And since that would be a normal proplist, you could even add new local Effect variables using pEffect["myvar"]=abc; - or pEffect[0]=abc;
Could you be a bit more specific? And by a bit, I actually mean, "a lot more specific". What I basically read in your text, no offense, is"Objects, effects, particles and players suck and are totally not OOP. GWX-Script pwns C4Script because it is also obsolete. Just browse through all our source and you will see. Have a good day."
Here is a specific link to some example scripts. It is planned to abstract Scenarios, Object Packs, Helper Objects and conventional objects to Classes.
http://gwx.bitfarmclan.de/hg/?mf=f7b94011fa7b;path=/packs/Objects/logic/;style=gitweb
It is faster for us to enable operator overloading because we can abstract Operators to functions and use the +operator for strings, ints and floats.
http://gwx.bitfarmclan.de/hg/?f=54907fde065c;file=packs/Objects/logic/engine;style=gitweb
My idea is to not store just one object in one scriptfile but having a lot of definitions in one script file or spread a single object definition over a lot of files (to structure it)
http://gwx.bitfarmclan.de/hg/?mf=f7b94011fa7b;path=/packs/Objects/logic/;style=gitweb
It is faster for us to enable operator overloading because we can abstract Operators to functions and use the +operator for strings, ints and floats.
http://gwx.bitfarmclan.de/hg/?f=54907fde065c;file=packs/Objects/logic/engine;style=gitweb
My idea is to not store just one object in one scriptfile but having a lot of definitions in one script file or spread a single object definition over a lot of files (to structure it)
And how would that make things easier for the scripters? I cannot see the benefits at at first glance
It would be more abstract, espeacially the overloading possibilities that can replace append- and include commands.
Well, that does not give an answer to my question in m opinion. So the only benefit would be that you can inherit from an object A (that inherits from object C) and disabling the higher inheritance to object C?
Object Oriented Programming is a through-thaught idea and leads to a better, more abstract programming style. It leads you to write like you speak with a human.
I could read the wikipedia article about OOP as well (though, im quite familiar to the concepts already). I'm going to repeat my question: And how would that make things easier for the scripters? I cannot see the benefits at at first glance(from)
![[se]](/mwf/flags/se.png "Sweden")
I would actually agree. Complete OOP orientation is a well known good way of structurizing programming languages. All modern ones are always almost completely OOP. Why it would be better is not so easy to answer directly to. However you should realize it yourself if you ever have worked in a complete OOP oriented environment VS a non complete OOP oriented environment. It would surely open up for more innovative and general ways of scripting compared to stumbling over old non modern concepts that gets in the way of what you would like to create. =) OOP for the win.
Right, OOP is good.But C4Script is a scripting language and I think one main aspect of scripting languages should be to make developing (or getting into the language) as easy as possible (even for people who have no experiences with other programming languages).
With proplists we have already made one huge step into the - at least - pseudo-object-direction.
Right now I cannot imagine anything I would need that couldn't be done using proplists
Well then it is an issue of balancing it between nice for new scripters VS nice for experienced ones. I would go for the latter. Anybody who is motivated and interested is able to learn. Scripting is also quite light weight introduction into programming OOP or not. Here at my university, the introductionary course is held in python and absolutely most people can handle it. Even though it is very OOP. Being unexperienced is only a temporary stage. You either quit or learn, so focusing in making that stage easy when it causes the static stage more nasty is not the way I would go at least. :P Sure, you might lose one or another scripter if it is more complicated, but those can not have been so motivated in the start then.
And it is not really about what you can or not can do. Most could already be done in CR's scripting. It is more about making stuff easy to do. PseudoOOP is just a hindrance when you work IMO.
And it is not really about what you can or not can do. Most could already be done in CR's scripting. It is more about making stuff easy to do. PseudoOOP is just a hindrance when you work IMO.
>when it causes the static stage more nasty is not the way I would go at least.
Well, does it? What kind of feature would you like? Maybe I just don't understand the necessity yet. :)
OOP is not harder, it's easier, see Java.
You just write what you want to say:
I know it's hard to implement when the old code is not OOP, but it could be a challenge.
You just write what you want to say:
Rock.Explode(1000) is easier to understand and more intiutive than Explode(1000,Rock)I know it's hard to implement when the old code is not OOP, but it could be a challenge.
![[us]](/mwf/flags/us.png "United States")
In OC you write
I think what I'm missing in this thread are concrete suggestions. Currently I only see "Let's make everything more OOP!!".
Rock->Explode(1000).I think what I'm missing in this thread are concrete suggestions. Currently I only see "Let's make everything more OOP!!".
1. We replace #include and #append through a class inherition system
2. Not every Object contains Vertives, OCF, etc., ther should also be abstract classes like Arrays (abstract them...) for making it easier to have helper objects without overhead
3. OCFs are replaced through an inheritance system: a Rock is a descendant from a "Collectible" etc.
and some other things that result from these things
2. Not every Object contains Vertives, OCF, etc., ther should also be abstract classes like Arrays (abstract them...) for making it easier to have helper objects without overhead
3. OCFs are replaced through an inheritance system: a Rock is a descendant from a "Collectible" etc.
and some other things that result from these things
OCFs are a performance optimization - that's certainly the last thing we want to do in Script. Using "IsClonk" and friends already works fine. It is in fact even more general than subtyping. which you shouldn't confuse with inheritance, btw, as "IsClonk" already makes good use of inheritance *nitpick*.
I don't know what VTables are supposed to be, but it's very hard to beat one bitwise Or per object.
A VTable is a list of functions for a object. You specify a function by its index. When a class is overloaden, the VTable has an other content at the same index. It's good for virtual overloading.
Sounds pretty close to how Find_Func works right now. But Bit-Or is certainly still faster...
Yes, but you have 32 bits in OCF and that's not enough for all Statements like "IsFood()" etc.
Which doesn't mean that it isn't a good thing to have for those 32 OCFs there are currently. Maybe we could unify the interface, but I don't see a reason to touch the underlying mechanics.
Yes, to keep the speed, we could left both but move some non-critical OCFs to script (i'm thinking of burning things)
Bit-OR is certainly faster for the check; but it's an additional state that needs to be kept updated - in some cases every frame for every object.
>2. Not every Object contains Vertives, OCF, etc., ther should also be abstract classes like Arrays (abstract them...) for making it easier to have helper objects without overhead
Wouldn't it be enough to be able to store functions (or function pointers) as variable values? For example in proplists? Then you could also build abstract classes (already with the current system)
Yes, but the solution with VTables is more efficient..
But if you want, we can introduce function variables that are used in proplists.
But if you want, we can introduce function variables that are used in proplists.
That is an implementation detail. I don't think it's important for the current discussion.
> Yes, but the solution with VTables is more efficient..
No, it isn't. :-)
A Proplist has a complexity of O(log(n)) to access an element. A VTable or a fixed element position in a class definition could be accessed with O(1).
No, you're wrong. In fact, C4PropList can even be faster because it needs less memory if there are lots of empty slots.
Why not at least replace -> with . if it is gonna be even more used? . has no function in C4script afaik and it is much easier to write, not to mention more common.^^
"." is being reserved for if we have "real" OOP one day, afair
Didn't you say up there that switching to "real" OOP was unprofitable and wasn't gonna happen? xD Or did I miss something? :S
>Didn't you say up there that switching to "real" OOP was unprofitable and wasn't gonna happen?
Nope, I just said that I think we won't need it. ".-reserved-for-oop" is the reason someone (Guenther/Isilkor?) told me the last time
I am in for it. Please do it you. More people listen to almighty sven2 than poor odd zagabar. xD
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
