[Ash.]

Quote:

Originally Posted by ****** Beside the PVar point, that's actually quite a bad argument (in a nice way) for anything. The point of a library like this is to abstract away details and hide them from the end-user. Honestly they shouldn't need to know that you store the data in PVars, it could be sent via HTTP to a remote server for all they care (though I wouldn't recommend that). Anything like that is internal to your code and where possible shouldn't be seen from the outside, as doing so can cause problems in the future. For example "foreach" creates a number of variables for each iterator created, but I don't document them and I don't explain them. People should only be accessing them through the interface provided so that if and when I choose to update the library and find that the internal representation needs to change, it doesn't matter. If, however, they have used the variables directly and I change something which they shouldn't have been interacting with, their code will break.

Hmm I see; however with something as simple as this I don't think that changing of the internals will happen; And changing a name wouldn't make much difference. However I can see where your points would be true in other scripts. But, to be fair: If they are interacting with the variables as they shouldn't, it's really there own problem.

Quote:

Originally Posted by ****** In "C++" "inline" functions are brilliant for this sort of thing as you can declare variables as private to one section of code, but still use them directly in other parts in a controlled manner. "C#" getters and setters also try and encapsulate this idea, but I'm less of a fan of them. They're local variables - they can't clash with other local variables. The only thing they could clash with is globals, but frankly if people are using globals with names like that it's their own fault if it causes clashes! Having said that, I'm a little worried about the new version of YSI for this reason as a new technique I have for advanced macros dictates the use of short names to improve flexibility - I'll have to do something about that! I hope you see this as useful instruction in the wider area of programming rather than critisism of this one library, it's not.

Yes, they're local but could clash with global variables; which is why I named them the way I have. I've played with C++ before, and I quite favour the way that works too, C# has and is always picky about the way things are done though. And yes, you may need to play with YSI if that is going to happen!

Everything you say is really helpful; and your criticism is always constructive anyway; I can see many ways what you have said can apply to PAWN and other languages, as well as single libraries.

Thanks,
Ash