Mixing in defaults

Colin Clark colin.clark at utoronto.ca
Mon May 12 17:58:21 UTC 2008


Hi Michelle,

On 12-May-08, at 11:16 AM, Michelle D'Souza wrote:
> So, for me the question comes down to how safe we want to be. We  
> know what we are willing to have overridden so using the more  
> specific function seems right to me. Although I used the word 'safe'  
> I can't actually come up with a reason why mixing in arbitrary  
> properties that would never be called or activated is 'unsafe'. So I  
> guess I'm willing to go with what ever the consensus is but I'm  
> leaning toward the fluid function.

Let me see if I can unpack your safety argument to make sure I  
understand it.

So the potential risk of doing dynamic mix-ins is that we end up  
granting outside code with access to internal state in our components.  
So if you were mixing in outside properties into a full-fledged  
object, the risk would be that additional functions could also quietly  
be mixed in which would then have access to our "this" context.

When you're just merging a set of properties together, I don't *think*  
this is a risk since we're not mixing in any programmatic code. We're  
also using a fixed vocabulary--we only access a specific set of known  
properties--so unexpected properties will never be touched. We're just  
merging the values of one hashtable into those in another.

So given this, what extra safety does fluid.utils.override() provide  
when merging defaults?

Colin

---
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org