OOC: Evan drops the OOC light..

Evan says, "Heyla Paric...  you here to learn coding too?"

Paric smiles, "Hmmm...just to watch and watch...heheh"

Evan chuckles, "Heh."

Sep blinks in from ::between::!

Paric chuckles, "Hey Sep/Jag!"

Agrajag walks into the office.

Agrajag calls to Sep, who flies over and lands on his shoulder.

Evan wonders if either of you 2 have had any experience w/ coding?

Agrajag nods, "nothing highly advanced, but I like to mess around with C and shell scripts a little."

Evan nods, "this is good...

Paric chuckles, "Hmmm...my experience.  I use to program dbase, etc. and some lp mud."

Evan says, "Just a tad bit of theory then:  Coding is nothing more than the process of telling the computer/MOO how to do something.  The hard part of coding is figuring out the algorithm..."

Paric laughs and shakes his head.

Evan says, "An algorithm being nothing more than a sequence of steps."

Evan says, "The code, then, is nothing more than how you tell the computer/MOO/whatever the algorithm."

Evan says, "End of theory.  any Qs?"

Agrajag shakes his head, "sounds pretty familiar"

Evan says, "Paric?"

Paric smiles and shakes his head, "No questions."

Evan says, "Quick summary of MOOcode:  verbs are how the MOO stores code to be executed...  each verb is defined on an object, and any of that object's descendants.  Verbs can also call other verbs, with or without arguments, depending.  Properties store information, and are also defined on an object and, thus, on any of that object's descendants.  This is called Object-Oriented-Programming.  The goal of Object-Oriented-Programming(OOP), is encapsulation.  To elucidate further, encapsulation means that when a verb is called, HOW it does whatever it does is irrelevant.  Thus, for instance, if one verb is a write-to-screen verb, and it has to be changed for some reason, any verb that calls that write-to-screen verb will not have to be changed, because the code on the W-T-S verb is encapsulated.  One of the goals of OOP is to write a given segment of code only once, and just re-use it, through encapsulation.  Another feature of OOP is hierarchy.  An object can have children that inherit all of the parent's Verbs and Properties.  The child object can then enhance on the parent's verbs/props.  BUT, it isn't necessary to re-write everything that is stored on the parent, because it is implicitly defined on the kids."

Evan frowns, "Guess I was lying... I wasn't done with theory.  That's a big chunk of info... Questions?

Agrajag shakes his head and just remembered he did a bit of java as well :)

Paric smiles and shakes his head. "Makes since to me."

Evan says, "ok, then.  The hardest part of coding is learning about all the other verbs around that you can use, and how to use them.  A big source of info on commonly-used stuff is in 'help utilities'...  don't need to read it now, but keep it in mind."

Paric nods.

Evan says, "MOOcode is very similar to C and PEARL.  it has your standard if/elseif/else/endif, while/endwhile, for/endfor loops and conditionals..."

Agrajag nods.  I also find it nice to @list other verbs to find useful functions.

Evan nods, "And for help on more efficient way to code things...

Evan says, "for instance:  how would you simplify:

if ($object_utils:has_property(<dbrf#>, "foo"))
   player:tell(<dbrf#>.foo);
elseif
   player:tell("<default_foo>");
endif

Evan says, "btw... there is an example of how to use an if/elseif/endif statement... and a way to print a single line to a char's screen."

Evan says, "Any ideas?"

Agrajag says, "only possible thing I can think of is to display it without the if statement before hand, then try to catch the error and display something else if there's an error, although I haven't done much programming with errors, so I don't know how well it'd work."

Evan shakes his head, "It uses the ternary operator... something that most people have never thought of.  here is the shorter version:

Evan says, "Concatenation:

player:tell(($object_utils:has_property(<dbrf#>, "foo") ? <dbrf#>.foo | "<default_foo"));

Agrajag nods, "that makes sense"

Paric smiles and nods.

Evan says, "the basic syntax for the operator is:  <expression> ? <return_if_true> | <return_if_false>"

Evan says, "Also note, that the <return_if_true> and <return_if_false>  can be expressions themselves... and verbs are expressions.  thus you could do: <prop/variable> ? <dbrf#>:<verb1> | <dbrf#>:<verb2>"

Evan says, "or: <prop/variable> ? 3 | 4      or any number of things."

Evan says, "you can even nest ?| commands... BUT it isn't a suggested practice, because it can get to be very un-readable."

Paric nods.

Evan says, "and readability is also _very_ good so that others can use your code.  My view point is:  if you have to nest ?| more than 2x you should use an if/elseif ladder...  if you have to use it 2x, consider _VERY_ carefully the use."

Agrajag thinks nesting them would be very confusing.

Evan says, "I assume that you have both done if/elseif/else  expressions enough that I don't need to go over them?"

Agrajag nods

Paric nods.

Evan says, "nods... here's the basic sentence: if (<expression>) <RETURN> <statement_block> [elseif(<expression>) <RETURN> <statement_block] [else <RETURN> <statement_block>] endif"

Evan says, "you can use as many elseif-s as you want, of course."

Evan says, "btw, standard syntax on the syntax...  things enclosed in <>s  are things you must replace with actually data.  things in [ ]s are optional."

Evan says, "What about for and while loops?"

Agrajag says, "I'm pretty comfortable with those."

Evan says, "ok... syntax is as follows:"

Evan says, "while (<expression>) <RETURN> <statement_block> endwhile"

Evan says, "The for-loops here are very strange... so watch these carefully.  NOTE: there are different kinds of for-loops."

Evan says, "Type one:  going through a run of #s...:"

Evan says, "for <variable> in [<beginning_#>..<ending_#>]  <RETURN> <statement_block> endfor"

Evan says, "example:  for index in [1..10] <RETURN> player:tell(<list_var>[index]); <RETURN> endfor"

Evan says, "in the statement section, the [index]  is indexing the list."

Evan says, "lists are equivalent to arrays... get to them in a min."

Evan says, "Type 2, using lists:"

Evan says, "for <variable> in (<list>)"

Evan says, "the <RETURN> <statement_block> endfor  being the same btw all types, I won't repeat them."

Evan says, "in this one, <variable> takes on the value of each element of <list>  in turn as the loop executes."

Evan says, "Any questions so far?"

Agrajag shakes his head.

Evan says, "btw, you can use expressions in the for <var> in [a..b]   for instance:  for blah in [1..length(<list>)]"

Evan says, "that would be the same as for blah in (<list>)    but you get the idea."

Evan says, "Just as a test...  write the for* line in a for loop that would put the values 42 through 100 into the variable fooBar"

Agrajag says, "for fooBar in [42..100]"

Paric smiles, "I'll be back in a while...phone call"

Evan says, "Good.  get one to count by three.  from one to 30.  1, 4, 7, etc."

Evan says, "laterz, Paric."

Agrajag says, "I'm not sure how to do it bye threes, but a guess would be  for i in [1,4..30]"

Evan says, "nope."

Evan says, "I have to admit that this one is tricky.."

Evan says, "for foo in [0..99]     and reference foo*3"

Evan says, "er... foo*3+1"

Evan says, "blinks... ack!"

Evan says, "you'd have to do [1..99] and reference foo*3... and not get a '1'"

Agrajag says, "s/99/10  you only said go to 30"

Evan says, "nods, "true.""

Evan says, "Now... variable-types."

Evan says, "There are three that I can think of, but I think there are four.  Numbers, Strings, and Lists."

Evan says, "duh.  4th is dbrf#s"

Evan says, "Lists, as I said before, are arrays.  they can have as many elements as you want, and are DYNAMICALLY_ALLOCATED.  (which is a HUGE w00!!!)"

Agrajag nods

Evan says, "you can have lists of lists, even.  this is how you would do multi-diminsional-arrays.  (tables, etc)."

Evan says, "lists look like this:  {1,2,3,4,5,6}"

Evan says, "that being a list of six numbers."

Agrajag says, "yep :)  and a multi is {{1,2},{3,"bar"}}"

Evan says, "note the braces that distinguish the list.  some simple built-in list commands:  length(<list>)  returns the # of elements in the list.  @<list> returns the elements, but not in list format.  this is used for adding to lists.  ex:  {@<list>, 3}  would return <list> with a 3 added as the last element."

Evan says, "yep...  and you've even notice the ReallyCool(tm) fact that lists can have different types of info in each element."

Evan says, "so lists are a melding of C's Arrays and structures."

Evan says, "not exactly, but sort-of."

Evan says, "Any questions so far?"

Agrajag shakes his head, "I've already messed around with moo coding a bit and learned some of this the hard way :)"

Evan says, "ok...  now, why don't you @List #3950:connect_stats   and see if you can figure out what it does."

Agrajag says, "That object does not define that verb."

Evan says, "oops... #3950:connectstats"

Agrajag says, "it tells you how many connected players there are and how many of them there are in their respective homes.  it also tells you how many children of each player parent are connected."

Evan says, "Good."

Evan says, "Try #3950:find"

Evan says, "Noted; $command_utils:suspend_if_needed(0)  resets the # of ticks a verb is allowed before it is forcefully @killed.  (ticks=clock-ticks)"

Agrajag says, "it looks like it gives you the dbref# and name of objects that have 'what' in their name"

Evan says, "Very good.  One last one: #4421:@make       (which is mine, despite what it says at the beginning)."

Evan says, "btw, notice lines 23 through 33.  this is something that comes in useful.  (listing options, and then having user select one."

Agrajag chuckles, "I've looked at this code before. (had to figure out why it wasn't working for me). it takes a list of objects stored on the players parent and gives them the option of which one they want to make.  it's useful if you don't want to set something universally fertile, but only want certain members of your craft/weyr/hold to be able to @create/@make them.

Evan nods, "Good."

Evan says, "that was _exactly_ why I coded it.  :>"

Evan says, "or even, ONLY members of your craft/weyr/hold"

Evan is going to have  a talk w/ Shirgie/Kira about getting a byline put it... if it's Co AstroArch, I _want_ the byline, since it is MY code.

Agrajag nods.  "I figured that out from the objects listed on it :)  you should get a byline put on there."

Agrajag says, "er.. figured out the exact reason you coded it based on the objects and looking at the source"

Evan nods, "Any questions you have atm?"

Agrajag shakes his head, "nope"

Evan nods, "Good.  I hope you enjoy coding then.

Evan hasta @bug for the night.  will CUL

Evan glides silently to the Bedroom.

[Smith] Evan: Smith is not Evaning any more!