[SnoW]

Originally Posted by 01101101 Oh lol examples weren't intended to be rude, just random names. You are saying you already noticed how it works, but at the same time you say it is still better to include part of the core. Why? The only difference I see is that AMXX STUDIO or whatever you use will take shorter in function shortcutting. The only difference I found from including something and not, is this #pragma reqlib #pragma library #pragma loadlib Which will add a really few bytes to the header. So, I ask you, which is the benefit obtained from including just what you need? [sarcasm]Oh, and by the way, if you are running amxmodx on a 64kb memory machine and you want to save those bytes you can remove that from all module includes, since the only thing it does is autoenabling modules.[/sarcasm] And by the way, even if you used just 1 function from fakemeta you should keep that stuff for autoloading modules.

I actually expected you to reason your opinion and how it's wiser to include the whole core rather than providing me information how it's better to not.

As of you can say that the compiling time and those couple of bytes don't matter, I could for example compare this to readability. Including something more specific tells attentively what the plugin requires. It for example tells to sa-mp people that my float system can be used in their pawn enviroment as well and doesn't need amxx.

[Exolent[jNr]]

Including the whole core is much more readable than going through the core and finding which includes you would need based on what your plugin uses.
My reasoning is that by including the core include, people will easily know what modules are loaded from looking at the code.
Then there are some includes that don't require modules, and they ask "what is the <xs> module?" and everyone tells them it is just an include file and has no module.

If there were to be any drastic update to AMXX that caused include files to be changed except for the core, the plugins would be broken.
Just because updates to AMXX are almost never going to happen anymore, doesn't overrule my previous statement.

As for your "float" code that would look amxmodx-dependent, you can easily convert any code snippets to any other language.
The natives/functions/defines you use from the amxmodx package are all documented with descriptions/values.

If you include something just like <float> or <string>, some people may be confused because I have yet to see a scripter here include a subsection of the amxmodx include.
So if they already have amxmodx included, it would be redundant and unnecessary to add float or string includes.

Including more individual sub-core includes is much less readable than including the whole core.
That's comparing 4 basic module includes to 12 sub-core includes.
The only situation where I have found your reasoning to be useful is when I needed the hlsdk_const include but did not need engine or fakemeta in my plugin.

[SnoW]

Originally Posted by Exolent[jNr] Including the whole core is much more readable than going through the core and finding which includes you would need based on what your plugin uses.

If you are referring that it takes more work for a plugin creator to look into core and see what he includes instead of including whole either. You can't compare the work of the people who don't know about "cellarray" to the information it provides, since it's all extra core, that isn't the case. Obviously you should include the whole core if you don't right up know that you need only one specific sub include. You naturally do it only if it doesn't take extra work.

If you are referring that a reader of a ready plugin doesn't regonize an include part of the core for example "cellarray", there's no logic when including amxmodx provides no information.

Originally Posted by Exolent[jNr] My reasoning is that by including the core include, people will easily know what modules are loaded from looking at the code. Then there are some includes that don't require modules, and they ask "what is the <xs> module?" and everyone tells them it is just an include file and has no module.

That is like using an old and slow native just because it's better known than the new faster one. Making the code readable is different thing than not coding with an efficient way to provide information to people they should know.

Originally Posted by Exolent[jNr] If there were to be any drastic update to AMXX that caused include files to be changed except for the core, the plugins would be broken. Just because updates to AMXX are almost never going to happen anymore, doesn't overrule my previous statement.

I believe you can overwrite the word "almost". But you are right generally even how unlikely it is generally as well.

Originally Posted by Exolent[jNr] As for your "float" code that would look amxmodx-dependent, you can easily convert any code snippets to any other language. The natives/functions/defines you use from the amxmodx package are all documented with descriptions value

I actually meant that it can be used just like that as sa-mp uses pawn and likely float as well. Converting is easy but it doesn't overrule the readability and usability in other environment.

Originally Posted by Exolent[jNr] If you include something just like <float> or <string>, some people may be confused because I have yet to see a scripter here include a subsection of the amxmodx include. So if they already have amxmodx included, it would be redundant and unnecessary to add float or string includes.

We are talking about an include file which code is unlikely modified. Like that they can't be overlapped.

Originally Posted by Exolent[jNr] Including more individual sub-core includes is much less readable than including the whole core. That's comparing 4 basic module includes to 12 sub-core includes. The only situation where I have found your reasoning to be useful is when I needed the hlsdk_const include but did not need engine or fakemeta in my plugin.

I never said that even including two sub core includes would be better than including the whole core.

[01101101]

Oh I won't read allll that. So I will give a simple opinion.

What is easier/more readable/nicer/logical
do

PHP Code:

#include <amxmodx> 


that has no perfonmance cost, and you have everything "out of the box"
or

PHP Code:

#include <core>
#include <float>
#include <amxconst>
#include <string>
#include <file>
#include <vault>
#include <lang>
#include <messages>
#include <vector>
#include <sorting>
#include <cellarray>
#include <celltrie>
#include <newmenus> 


[SnoW]

Originally Posted by 01101101 Oh I won't read allll that. So I will give a simple opinion.

You can't debate if you don't comment everything other says. Not commenting a single thing in that big post makes your opinion and reasoning pointless. Like that I have already won this debate against you. I will wait Exolent to comment though.

Originally Posted by 01101101 What is easier/more readable/nicer/logical do PHP Code: #include <amxmodx>  that has no perfonmance cost, and you have everything "out of the box" or PHP Code: #include <core> #include <float> #include <amxconst> #include <string> #include <file> #include <vault> #include <lang> #include <messages> #include <vector> #include <sorting> #include <cellarray> #include <celltrie> #include <newmenus>

My last sentence in the post you didn't read totally destroys that whole opinion, so I need to say nothing here.

[01101101]

Oh yes. First of all, this is about the true, not about an imaginary score that your mind creates to feel better (ohh my ePenis is now larger). So you don't won this discussion. Ok, if what you want is to close the discussion from your part, that must be because you are running out of arguments.

Here you said that any decent plugin uses amxmodx.

Originally Posted by SnoW In this issue amxmodx is included anyway in anything decent doing plugin. Somehow it doesn't change the fact that it wouldn't be better to include only what you need.

As well, any decent plugins will use amxmodx itself, amxconst, probably float, core, string, lang, newmenus and messages. That just from amxmodx sub-includes. Then will use probably modules includes like fakemeta, engine, etc.

So, as you stated before, any decent plugin will use much more than 1 include.
But then, you say "Somehow it doesn't change the fact..." OK, here you are saying that it is in all cases better to do the time-eating-slow-useless-include way.
Oh, somehow, Why? God somehow exist, oh really? Somehow.

We are talking about not exceptions, but general cases since this change you say would be applied to all plugins. And in general cases, plugins uses a lot of includes, look at my zombie mod

PHP Code:

#include <amxmodx>
#include <amxmisc>
#include <fakemeta>
#include <cstrike>
#include <hamsandwich>
#include <engine>
#include <xs>
#include <csstats>
#include <sqlx>
#include <geoipse>
#include <unixtime> 


With your way it would be sooo long that I don't even feel like opening all those includes to check.

I even think that amxmisc should be added into amxmodx include, and as exolent said, do 1 include per module.

[Arkshine]

Originally Posted by SnoW You can't debate if you don't comment everything other says. Not commenting a single thing in that big post makes your opinion and reasoning pointless. Like that I have already won this debate against you. I will wait Exolent to comment though. My last sentence in the post you didn't read totally destroys that whole opinion, so I need to say nothing here.

What a childish answer and pointless debate...

@01101101 : You better ignore him, you know. Not worth to waste your time.

[SnoW]

Originally Posted by 01101101 Oh yes. First of all, this is about the true, not about an imaginary score that your mind creates to feel better (ohh my ePenis is now larger). So you don't won this discussion. Ok, if what you want is to close the discussion from your part, that must be because you are running out of arguments.

It's unbelievable how you claim that I would like to close the discussion and would be out of arguments, when I just provided a bunch of facts you to comment, but you totally ignored them twice.

Basically what it seems to be you are doing is that after I say how the thing is providing facts you can't deny, you start to blame me and my way of handling the situation and not commenting the thing we are debating about.

As of my ePenis, I don't really get any satisfaction for "beating you". If it isn't obvious my debate thing is just funny joke you don't seem to understand.

Originally Posted by 01101101 Here you said that any decent plugin uses amxmodx. As well, any decent plugins will use amxmodx itself, amxconst, probably float, core, string, lang, newmenus and messages. That just from amxmodx sub-includes. Then will use probably modules includes like fakemeta, engine, etc. So, as you stated before, any decent plugin will use much more than 1 include. But then, you say "Somehow it doesn't change the fact..." OK, here you are saying that it is in all cases better to do the time-eating-slow-useless-include way. Oh, somehow, Why? God somehow exist, oh really? Somehow. We are talking about not exceptions, but general cases since this change you say would be applied to all plugins. And in general cases, plugins uses a lot of includes, look at my zombie mod PHP Code: #include <amxmodx> #include <amxmisc> #include <fakemeta> #include <cstrike> #include <hamsandwich> #include <engine> #include <xs> #include <csstats> #include <sqlx> #include <geoipse> #include <unixtime>  With your way it would be sooo long that I don't even feel like opening all those includes to check. I even think that amxmisc should be added into amxmodx include, and as exolent said, do 1 include per module.

You provide a lot of information that doesn't matter because you are claiming a fact I've already clearly stated here false:

Originally Posted by SnoW I never said that even including two sub core includes would be better than including the whole core.

I've also said this should be only used with for example in the thread we are now, a simple include file that needs only one part of core. Like that Emp includes only "cellarray".

Originally Posted by Arkshine What a childish answer and pointless debate... @01101101 : You better ignore him, you know. Not worth to waste your time.

I don't see anything childish in my answer. The debate itself isn't pointless, but this seems pointless as the side who's against me doesn't seem to provide any new proof but seems more to spent time insulting me.

Starting to ignore me now would look bad as not been able to prove you right.

[01101101]

Ok you win your ePenis is now larger.

[SnoW]

Originally Posted by 01101101 Ok you win your ePenis is now larger.

I'm not questioning you but I do hope that the purpose of your sentence is sincere instead of what I'd guess from the ePenis.