 |
 |
|
|
|
|
|
|
|
|
|
| Author |
Message |
Marilla
Joined: 02 Feb 2006
Posts: 329
|
 Posted: Wed Dec 06, 2006 2:41 pm Post subject: |
 |
|
| Xadhoom wrote: | But as i've already said: it's up to the dev, no need to continue this (useless) discussion, so don't expect me to reply again  |
Oooh goody. That means I can get in the last word!
People who "don't know their includes by heart" also should not need this - they shouldn't be adding includes willy-nilly; They should be carefully examining whether they need a particular include.
This just seems silly to me, on so many levels. I mean... can you imagine someone programming in C/C++ by simply slapping include and using statements at the top of every source file, until something happens to work? Yet, it often seems like that's how some people try to get eScript to work.
===============================
To me, programming is not so much about just 'knowing' everything... but it's about knowing where to find things, and how to use the environment and systems involved in the language/compiler you are using to get the effect you want. Just throwing whatever code you want into includes leaves you with a mess that apparently, some people think can only be solved by having the compiler do even more work beyond simply compiling.
While I don't think -any- modern 'compiler' is merely a compiler any more, these days, I think that it's always a good thing to keep compilers as lean as possible, and limited to doing work that is at least related to compiling. Aside from obvious things that could cause serious problems (like compiler warnings about hidden and unused variables), I do not think the compiler should be checking our code.
Yukiko mentioned something really great above, too; This sort of effort is something tailor-made for Perl. For those not familiar with Perl, C or Java could likely also be used. On Windows systems, a VB.NET or C# console program could be written to do this (much like Danielle's program that checks source files to positively make sure you have the appropriate 'use' statements - a program could be written that negatively assures you are actually using the includes you note. It could also easily be expanded to do the same thing for use statements (to assure you don't have any extras))
But I think that someone who has this problem with any frequency will be left with a big mess, still; They'll end up having to run such an auditing program frequently, because they are likely never to really know what their includes are for, and so they are likely to just keep tossing in more and more includes every time they try to work with a source file, until they find what they are looking for... and in the meantime, they usually leave the dozen or so other includes there, too. Bleh! |
|
 |
|
|
|
|
|
| Author |
Message |
Marilla
Joined: 02 Feb 2006
Posts: 329
|
| Posted: Wed Dec 06, 2006 3:09 pm Post subject: |
|
|
| Yukiko wrote: | | Just try to trace through any package in any Distro version |
That's an unfortunate truth here. Believe it or not, the knowledge of that fact has tempered my response to this suggestion  Because I know that by default, everyone's includes were a mess.
However, I don't recall the 095 distro having much trouble with large numbers of unneeded includes, thereby causing unnecessary recompiles. As you noted above somewhere, too; So what? It seems like you would have to have some really broad problem here for it to be noticeable; A half-dozen scripts with an extraneous include would hardly be something to notice, unless there is, otherwise, only a like or smaller number of scripts that legitimately need it. In such a case, it would seem easy to fix the problem.
But even if you are starting out with the 'fresh' distro, you still should not be just tossing include statements into your scripts as a way to 'fix' them... yet I know from looking at others' code, and seeing how many include lines exist, then are commented out (often to be later added in below), I know that people seem to do this, an awful lot.
To the extent that your includes simply are a mess, and that's simply what you must do to work; OK. I worked with a distro in the past, and I originally started with a script set that, as full of neat ideas it may have been, was a horrible mess as far as includes and lots of other basic scripting problems (WoD/Ackadia); So I had to deal with all of this myself.
It took time - lots of it - to get the includes into something resembling organization. In fact, I would say that only my recent upgrade work - where I also brought in another scripter - forced me to really finish that. Up until recently, I still had, for example, std.inc. Forgive me, those who wrote functions in it - but at least the version of it I had was a horrible mess; mostly filled with functions that had been replaced with core functions since 092, at least. However, the biggest problem with it was that it was a huge hodgepodge of functions, very few of which were related to any other functions there. I had, over the years, been removing any links into that file from any of my scripts; replacing them with calls to core functions that did the same thing, or creating new, targeted includes that made more sense (so that when you see the name of an include, you know exactly what it's for. Exactly what obvious purpose does an include named "std" serve? Compare that to an include named "webbrowser" or "townstones" or "magiceffects". Granted, often the 'obvious' is a bit esoteric, but still...)
It was only when I brought on someone to help, and they started using functions again in std.inc, that I realized that file was still there, and needed to be deleted. Having another set of eyes and hands in the scripting made me realize even more how important it was to keep things organized and understandable. I still have some way to go with that now, due to having more hands in the soup - for instance, I had long relied on 'clips' in TextPad as a reference to what functions I had available where, and what their parameter lists were, when I did not remember something off the top of my head (which, I almost never do!)... but of course, my scripter does not use TextPad, so I can't just send him my clip file. This has left me largely manually documenting the functions in my includes for his use.
It would have been much better had I done something like have a comment 'header' in each include which included a list of the functions meant to be called from outside that include, along with their return values and explanations of their parameters. As it is, he's done a good job of discovering the uses of the include functions themselves (often he goes there before he goes to the Core functions, which is how he ended up using functions in std.inc, most of which had better Core functions instead)
So.. umm... that's my big rant for the day! |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Author |
Message |
Marilla
Joined: 02 Feb 2006
Posts: 329
|
| Posted: Tue Jan 02, 2007 3:09 pm Post subject: |
|
|
| tekproxy wrote: | | It seems ecompile already ignores includes that are not used |
Which is why this isn't needed.
| tekproxy wrote: | | and it would be absurdly trivial to simply print out any of them. |
Depends on how you define 'absurdly trivial'. I think it would be 'absurdly trivial' to simply use your includes properly in the first place. But I think you are failing to understand that eCompile is doing what you said above: IGNORING code in includes that it is not using. If no code is ever called that's in an include, it's not bothering with any of the stuff in that file. It's IGNORING it - as in, not doing anything. It's not counting it, tracking it, or even reading the contents of its functions (it's merely making sure that it gets a list of the function/variable identifiers so as it compiles, it know what's where).
| tekproxy wrote: | How does something like this turn into a 3 page thread??  |
It was dead, until you brought it up again. I think it turns into a 3 page thread because it's a request made by lazy scripters that would cause all of our compiles to take some extra time and effort, when the problem here is in your code, and should be fixed there.
Why not have eCompile warn you when you have an infinite loop due to using a constant as a control and having no break statement? It would be 'absurdly trivial' to do so, wouldn't it? Why... it could even be an option you could turn on and off in ecompile.cfg...
| tekproxy wrote: | I think it would be helpful to have a configurable option in ecompile.cfg that's off by default that would print out unnecessary includes, unless it's not as trivial as I assume it is.  |
I think it would be helpful for people to understand how to use includes properly, so that requests like this would die. |
|
|
|
|
|
|
|
|
|
|
|
|
