I don't know, I guess a 'rubberblock' might commonly have a 'block' keyword defined, in which case you might match the first one. If there are no keywords would you expect 'block' to match rubberblock before 'red block'? I might not.
I'm with Idealiad, did you have another approach Kelvin? Most of my 'object' interactivity work has been with parsing input, more along the lines of making it more 'human approach'. IE rather than code of 'look block' it would scan for and ignore/choose based off of things like 'look at my block', it ignores 'at' and knows 'my' means in inventory or equipped (not room), and then looks at 'that' block.
But, things like taking a substring, I've never gone into, relying more on builders to have the keywords defined in ways that make more sense. - Dave.
I can't really articulate what I was seeing correctly because I don't have much background in the algorithmic side of it, but it seems like the algorithms it has in there would be more appropriate for stuff like searching multiple objects and trying to find the best (but not necessarily correct) match out of all possibilities.
A really fun example was that in a room that just had me (a player object named Snagglepants) and an object named "Test Station", "look sta" matched me (Snagglepants) with a higher score than the station. I can't remember which of the algorithms I was using, but after writing a set of tests to compare my desires against what I was getting, each one failed in different unacceptable ways.
In the end, I think I want to just emulate MUX/MUSH behavior (the substring + word boundary approach), but wanted to see if anyone else had solved this in an elegant manner.
Any time you have two things whose object names contain the string to be matched a substring you have an issues. You might expect, reasonably that if your input is "red" and there is a "big red table" and a "red table" in the room, that the latter ("red table") would be gotten since the string occurs earlier in it's name.
The approach you mention (the substring + word boundary approach) seems like it's reasonably intuitive and that would be why it has been used.
In the case of the block, checking against a type of thing might make sense. Suppose I type "look block", then I could logically expect to get the first thing that IS A block. If the game knows that both "A Rubberblock" and "A Red Block" are of type block, then I'd expect to get whichever it got to first. The game can't know what you're thinking and won't respond as you desire unless you give it all the details. If the game implemented view and you could only see "A rubberblock", then of course you'd get that one, because you can't "see" the other one.
It seems safe to use "the substring + word boundary approach", provided that the keyword can be matched against any part of any of the distinct substrings of the input. Really, unless "a rubberblock" is a special kind of block then it should be named "a rubber block" since both red and rubber describe an attribute of the block.