Open viperscape opened 7 years ago
Now that the ffi has been mostly removed, working on collections is needed and this has become a first priority. Some syntax ideas below:
store
@player.items add dagger
;
Where player is a def block, and items contains multiple vars
This shows a few ugly heads, for instance what if there are adjustable stats on the item, which means objects need to be supported. The work around for this is def blocks representing items, however if items need to be unique, then the block names themselves must be unique. dagger-postfix-uniquename
A fix for this could be to create a base block, and copy from it:
def daggers
damage 1.5
;
root
@player.dagger new daggers
;
On the backend, a player_dagger
def block can be added that initially copies daggers
, player.dagger
is now a symbol which points to player_dagger
This also means referencing sub structs like player.dagger.damage
can be done. At this point, perhaps a collection really should be a group of symbols referencing blocks. They could be utilized with basic iterative functions:
@player.items [dagger sword bag] #represents a collection of symbols, referencing related def blocks
@player.items remove sword
Started an iters
branch which is taking a different route to all of this.
I've left out collections purposefully since it really would slow down the development of the library, but I think it's time to start thinking about how collections might be used inside scripts. A good use case I came up with is web site templating, something similar to mustache. This is trivial in lichen, except when mapping over a collection. All elements are owned in lichen, and as such are copied when needed-- this isn't that bad of a situation but with collections this is obviously not efficient. One thing that should be considered is a new supertype called Vars, which contains Var and RefVar (borrowed). Also, lichen has methods to read maps, and works on lists inherently. It would be nice if syntax did not change in this respect.