Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

collections #5

Open
viperscape opened this issue Jun 2, 2017 · 2 comments
Open

collections #5

viperscape opened this issue Jun 2, 2017 · 2 comments

Comments

@viperscape
Copy link
Owner

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.

@viperscape
Copy link
Owner Author

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

@viperscape
Copy link
Owner Author

Started an iters branch which is taking a different route to all of this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant