From Forum: Simpler Syntax?

[Bill Scott]

Bringing this over from heyotwell's message about Simpler Syntax...

I love the idea of Protoscript but to me, the syntax still isn't simple enough or consistent enough to use as a designer. For example:

Code:
$proto('img#avatar', {
  Click: {
    onClick: {
      Fade: {
        opacity: {to: 0},
        onComplete: {Close : {} }
      }
    }
  }
});


Why is "clicking" represented twice? I know one is the name of the event and one is the callback, but that's irrelevant and confusing--this duplication seems to be consistent through the docs. Much simpler would be:

Code:
$proto('img#avatar', {
  onClick: {
      Fade: {
        opacity: {to: 0},
        onComplete: {Close : {} }
      }
    }
});


Also, why are some things Capitalized and some not? (why is "Close" capitalized above?) This is an additional detail that makes the syntax much harder to learn. Keep in mind that although there may be technical reasons for naming objects and events differently, this really doesn't matter at all to anyone who's not a programmer.

Consistency about when to use objects vs. numbers also bothers me: in this example, why does the "duration" property get a number after it, but the "opacity" property requires an object?:

Code:
$proto('img#avatar', {
  Fade: {
    opacity: {to: 0.0},
    duration: 0.9
  }
});


Yes, yes, I know there are reasons, but these kinds of things need to be simpler and more consistent, either make "opacity" take a single number (maybe as "startOpacity" and "endOpacity") or make all properties take objects.

I have high hopes for the GUI to avoid dealing with all this.

[heyo...@gmail.com]

> Why is "clicking" represented twice? I know one is the name of the event and one is the callback, but that's
> irrelevant and confusing--this duplication seems to be consistent through the docs.

Hope I wasnt't sounding too harsh here. I didn't mean "the docs are
inconsistent" which is not the case.

What I meant was the that this syntax itself should be designed like a
UI: self-consistent, predictible, intuitive, single clear points of
entry and control, etc. I think that the current abstraction doesn't
go far enough.

[b.s...@yahoo.com]

Yep, I understand your point completely.

The actual problem is they are too consistent.

Let me explain.

The syntax goes like this:

SELECTOR
  BEHAVIOR (events are behaviors too)
    ATTRIBUTES
    CALLBACK/BEHAVIOR
      ATTRIBUTES
      CALLBACK/BEHAVIOR


The Click is a behavior that actually wires up an event. It is different than the onClick which is a Callback. Not all callbacks correspond 1:1 with an explicit event.

For example DragDrop behavior has 8 or so callbacks (onStartDrag, onDragDrop, etc.)

All behaviors have a callback (normally... Fade has 3, Close has 1)

So to merge the concept of the callback onClick with the concept of wiring an event Click would not be possible to parse correctly.

To reiterate: behaviors can be a pure behavior or an event behavior. Behaviors can have callbacks.

To handle explicit event wiring and implicit event wiring and still support callbacks I was kind of forced into this model.

Now that does not mean the syntax is simple enough.

What I am about to start working on is the GUI expression for this nesting... but note that it won't look this complex (hopefully).

Typing JSON is not the end game for designers :-)


--
Bill