danShumway
commented
9 years ago Been thinking about this more, and there are a couple of considerations I have.
I feel really good about how infect() works as a function, with a couple of caveats that I'm not completely sure what Object.infect() ought to be returning, but other than that, great. It's something that's hard to break.
It doesn't necessarily follow that there should be similar interfaces for everything else. So I like the idea of a shared scope, but I don't really want it to be something in a closure that can only be accessed through a bunch of methods.
Part of this is me drilling down on what some of the design philosophies for vAnalyze need to be - the first being that (outside of a stable base) encapsulation is a really bad idea for a library of this type.
For a large library, you encapsulate stuff because it leaves you with a single interface that you can support for a long time - but vAnalyze is not something that you build large structures out of, in fact I'm actively discouraging that type of development. This is for writing unit tests on the fly.
That means I want to be exposing stuff to you whenever possible - using properties instead of methods when it makes sense, returning objects back to you that you can manipulate. And if that allows you to do some awful things, well, none of the code you're writing is permanent, so what does it matter? You'll develop better testing strategies over time.
That changes the way that I think about this stuff, because it makes maintaining a clean, easily understandable backbone through the __infection__ object a lot more important. What I'm thinking now with things like properties is that you attach them as a structure on your actual __infection__ object. So you can just call myObj.infect().properties['x'] and you get back a property object that you can save and manipulate and do all kinds of stuff with. And if you want more functionality for grouping properties, well I already wrote the search function to do that.
Secondly, I'm starting to like __proto__ a lot more, because when you log an object to the console in chrome or firefox, you can access that property graphically without writing any code. So that becomes a big help if there's some way to manage a scope chain through prototypes. Still cementing what I want that to look like though.
One possible idea at this point, depending on what Object.infect() ends up looking like, is maybe that's where your global scope is, and stuff inherits from there.
A dependency for #12 , this should determine not only how things like shared data work (ie. a globally accessible list of all infections, a shared stack, etc...) but also I guess inheritance and scope chain for setting options on infections.