[188] in Coldmud discussion meeting

root meeting help first first in chain previous in chain previous next next in chain last in chain last

Re: confusion

daemon@ATHENA.MIT.EDU (Thu Mar 31 14:30:46 1994 )

Date: Thu, 31 Mar 1994 12:22:12 -0600 (MDT)
From: the Lynx <BRANDON@cc.usu.edu>
To: coldstuff@MIT.EDU

<	How do the current cores deal with general setting of variables
< (and by this i dont mean other objects setting a var, just the object
< that owns the var setting it for internal use).

In world 6 you have to first use .add_parameter, then you have to create a
method to modify the parameter and set its initial value.  In CDC we've hacked
.add_parameter so it can also set the initial value.

< 	Would it be bad to have one method that either set the var or
< returned the var, based upon the context it was called in? This may
< be a bit confusing to the programmer, so I could see why it wouldnt
< be desireable, it just seemed like a neat idea at the time :)

Im vague as to what your asking, are you saying you have a method which
accesses parameter ,foo, where the method accessing it can either set the
parameter to a value, or return the value?  Like:

	.foo() => [value of foo]
	.foo([value of foo]) => $object

I would personally not like this idea, as it just makes sense doing it the
other way and probably takes less code in the long run:

method foo <1>
arg [args]

if (!args)
  return foo;
foo = args[1];


method foo <2>
return foo;
method set_foo
arg value;

foo = value;

hsm, dunno, I like the set better anyhow... :)

< As a corellary to point 2 should the core methods that add a parameter
< also add the set and retrieve methods for the parameter (pehaps based on
< a template?) This would of course be modifiable, but would then be 
< useful in preventing typing in the accessor each time. alternately
< a template accessor could be called or inherited, although im unclear
< on how to inherit a uniqely named method. 

I would definitely say no.  This is because doing such a thing would lead to
bad coding immediately, where people yearning for MOO would just fall back into
MOO patterns.  Often times you do not even WANT to have direct accessor methods
for values, an example would be $input and $input_parser at tCD.  $input has
two parameters ,receiving and ,input.  ,input is only added to by .new_line(),
only returns text when .finish_receiving is called, and is cleared by

< Sorry about continuously restating my point, but i keep getting responses
< to the parts I mostly already know (i.e. other objects should directly 
< set vars on an object). my point is that there should be only one method
< period that sets a var on an object, and that object should use that 
< method...

Yeah.  I'd suggest just sticking with eval.  Actually, I suppose we can hack up
an "as * eval *" and "def * as * eval *" for $programmer, with security checks

-Brandon (Lynx)