Properties

[Daniel Keep]

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.

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

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;
}

That might as well be a language construct!  And D isn't as bad as C/C++ 
when it comes to inscrutible error messages; we at least have 
pragma(msg), although I admit it would be nice to have more control over 
where the compiler says an error comes from, and what the code 
responsible is.

At the end of the day, my job is to make a computer do stuff.  If string 
mixins help me reach that goal quicker [1], then I'm all for it.

  -- Daniel

[1] Obviously, I don't mean "at all costs;" something like:

   mixin(/* a long, complex expression that produces a string */);

is pretty obviously a bad idea for exactly the reasons you gave above. 
Something like:

   mixin(hhfk("kjiq9238*)&70394{"));

is also a bad idea, for rather obvious reasons.