2009/4/8 James Paige <b...@hamsterrepublic.com>:
> On Wed, Apr 08, 2009 at 02:32:59PM +1200, Ralph Versteegen wrote:
>> 2009/4/8 James Paige <b...@hamsterrepublic.com>:
>> > Ah, of course! Once globals can hold strings this it would only make
>> > sense for ${G#} to be able to display strings
>> >
>> > I wonder if, after the SAV format has been redone, we can devise a way
>> > to make it possible to reference globals by name rather than by ID
>> > number, perhaps using a method similar to what is currently done with
>> > new-style plotscripts?
>> >
>> >> A detail that might be relevant that was never decided (by me, if it
>> >> was never asked of anyone else) was whether real string variables
>> >> would be variables bound to string objects (like in Python, where two
>> >> variables can be bound to the same Dict (mutable) or string
>> >> (immutable)) or whether each variable (ignoring a pass-by-reference
>> >> feature, which can be considered aliasing) will always point to a
>> >> unique string (ignoring implementation details like copy-on-write)
>> >> that can't be modified by any other variable.
>> >
>> > I prefer the python way. If I really explicitly know I need a copy of a
>> > variable and not a reference, I would rather do something like
>> >
>> > v2 := copy(v1)
>> >
>> > But at least in my own python programming I find the situtations where
>> > copying instead of referring is REALLY needed for a REAL reason and not
>> > just for superstition are awfuly rare.
>> >
>> > ---
>> > James
>>
>> No, wait, that's different from python, at least for strings, since
>> strings are immutable in python.
>
> Oh, I didn't mean for strings. I guess I was just thinking of objects...
> something we haven't discussed in a plotscripting context.Something I would like to! But without some extra functionality beyond a structure of dynamically typed elements, I don't see any difference from a map - which doesn't justify adding more syntax, IMO. Maybe it would be a good idea, since this is an RPG engine, to make objects something that can also represent in-game objects like NPCs - providing an alternative way to access their data, maybe? Does this mean accessor functions and 'magic variables'? >> I feel nervous about making the following two situations act differently: >> >> a := 3 >> b := a >> a := 4 >> >> a := "3" >> b := a >> a := "4" >> >> On the other hand, our users are used to working with references to >> game objects, which are never copied, and maybe that's what we should >> look to? >> >> An alternative to a copy() operator could be a ref() operator. > > I guess I could be happy either way. > > But I still think I prefer the python way of doing it. Even for strings? OK, suppose two variables point to the same string object: a := "3" b := a You can modify that object like so: delete char (a, 1) How do you change the string to a new one? b := "4" ? Does that mean you want := to rebind to a new object, and passing something to a function like tolower() to modify the shared object? Differing behaviour for primitives and compound types annoys me a bit. Hmm, an idea. What if integers, (floats), strings, arrays and dictionaries all copied automatically on assign, while variables only reference objects. Add a way to alias two variables to the same data (or maybe just pass by reference will be enough, and you can stick whatever you want in an object to share it). This seems to me like a nice cut off point between default-copying primitives (like our integers) and default-referencing objects (like NPCs, timers, etc) > --- > James _______________________________________________ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
