04: FINDing your Way Around

[Ptirhiik]

Ok, quote all examples are ridiculous, all are issuing with easymod, and not with standard process of mods. You have a very valuable one, unsolvable in a clean way in comments, you don't want to consider it (although it has to be considered). There I has pointed you an example, which is of course very simple in order to be understable, perfectly correct and certainly not ridiculous when you are dealing with differents templates, and you don't want to consider it. Well, I could go to a full mod installation with those issues, I'm quite sure there you won't neither consider it. What is ridiculous there ? Adding 3 or 4 lines in order to have a find unique, although the only line requested is unique, or willing to absolutly treat the find process as a part of a line, going to search the last word of a line, the first of the second and one in middle of the third line ? Sorry, but I find as an evidency that is ridiculous (and btw, be sure I have readen all the post there, or I won't be posting regarding issues), particulary because this kind of search is addressed by the IN-LINE FIND statement. The way you want to handle the find is just un-understable for a user, will bring absolutly nothing with ability of stacking mods, at contrary as you have to increase the number of line to find a specific one although it is unique, and most of all deny author to add comments in the code on what has been done, which is really a pity.

Considering comments now : why should have to add specificities to the code because of easymod ? Any state of code has to be processed by easymod, whatever it is, and a line having // at start isn't the same than one which haven't. That is common sense. A line starting with "<table" isn't the same than a line starting with "<td>", whatever the rest of the line is. There you are going to set a comfusing signification to the find, although it is one of the most common understood tag today.

[GPHemsley]

I haven't read the last two huge posts by Ptirhiik, but I would just like to point out a fact that you (Nuttzy) seem to keep missing: Some code in phpBB comes, fresh from the package, commented out. Most likely this is due to the fact that the feature is unfinished, or they may want that code later, but nevertheless, it is still there.

[Nuttzy99]

I really do want to work with you on this. Now that I have my morning coffee maybe I'll be less grouchy Coffee makes me more civil

You have a very valuable one, unsolvable in a clean way in comments, you don't want to consider it (although it has to be considered).

I promise we will address your commented is_auth example. Please let's stick to one issue at a time. You are telling me there is a huge fundmental flaw with the way EM deals with TPL files. It is very important to me that this be looked into first.

You have presented some code that you claim to be unique...

Code: Select all

#---[ FIND ]------
<table width="100%"

...and I am saying this is far from unique as similar code appears hundreds of times in the TPL files. By unique I mean not just unique to the file but also as unique as possible in that it won't cause conflicts. I'm sorry I called your example ridiculous, but if I were to see an Author use something like this I would ask what the heck they are doing!

So to me, what you have discovered is that EM can be broken if Authors provide too little info. I don't know what I can say to this beyond the fact unique means both unique to the file and a unique piece of code whenever possible. This example is certainly not unique in that regard and would be rejected. I think what would be helpful in the documentation is better explain what I mean by unique and to give example of what is unique and what is not.

Now then, with that said, since non-descriptive fragments like you cited violate the rules, would you still say there is a problem with EM and TPL files? If so, please explain and quote code examples if possible. For the record, I do see a case where even that non-descript code you are using could be used, but I don't want to cloud the matter by getting into it (unless you really want to hear it).

To be fair, I will work on a response for case where requiring the front of the lines will fail. I will not write my post with the "slamdunk" attitude I had when I quoted the SQL block. I will work on carefully thought out and legitmate examples.

We will work together on coming to a consensus. I will stop trying to win the battle a single post and instead be more understanding with the goal of reaching a consensus one issue at a time. Once we are done with this then we can move on to the next.

I'm at work so it will take me a while to get a response written. Thanks for the understanding and sorry for the grouchiness. Thank God for coffee!!!!!!

-Nuttzy

[Nuttzy99]

I haven't read the last two huge posts by Ptirhiik, but I would just like to point out a fact that you (Nuttzy) seem to keep missing: Some code in phpBB comes, fresh from the package, commented out. Most likely this is due to the fact that the feature is unfinished, or they may want that code later, but nevertheless, it is still there.

I do think that at the end of the day my method will work fine with this. But we'll get to this issue later, after the TPL issue is resolved.

-Nuttzy

[Nuttzy99]

FYI, on my lunch break I've come up with some pretty convincing cases as to why forcing the inclusion of the start of the line breaks things. When I get home from work I'll post them up. There are some practical reasons even in the Country Flags MOD.

-Nuttzy

[Nuttzy99]

I could probably do a better job of explaining things but I'm getting ready for bed. Writing EMC has now come to a halt for the past few days as this matter was discussed. I must move on to documenting other things now. I'm not shutting the door on discussion, just saying that I won't be checking back on this topic (or at least I shouldn't) for a few days. I think I have some compelling arguements below that justify why my approach is necessary. I just cannot devote time to this discussion right now especially when no opposing agruements have come close to persauding me.

Ptirhiik, if you want to make a detailed post about how you feel my method fails with your is_auth example then I will be more than happy to fully examine it and give a thoughtful reply (in a few days).

Why FIND must not be forced to include the start of the line:

There are several obscure reasons I could use but I will not use those in my arguement. There are so many very legitmate reasons that it is not necessary for me to stretch things.

First the principal goal of FIND to use unique elements of a line (or block of lines) to find the part of the code you are looking. We do this with the knowledge that lines may have been changed by a previous MOD installation or we may be looking for lines in a non-subSilver TPL file.

It is completely reasonable to assume that any part of a line may have changed from the default phpBB, whether it be the beginning, middle, or end of the line. Therefore it is necessary to limit the FIND to only what is unique about it and eliminate all other text that could possiblely causes a FIND to fail. But one must remember to not be overzealous in trimming out text or must include additional lines in the FIND to assure that the correct line(s) will be found.

Some folks, especially those that like to comment out a lot of code, support the notion that FIND must be forced to include all of the text from the start of a line until the desired unique element is encountered. Unfortunately this idea is flawed and will needlessly result in FINDs failing to do their job. Several examples follow.

Conditional statements
In PHP files the most likely instance where the beginning of a line will change is on any conditional statement. For example, it is entirely like that you may be seeing a line like this....

Code: Select all

if ( $mode == 'editpost' || $mode == 'delete' || $mode == 'poll_delete' )

...but another MOD has changed it somethign like this...

Code: Select all

if (( $mode == 'editpost' || $mode == 'delete' || $mode == 'poll_delete' ) && ($foo))

...therefore the best way to find this line possiblely may be to reduce the search string down...

Code: Select all

$mode == 'delete' || $mode == 'poll_delete'

...but there is no doubt here that forcing FIND to include the beginning of the line is going to cause it fail.

Similar things can be said for "while loops" or with variable assignment. For example you may have a while loop that has changed from...

Code: Select all

while ( $end_counter && $end_html < strlen($message) )

...to...

Code: Select all

while ( ($end_counter && $end_html < strlen($message)) && ($foo == $bar) )

You may also have a variable assignment like this...

Code: Select all

$is_auth = auth(AUTH_ALL, $forum_id, $userdata, $post_info);

...that gets changed to...

Code: Select all

$is_auth = ($foo) ? auth(AUTH_ALL, $forum_id, $userdata, $post_info) : $bar ;

...in both these examples there are plenty of unique elements to search for, but forcing the requirement of the beginning of the line will make the FIND fail when it is totally preventable.

SQL statements
To a lesser degree, SQL statements are also susceptible. Take this for example...

Code: Select all

$sql = "SELECT u.username, u.user_id, u.user_posts, u.user_from, u.user_website, u.user_email, u.user_icq, u.user_aim, u.user_yim, u.user_regdate, u.user_msnm, u.user_viewemail, u.user_rank, u.user_sig, u.user_sig_bbcode_uid, u.user_avatar, u.user_avatar_type, u.user_allowavatar, u.user_allowsmile, p.*,  pt.post_text, pt.post_subject, pt.bbcode_uid
	FROM " . POSTS_TABLE . " p, " . USERS_TABLE . " u, " . POSTS_TEXT_TABLE . " pt
	WHERE p.topic_id = $topic_id
		$limit_posts_time
		AND pt.post_id = p.post_id
		AND u.user_id = p.poster_id
	ORDER BY p.post_time $post_time_order
	LIMIT $start, ".$board_config['posts_per_page'];

...in this frequently modified section of code, if anything inserted before u.username or POSTS_TABLE or if the code following WHERE, ORDER BY, OR LIMIT is modified only slightly then the FIND could needlessly fail. For the most part though, authors will probably insert new code in the middle of the line rather than the start, but there is no guarantee. I prefer to give authors as much freedom as possible so they may order things however they want.


The big one! TPL files
The greatest need for not forcing the use of the start of the line comes from TPL files. It is undeniable that many user have more than just the default subSilver installed. Some of these templates are more similar to subSilver than others. Even an unmodified non-subSilver TPL can have problems being MODed unless there are specific instructions for it. But the goal remains the same of trying to install MODs into all templates even if they are different from subSilver and modified as well.

By forcing the inclusion of the start of the line then you are going to be requiring the inclusion of items such as widths, colspans, alignments, and classes. This is pretty much guaranteeing failure in anything but subSilver. I simply cannot allow this to happen.

But requiring these will even create problems for subSilver once it has been modified. It means that in the following line...

Code: Select all

<td width="150" align="left" valign="top" class="{postrow.ROW_CLASS}"><span class="name"><a name="{postrow.U_POST_ID}"></a><b>{postrow.POSTER_NAME}</b></span><br /><span class="postdetails">{postrow.POSTER_RANK}<br />{postrow.RANK_IMAGE}{postrow.POSTER_AVATAR}<br /><br />{postrow.POSTER_JOINED}<br />{postrow.POSTER_POSTS}<br />{postrow.POSTER_FROM}</span><br /></td>

...if a previous MOD has changed anything before {postrow.U_POST_ID} (which is the first unique thing about the line) then your FIND will fail. There are just too many elements that people may want to change.


Adding comments to the code
As I've said before, the core phpBB core code is like a map. We rely on various landmark to FIND our way around. Some folks have the practice of automatically including in their MODs large blocks of duplicate code that matches the original phpBB core code, except it has comments in front. The intention is good, allowing users that manually edit files can see what was changed. However the effect is like adding extra landmarks that don't really exist into our map! Without some way of distinguishing these blocks from the rest of the code, then integrity of our map degrades rapidly. To allow for this practice there must be a standard adopted to inform us that we must not use these lines in our FIND.

-Nuttzy

[-=ET=-]

Comments like you are suggesting will not be allowed. Yes, this means the size of Ptirhiik's MODs will be shrinking quite a bit However EM will be providing its own comments that EM will know how to skip.

As for the way you leave comments in your subforum MOD, if a person is manually installing it then they could simply comment out all those lines instead of you have to put them in the MOD script. There is no reason why you need to be doing this for them. If someone manually installing wants to document changes they can do it just as easily themselves than if you were including the comments in your MOD script.

My reasoning for not allowing such comments: sometimes people want to search for text that is a comment (like your comment anchoring idea). Therefore you cannot automatically skip a line b/c it is commented out. Plus I will also need to be keeping track of every /* and */ which is very messy.

The bottom line, is that if we want automation then we have to the best we can as a community to standardize things. There will have to be some give and take but the benefit will be near flawless automatic MOD installations. I also am not deciding all these things by myself. I always submit things to the community to examine and am willing to reverse my decisions. I also NEVER require something unless it is necessary and I have known for quite sometime that comments like you are suggesting cause problems.

IMO the best way to deal with them is to eliminate them and have some or have some standard way of telling EM to skip them. So perhaps a compromise. I could probably make it so that by adding a little extra text that EM will know how to skip your kind of comments too. But this is going to lead to double commenting since EM will already be doing this. I really don't think it is up to the MOD author to be generating the kind of comments that you do.

Exactly!

Well, I'm a bit late on this post and I can't quote and argue with you (Nuttzy) on all the amounts of arguments that were exchanged in these last 4 pages here, but I FULLY agree with you!

The FIND definition must NOT change!
Comments not managed by EM must not be allowed!
FIND must NOT necessarily start at the beginning of the line!
FIND is NOT IN-LINE FIND (you may find a line with a unique string and find a smaller string with an IN-LINE FIND command)!
Etc.

Keep up this way, ALL you said is simply good sense!

[A_Jelly_Doughnut]

Not it is clear except for one thing.
A find for this:

Code: Select all

$sql = "INSERT INTO" WHERE

would be valid? It seems that someone posted this, and called it valid. (I know it isn't unique).

[Ptirhiik]

How could I agree with this :

Comments not managed by EM must not be allowed!

Hopefully, phpBB original files are full of comments, and a mod without any comment is just a poor quality developpement, there all programmers can say that. Your forget also to mention that easymod is not the only way to modify a script - but only one way - but has to deal with all states of code.

An at end, there is no difference between finding fragment through a file and finding fragment to a string : both are the same process, so a FIND is an IN-LINE FIND in the finding process described. As at this time I can't see no limitation finding fragment on two or more consecutive line, I can't see any differences between in-line find and find.

Please use the words "good sense" in their good meaning. Here we are dealing about concrete case, and concrete issues, and trying to find the best way and avoid the most issues as we can, not having a fight on who will get the last word : I think both Nutzzy and I will let this to the kids who are playing in the garden, so common, you have already prooved that you can be much more usefull than this .

[GPHemsley]

If you ask me, there should be no question about commented out lines as long as no one (like Ptirhiik) includes the muted code, pre-MOD, before it and no one uses /* */ over more than one line. All other comments should be perfectly "legal" and perfectly acceptable to EasyMOD. Even those that put

Code: Select all

// Start - MOD Name
MOD code
// End - MOD Name

should be perfectly fine, and used in addition to EasyMOD's breadcrumbs.