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

Dealing with custom contexts is awkward #131

Open
qiemem opened this issue Aug 17, 2014 · 10 comments
Open

Dealing with custom contexts is awkward #131

qiemem opened this issue Aug 17, 2014 · 10 comments
Milestone

Comments

@qiemem
Copy link
Member

qiemem commented Aug 17, 2014

As long as you stick to breed-set based contexts, the nw primitives mix nicely with the netlogo ones. However, when you switch to static agent-set based contexts, thinks get more difficult. For instance, to the degree of a node, you first have to have a reference to the link-set of the context and then do count my-links with [ member? self nw-links ]. This is pretty awkward. One solution would be to provide primitives that mirror the built-in primitives, but relative to the context. For instance:

  • nw:nodes - turtle-set of the nodes in the network
  • nw:links - link-set of the links in the network
  • nw:my-links (and variations thereof) - links connected to caller
@nicolaspayette
Copy link
Member

Good idea. Maybe you should consider going with nw:turtles instead of nw:nodes, though, for consistency.

@qiemem
Copy link
Member Author

qiemem commented Aug 18, 2014

sigh I suppose you're right. Figured nw:nodes was more appropriate to context, but whatevs.

@qiemem
Copy link
Member Author

qiemem commented Oct 16, 2014

@nicolaspayette, if I add these, do you think we could toss nw:get-context, since it would be made obsolete? I doubt anyone's using it yet. @arthurhjorth, you might have thoughts on this too.

@nicolaspayette
Copy link
Member

I'm all for it. And it would have the advantage of eliminating the asymmetry between nw:set-context (taking two arguments) and nw:get-context (returning a list) that bothered @arthurhjorth (and me).

@arthurhjorth
Copy link
Member

Necroing this. If we want students in MAM to work with nw, it might be worth looking into? Also, I just tweeted about the nw-extension on teh twitter, so I was reminded of the discussion that @nicolaspayette and I had about this a year and a half ago(!).

Sorry that I never responded, I thought I did. I would be totally in favor of your proposed suggestions. The fact that nw:set-context nw:get-context failes is a good sign that this isn't working as it ought to :)

IF it's too late to drop nw:get-context, nw:turtles/nw:links/nw:my-links/etc. might still be nice to have.

@qiemem qiemem added this to the hexy milestone Aug 14, 2016
@qiemem
Copy link
Member Author

qiemem commented Aug 14, 2016

Thinking of doing this for hexy. What do you think @arthurhjorth and @nicolaspayette ?

Do you think we should also keep nw:get-context? Keep the primitive but remove the documentation (thus deprecating it)? Remove it completely?

@mrerrormessage Can extensions define their own auto-conversion rules? nw:get-context could be auto-converted to (list nw:turtles nw:links).

@nicolaspayette
Copy link
Member

I stand by my 2014 comment:

I'm all for it. And it would have the advantage of eliminating the asymmetry between nw:set-context (taking two arguments) and nw:get-context (returning a list) that bothered @arthurhjorth (and me).

:-)

If autoconversion for extension primitives is possible, that would be by far the best option. If not, I think it would be acceptable to outright remove it. I would normally advocate a period of deprecation, but 6.0 seems like a good time to break backward compatibility. The change will need to be clearly documented, though.

@mrerrormessage
Copy link
Contributor

I'm happy to go with whatever you all think is best. I haven't used the nw extension enough to have an informed opinion on the issue. The autoconverter can definitely convert between extension primitives if textual substitution (aa bb cc + rule: bb -> dd = aa dd cc) is all that's needed (it should be able to do it even if more than that is needed, but I'd want to verify).

The list of auto conversions is here. I'm fine with adding autoconversions for bundled extensions to that list. While a solution that allows extensions to define their own autoconversions is almost certainly possible, due to the way autoconversion is performed, I would expect some pretty colossal difficulty in doing so. Auto Conversion occurs as part of model loading in order to correctly convert all widgets, so information about extensions is pretty minimal.

@arthurhjorth
Copy link
Member

I don't know anything about the auto conversion thing, but fixing the error on nw:set-context nw:get-context would make me happy. But I would love to better understand switching between contexts, because I've wanted to do that often. How would it concretely work with these primitives?

@qiemem
Copy link
Member Author

qiemem commented Aug 15, 2016

Awesome, thanks for feedback everyone.

I don't know anything about the auto conversion thing, but fixing the error on nw:set-context nw:get-context would make me happy.

This only helps a little with that. You would do nw:set-context nw:turtles nw:links instead. So the original asymmetry is gone, but you still have some asymmetry in that there's one setter and two getters.

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

4 participants