On 2010-07-16, at 06:36, André Bargull wrote: > I fully support your idea, but I've still got some questions for you, they > vary from very simple ones to quite implementation-specific ones. I just want > to make sure we're not going to be too loose in the specification phase. > (Most of them need to be answered at some point in the implementation process > anyway.) > > Questions: > - In the current proposal, the `implementation` value seems to be unused. Is > it necessary to have this value at all?
I was intending it to be for documentation, but it could be inferred from the result-type of the accept method. > - `implementation` doesn't sound that mnemonic, is there a better name? The current documentation uses "LZX Type" and "JS Type". I'm not sure that is any better. I'm certainly open to suggestions! > - How is <type> mapped to a lzs-class? Does it take the same approach as the > current built-in presentation types, that means a class with two static > methods accept() and present()? I think it might be better to revise the built-in types to be along the singleton pattern, a class with instance methods with a single instance. Inheritance works much more naturally that way (rather than the current kludge where related types inherit 'manually'). It would allow you to define a type that specializes an existing type, which I think could be very powerful. > - Can you add additional <method>s and <attribute>s to a <type>? Yes, you might need support methods or attributes. We may extend the required methods (e.g., the `validate` and `describe` methods I mention). Initially, the only required methods are `accept` and `present`. > - Is <type> going to be a top-level element? Yes, it is really just a specialized <class> > - Will it be possible to define types in script? No. Is there a need? > - accept() and present() aren't typed in your proposal, why did you omit > typing? Laziness. But also, if we permit type extensions (<type name="range" extends="number">, for instance), you will not be able to accurately type them because (at least on as3 platform) method overrides must have identical (invariant) type signatures, there is no support for co-/contra-variant signatures. We could work around this by making the problem argument/parameter (the implementation type) be the dispatched argument: `accept` would take a String as an argument and return a new instance of PresentationType, `present` would be a method of no arguments (dispatched on the subtype of PresentationType) and return a String. But this would mean we would be allocating PresentationTypes (may not be a bad thing), and just push the type-signature problem off on some other method (we'd still need something like `getImplementationValue` on PresentationType to extract the implementation representation, and that would have to have a type of `*`, to fit in the as3 type system. I'm ambivalent a! bout this. I lean toward the original proposal as being more efficient (less allocation) even if it cannot be as type accurate. But, maybe there are benefits to actually allocating PresentationType instances -- it would allow us to store more information with each value, such as: the original input, for types with multiple representations (color) a preferred representation, etc. These PresentationTypes could replace <basevaluecomponent>, as mentioned in http://jira.openlaszlo.org/jira/browse/LPP-7354 (which is what is at the base of all this). > - Which attributes / methods are required for <type>, will there be useful > defaults? accept and present are required. If you are subclassing another type, the defaults are probably useful. We could possibly make `expression` be the default type you inherit from, but I think that is dangerous -- expression is a little sloppy (because we did not require self-typing representations the way JSON does), so it can't work reliably as a default. I think the only useful defaults we can have is to signal an error if you leave out accept or present and are not extending another type. > - Is it an (compile time) error to refer to a type in <attribute> when there > is no matching <type>? Yes (including the built-in types as being <type>s). > - Is it an (compile time) error to have two types with the same name? Yes. My recent substrate change to support user-defined types makes both of these checks at compile-time. > - Will it be possible to override built-in presentation types? No. That is an error. I think it will be useful (and possible) to subclass them. > - Will it be possible to defer loading of presentation types, that means can > you place <type> in <import>ed libraries? (Possible implications with > stricter typing and the as3 runtime?) Certainly not initially. That would require a huge amount of effort for very little benefit (that I can see). > - Will you add examples to the dev-guide and other places, so people will be > aware of this new feature? Well, eventually. This initial effort is in direct support of making new/better components. > - What about creating a wiki-page for the proposal, maybe that will make it > easier to amend the proposal in comparison to an e-mail conversion! ;-) Always a good idea, although I find the overhead of creating a wiki page to be stifling. An email conversation seems much more efficient for thrashing out the initial idea. Once things are reasonably well agreed on, a wiki page is useful. Thanks for the feedback! > - André > > >> The name that does the accept/present is the value of `name`, the >> `implementation` value is the internal representation type. >> >> So with: >> >> <node name="foo"> >> <attribute name="x" type="boolean" ...> >> >> you are meant to be able to say: >> >> foo.acceptAttribute('x', "false"); >> >> and the system knows that 'x' has a type of 'boolean' so it looks up the >> 'boolean' type, and calls (effectively): >> >> foo.setAttribute('x', lz.PresentationTypes['boolean'].accept("false")); >> >> to convert the string representation "false" into the Boolean implementation >> `false`. >> >> Perhaps a more compelling example would be for the type `color`, which knows >> how to parse lots of different color representations, it's declaration would >> be: >> >> <type name="color" implementation="Number"> >> ... >> </type> >> >> <attribute name="bgcolor" type="color" /> >> >> You can say: >> >> foo.acceptAttribute('bgcolor', "red"); >> foo.acceptAttribute('bgcolor', "#FF0000"); >> foo.acceptAttribute('bgcolor', "rgb(100%,0,0)"); >> foo.acceptAttribute('bgcolor', "hsv(0,100%,100%)"); >> >> and they all mean the same thing. >> >> On 2010-07-15, at 15:46, Henry Minsky wrote: >> >> >/ In your proposed syntax, does the value you specify for "implementation" >> />/ becomes the classname that implements the accept/present behavior for >> the >> />/ type? >> />/ >> />/ >> />/ >> />/ On Thu, Jul 15, 2010 at 3:33 PM, P T Withington<ptw at pobox.com >> <http://www.openlaszlo.org/mailman/listinfo/laszlo-dev>> wrote: >> />/ >> />>/ We want to add the ability for LZX programmers to define new attribute >> />>/ types, beyond the built-in `boolean`, `number`, `string`, etc. >> />>/ >> />>/ For data-binding, we use the concept of a "presentation type" that >> knows >> />>/ how to "accept" a string-representation of a type value and convert it >> to >> />>/ the internal (Javascript) implementation, and how to "present" the >> />>/ implementation value as a string-representation. This is similar to >> the >> />>/ concept of serialization or JSON representations. Unlike JSON, we >> don't >> />>/ require self-typing representations. Our representations have an >> implicit >> />>/ schema. (I.e., in JSON, you know a value is a String because it is >> />>/ represented in quotes. We implicitly associate a type with a >> representation >> />>/ in data-binding, because the type of the bound attribute defines how >> the >> />>/ representation will be converted.) >> />>/ >> />>/ Here's an example of how one might write the existing built-in type >> />>/ boolean: >> />>/ >> />>/ <type name="boolean" implementation="Boolean"> >> />>/ <method name="accept" args="string"> >> />>/ // Be liberal in what you accept... >> />>/ switch (string.toLowerCase()) { >> />>/ case "": case "0": case "false": >> />>/ return false; >> />>/ default: >> />>/ return true; >> />>/ } >> />>/ </method> >> />>/ <method name="present" args="value"> >> />>/ // ... strict in what you present >> />>/ return (!! value)? "true" : "false"; >> />>/ </method> >> />>/ </type> >> />>/ >> />>/ Basically, a type is initially going to have two methods, `accept` and >> />>/ `present`. We may add more protocol in the future (such as a >> `validate` >> />>/ method that will check if a string represents a valid member of the >> type, >> />>/ and a `describe` method that can be used to prompt for input). >> />>/ >> />>/ By letting new types be implemented in LZX, we hope to make it easy to >> />>/ data-bind more complex types. >> />>/ >> />>/ Comments and input appreciated. >> />>/ >> />/ >> />/ >> />/ >> />/ -- />/ Henry Minsky >> />/ Software Architect >> />/ hminsky at laszlosystems.com >> <http://www.openlaszlo.org/mailman/listinfo/laszlo-dev> >> /
