[Gryphus One]

Quote:

Originally Posted by Ceathor What I like to do, or rather, what I try to do, is to make different files for different parts of the gamemode. As Y_Less said, not sorting the books by color, but by topic. Some of the files that I include back into my main gamemode are: - Initiation - User initiation - User damage things - Vehicle purchase things - Vehicle damage things Well, basically, new file for a new feature. If I for instance decide to create a new feature that allows users to purchase and place furniture, I would make a brand new file for this feature on its own. That way everything is easy to edit, and the file for a quote on quote _bugless_ feature that I do not want to alter does not have to be opened at all. Of course I sort things into different folders and such, but that's the main point of it all anyway.

Except folders, that's what I too do.

Quote:

Originally Posted by [HLF]Southclaw I read some really neat articles on "Leaky Abstraction" check them out: http://www.joelonsoftware.com/articl...tractions.html http://www.claire-blackshaw.com/blog...-abstractions/ I think they will tie in pretty well with this thread. tl;dr? The concept discussed in the articles is basically about abstracting too far or unnecessarily from the fundamentals and the complex problems "leaking through" to the simple layer on top and causing more problems that the developer using the simple method has no idea how to address. Here's a SA:MP example where IsPlayerInAnyVehicle is just a glorified vehicle ID validation check (I don't actually know the internals of this function, this is hypothetical). You run a loop and check IsPlayerInAnyVehicle then if they are, GetPlayerVehicleID and do something. But you may as well just get the vehicle ID on every iteration and just check if it's valid thus only calling one function instead of two that pretty much do the same thing only one returns a normalised result. Another example of the second point: I am using YSI to develop a higher level player-interaction library, SIF. If I upgrade to YSI 4.0 because I need a feature that is only in YSI 4.0 and y_hooks breaks while Y_Less is on holiday, I am completely stuck as I have no idea how y_hooks works or how to fix it.

I have read the first article: well, it's obvious that abstractions can simplify things but cannot do miracles (like the examples of TCP when a snake chews your network cable or having to drive more slowly when it's raining). Apart from that, the article tells us that we must learn how abstractions work and the things they abstract away, but with that reasoning we sa-mp scripters would have to learn binary code just in case abstraction layers like Pawn start leaking.

I have also read the second article and well, I understand its point in the example of calculating the position of a point from a plane and using two functions when only one was enough, but then, must we know exactly all the internals of every single function from every single abstraction layer we use? progress in hardware, with more and more CPU, memory, graphics and storage resources available, improved energetic efficiency, longer lasting batteries and decreasing prices, should all compensate by far that loss of code optimization brought by the increased number of layers. In fact in that article there's a comment which shows what Y_Less said in this thread: sometimes readable code being better than fully optimized but harder to understand code.
Here in sa-mp scripting we have a clear example with file scripts: Dini is an abstraction layer for sa-mp's raw file functions and it's slower, but much more usable than those. Y_ini is another abstraction layer, and while more optimized than Dini, it's also harder for the scripter.

I think your example about IsPlayerInAnyVehicle and GetPlayerVehicleID, although somewhat similar to that of the article about the point and the plane, has more to do with the scripter not thinking well than with the abstraction layers themselves, because in this case you can easily know that GetPlayerVehicleID itself is enough to tell if a player is in a vehicle.

Your example about upgrading to YSI 4.0 and something breaking, reminds me of a thread I read about sa-mp not upgrading to a newer version of Pawn so some "hacky" things won't stop working.