Readability comes from clear syntax, not from english words separated by dots and brackets.
An expressive language (in programming) is good if it helps you understand what it means, not if it enables you to read it aloud to your boss. Also, I can't remember a single use of this kind of DSL in Wicket's API. OTOH, setters that return 'this' (AKA, configuration method chaining) are used everywhere. I don't like consistency just for consistency's sake, but in general I wouldn't make something inconsistent if the alternative is not much better (which is not the case). Tetsuo On Wed, Jun 8, 2011 at 9:30 AM, James Carman <[email protected]> wrote: > DSLs must be expressive. It's all about improving readability. > > Sent from tablet device. Please excuse typos and brevity. > On Jun 8, 2011 8:12 AM, "tetsuo" <[email protected]> wrote: >> I don't like the builder pattern in this case (specially with that >> verbose syntax), but I kind of like the idea of method chaining for >> additional (optional) configurations, with sensible defaults: >> >> add(new AttributeModifier("class", "selected")); // to overwrite the >> current value >> >> add(new AttributeModifier("class", >> "selected").setCreateAttribute(false)); // to not create the attribute >> if it does not exists (default is true) >> >> add(new AttributeModifier("class", "selected").append(" ")); // to >> append, separated by space >> >> add(new AttributeModifier("class", "selected").prepend(" ")); // to >> prepend, separated by space >> >> add(new AttributeModifier("style", "width:80%").pattern("width: >> *100%")); // to replace the value matched by the pattern (the current >> functionality of AttributeModifier) >> >> >> DSLs are useful, but they must be terse. Haiku, not sonnet. >> >> >> >> >> On Wed, Jun 8, 2011 at 8:03 AM, James Carman >> <[email protected]> wrote: >>> I like the idea of the builder pattern much better. DSLs rock! >>> >>> Sent from tablet device. Please excuse typos and brevity. >>> On Jun 8, 2011 6:35 AM, "Martin Grigorov" <[email protected]> wrote: >>>> or builder pattern: >>>> >>>> AttributeModifier.attr("name").model(someModel).create().append() >>>> >>>> On Wed, Jun 8, 2011 at 12:27 PM, Martijn Dashorst >>>> <[email protected]> wrote: >>>>> Taken from the user@ list, where it might get snowed under... >>>>> >>>>> The SimpleAttributeModifier, AttributeAppender and AttributePrepender >>>>> classes are in my opinion stop gap measures to work around issues with >>>>> AttributeModifier's API. >>>>> >>>>> I think that we could do better API wise with three factory methods (or > 6 >>> if >>>>> we duplicate each method to take an IModel<?> and a String for >>>>> convenience) on AttributeModifier, and deprecate > SimpleAttributeModifier >>>>> and AttributeAppender. I'd also merge the appender/prepender logic into >>>>> attribute modifier, such that user specializations can make use of >>>>> them. >>>>> >>>>> AttributeModifier.setAttribute(String attribute, IModel<?> value); >>>>> AttributeModifier.setAttribute(String attribute, String value); >>>>> AttributeModifier.prependAttribute(String attribute, String value); >>>>> AttributeModifier.prependAttribute(String attribute, IModel<?> value); >>>>> AttributeModifier.appendAttribute(String attribute, String value); >>>>> AttributeModifier.appendAttribute(String attribute, IModel<?> value); >>>>> >>>>> Or perhaps: >>>>> >>>>> AttributeModifier.overwrite(String attribute, IModel<?> value); >>>>> AttributeModifier.overwrite(String attribute, String value); >>>>> AttributeModifier.prepend(String attribute, IModel<?> value); >>>>> AttributeModifier.prepend(String attribute, String value); >>>>> AttributeModifier.append(String attribute, IModel<?> value); >>>>> AttributeModifier.append(String attribute, String value); >>>>> >>>>> I'd value input on the naming of things. >>>>> >>>>> Martijn >>>>> >>>> >>>> >>>> >>>> -- >>>> Martin Grigorov >>>> jWeekend >>>> Training, Consulting, Development >>>> http://jWeekend.com >>> >
