API name change ideas for Infusion 1.0

[antranig at caret.cam.ac.uk]

Quoting Michelle D'Souza <michelle.dsouza at utoronto.ca>:

>
> On 30-Mar-09, at 2:19 PM, Colin Clark wrote:
>
> > Hi everyone,
> >
> > As part of the Infusion 1.0 cleanup parade, we're going to consider
> > improving the names of parts of our API. This has to be done with
> > care, and we'll want to consider backwards compatibility for each
> > method we rename.
> >
> > Rules for the API renaming process:
> >
> > 1. Nominate your suggestions for methods to rename either on list or
> > in the channel
> > 2. The component co-coordinators need to be included in the renaming
> > discussion
> > 3. Propose a strategy for enabling backwards compatibility
> > 4. Be gentle. Naming debates can easily fall into "bike shed"
> > arguments or hurt people's feelings.
> >
> > Here's my list of names that I'd like to see us discuss:
> >
> > * The DARApplier and associated names
> > The DARApplier is the newest part of our framework. As model layer
> > infrastrcture, the DARApplier allows components to make requests to
> > the framework for changes in the model. It provides a scheme for
> > validation routines to be plugged into this change request pipeline,
> > and for change events to be fired as a result of successful updates
> > to the model.
>
> One of the associated names I'd like to see us rename is
> 'that.applier'. It's not very clear to me what I'd use it for.
>
> How about ChangeGuard and that.changeGuard or ModelGuard and
> that.modelGuard?

Well.... guarding is just one of its several functions. So far the
full civilization of listeners it supports are
i) guards which can react "early" to incoming changes to the model,
validate or reject them
ii) (not yet implemented) "transactional" reactors which can look at
a fully assembled "new state" to the model, and still have the ability
to back out the transaction as a whole (only at greater cost than
rejecting it at stage i)
iii) model changed listeners, which notify interested parties about
which pieces of data are now "dirty" due to change etc. so they may
update their own state (whether in other models, or in a UI, etc.)

To me, it automates the complete lifecycle process of "applying"
a change to the model...

> >
> >
> > * Fluid.js: fluid.findKeyInObject()
> > This is a framework utility that performs reverse lookups in an
> > object: pass in a value, and you'll get its associated key. This
> > name always confuses me about the order and nature of the arguments.

We already renamed this one once.... I think it used to be called
"find" or "findKey"?

> > * DataBinding.js: fluid.assembleSuperModel()
> > This one is a bit confusing. I'm not sure how and when I'd use it,
> > and some in the community has said it reminds them of nerds in their
> > basement. Enough said.
>
> Is this creating a renderer model? I'm not certain what it's doing
> exactly.

This automates the work both of assembling many smaller models into
a combined model, but at the same time assembling their sub-appliers
into a super-applier, which will route incoming change requests to
the "leaf appliers".

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.