Thinking of object orientation
Posted: Fri Jul 20, 2012 7:16 am
Hello everyone,
I've seen that you are designing the core and the API. We all know how EventScripts worked - and of course we like it.
But EventScripts was contaminated with the old EventScripts Shell language (this is not being ment negative). And now you have the chance to stop thinking of old behaviours and patterns.
Why do you agonize about userids, steamids, client indices, serial numbers when they ALL express the same thing: a player. And a player is an entity, even when it's a very specialized one. What about to forget that there are different ways to identify the same object? That is against typical oop patterns and does not promote the simplicity of python.
What I want to say: forget about event variables like userid, steamid. Think of passing objects to the callbacks. Think of accepting entity / player objects only to API functions.
It would make the life so much easier here. Every entity has an index and a serial number. It's perfect, since every player has the same attributes. You are perfectly allowed to derive a player class from an entity class.
This is - in my opinion - the great chance to be better than EventScripts and even than SourcePawn (I do not speak against the SourceMod community and their developers here!).
I do hope you get my point and you guys may start a discussion here ;-)
Chris
I've seen that you are designing the core and the API. We all know how EventScripts worked - and of course we like it.
But EventScripts was contaminated with the old EventScripts Shell language (this is not being ment negative). And now you have the chance to stop thinking of old behaviours and patterns.
Why do you agonize about userids, steamids, client indices, serial numbers when they ALL express the same thing: a player. And a player is an entity, even when it's a very specialized one. What about to forget that there are different ways to identify the same object? That is against typical oop patterns and does not promote the simplicity of python.
What I want to say: forget about event variables like userid, steamid. Think of passing objects to the callbacks. Think of accepting entity / player objects only to API functions.
It would make the life so much easier here. Every entity has an index and a serial number. It's perfect, since every player has the same attributes. You are perfectly allowed to derive a player class from an entity class.
This is - in my opinion - the great chance to be better than EventScripts and even than SourcePawn (I do not speak against the SourceMod community and their developers here!).
I do hope you get my point and you guys may start a discussion here ;-)
Chris