[Aiml-programr-developers] New graphmaster "node" class completed

[Nicholas H.Tollervey]

Mauro,

All sounds good to me. I like the idea of comparing old/new... that way
we can be certain that the code in the lib has earned its place... also
I like the opportunity to learn. :-)

I'll take an in-depth look at your new file / comments tomorrow during
lunch and will reply in depth very soon.

As I think I mentioned in a previous email, I'm intentionally not
looking at the "current" node class so we can do an untainted compare
and contrast. However, I've obviously quickly skimmed through your new
file. I'm really going to enjoy this!

Some quick points: I agree with using the metaphors as it makes the code
easier to understand - a good thing. Also, seeing how you've refactored
my clunky Ruby is certainly an eye opener. Coming from C# (where there
is no obvious equivalent) just using the Array.shift method makes things
a whole lot easier. In addition, I like how "unless" is used to get rid
of pesky if...else. Finally, I think it important that we include some
means of referencing the origin of a template in the graphmaster as this
is extraordinarily useful when debugging AIML (see the "source" argument
in my add_category method).

Best wishes,

Nicholas

mauro at cicio.org wrote:
> Hi Nicholas,
>
>   
>> Regarding the first two points (Ruby indentation / 80 column rule): no
>> problem, go for it (what exactly are the ruby indentation rules? where
>> might I find them? I thought I was following them?).
>>     
>
>   
>> what exactly are the ruby indentation rules?
>>     
> Simple: 2 spaces (not the C/C++ 4).
>
>   
>> where might I find them?
>>     
> I don't remember, I read them about 7 years ago and always respected since.
> Anyway: the generated code (e.g. Rails) respects all of them.
>
>   
>> I thought I was following them?
>>     
> Yes, I think so too: I just modified the 4 to 2.
>
>   
>> Coding "style"
>> rules are fine with me... it helps keep the code consistent and readable.
>>     
>
> I agree. In each lang, I stick to the main stream of that lang.
>
>   
>> Regarding comments: :-P I always comment first and then code. Helps me
>> remember what I'm supposed to be doing!
>>     
>
> This is fine. Not a reason -per se- to keep the comments once the
> coding is done :-)  I find them annoying, considering that your code
> is very clear, but is not a big deal.
>
>   
>> Also, as the Node class is (only
>> slightly) conceptually abstract yet essential to the correct workings of
>> a bot so I wanted to make sure anyone reading the code would have no
>> doubt how it works.
>>     
>
> Good point.
>
> I was referring to things like:
>     # @children to contain the child nodes from this node
>     @children = Hash.new()
>
> I suspect that if somebody needs a comment to understand what the
> @children of a Node class are, then s/he is reading the wrong
> literature ;-)
>
>   
>> My usual commenting style is much more terse and I
>> definitely subscribe to the self-commenting code school of thought.
>>     
>
> Great!
>
>   
>> Nevertheless, when working from a detailed specification (like the AIML
>> standard) I usually include relevant details in the class documentation
>> so it shows up in things like rdoc.
>>     
>
> I completely agree on this. I have never looked into it, but I think
> that Ruby has a mechanism to merge the comment file and the code file
> on the fly.
> Of course this is only for the class comment.
>
>   
>> Concerning editors: on anything but Windows I use VI (vim)
>>     
>
> Me too!
>
> Now I wanted to begin doing some real work myself!
> What I did is to rewrite your class up to the add_category method.
> Nothing new from the functional point of view, only style.
> At the add_category I stopped, in order to prepare a few comments and
> open a discussion on style, OO, programming.
> I have created a parallel file (play/nicholas/graphmaster/lib/node_mc.rb)
> where I also attempt a "defence" of the equivalent method in the old
> implementation. Using this technique (processing ourr code, like we
> where lawyers), is supposed to help us in becoming better programmers.
>
> Of course this kind of detailed work is very "expensive", so if you
> are not into this kind of things (I think you both are!), tell me and
> I drop my coach attitude :-)
> Very interesting is the point 5 in the file. I left it open for you to
> have the first word on it. I really hope you like the game (and have
> time to play it),
>
> Ciao,
> Mauro
>
>