Properties

[Nick Sabalausky]

"Daniel Keep" <daniel.keep.lists at gmail.com> wrote in message 
news:gk8j4h$29fm$1 at digitalmars.com...
>
>
> Nick Sabalausky wrote:
>> String mixins are very powerful, and certainly welcome IMO, but they 
>> involve dynamically generating code by algorithmically splicing together 
>> little text snippets, and that's just very hack-ish. It's literally just 
>> like using classic-style ASP or PHP. That was too clumbsy even for the 
>> already-clumbsiness-embracing world of the web; that's why they're moving 
>> towards proper page-templating engines. I see the role of string mixins 
>> as being a handy way to hack together a piece of advanced functionality 
>> until a better more proper way comes along.
>
> I think the comparison is a bit loose; the problem with ASP and PHP was 
> the way most people mixed processing logic and display.  Here, there's a 
> relatively clean separation.
>

It's not so much an issue of logic vs display (if you're using a somewhat 
literal definition of "display"), as it is an issue of proper ways to 
dynamically generate code regardless of whether the generated output is a 
"display" description or a description of yet more logic (ex, generating 
client-side JavaScript using classic ASP/PHP techniques is still rightly 
considered just as bad as if HTML were being generated).

With that in mind, how do D string mixins have more logic/output separation 
than typical ASP or PHP? The actual implementation of the string-generating 
function (or template) still mixes logic with output.

Suppose you wanted to make a mixin that generated a bunch of int 
declarations from a list of names. How would you implement that? With 
current D, it would have to be something like this:

/ / Pseudocode
declareStuff(string[] names) // template or CTFE
{
    // Template-style would be mostly the same,
    // but maybe slightly more functional than imperative.
    string str;
    foreach(name; names)
       str ~= "int "~name~";\n"; // \n helps with debugging
    return str;
}

Now compare that to a fairly typical method for generating a list in 
classic-ASP/PHP:

/ / Pseudocode
generateList(string[] listElements)
{
    string str= "<ul>";
    foreach(elem; listElements)
       str ~= "<li>"~elem~"</li>\n";
    return str~"</ul>";
}

It's practically the same code, except that the web development world has 
been discovering that's in a bad style that leads to problems.

Although, maybe string mixins could make use of proper logic/output 
separation if we had better CTFE. Then we could use something like ANTLR's 
StringTemplate lib. But maybe that would lead to unnecessarily long compile 
times?

In any case, whenever I see "mixin(...);", even in my own code, I always 
think "hack". That's fine for obscure special-domain tools, but for 
something as common and as general as properties, it just comes across as a 
big kludge.

> Yes, a language-level construct for this would be nice, but where do you 
> draw the line?
>

IMO, Somewhere beyond "property syntax" ;-)

> Personally, I'm a big believer in generic constructs.  Let's pretend for a 
> moment that we've got AST macros, and can specify that our macro uses { } 
> instead of ( )...
>
> properties
> {
>     rw int foo;
>     ro float bar;
> }
>

If we had AST macros, and creating them was significantly cleaner than 
creating string mixins, then that would certainly reduce the need for 
language-level things like properties.

However, I would still very much insist that something as common as 
properties would, at the very least, be part of the standard library. It 
wouldn't be good for the language to have twenty different custom 
property-syntax libs floating around.