Without getting too bogged down in implementation specifics, you're quite right - one of the requirements would be syntax checking and error reporting. I would prefer not to have a DSL (as is not unusual though) without decent reporting to locate and explain syntax errors.pytrin wrote:Does this means you'll be eval'ing the code..? This bring on another important point which is debugging. Unless you intend to build a full fledged parser, debugging the specifications written in this DSL would be very hard. A typo here and there would be very hard to track down
There will be eval() involvement since a DSL would be translated into PHP before execution so code generation is necessary.
Sorry if I got touchyarborint wrote:Then it is time to think outside both the PHP and Ruby boxes.
The main reason I noted Ruby is that its DSLs have a lower threshold of understanding for non-programmers. BDD has a significant focus on that aspect so it's not simply a question of using what PHP developers are familiar with. If that was the only concern I wouldn't be worrying about a DSL at all. This becomes a bit more obvious when it comes to specifying an application level behaviour (which an altogether different proposition than low level code specs).
I agree completely - the DSL should not be bogged down in what any language is doing. I would however like for the DSL to reflect some general formatting reminiscent of PHP itself since it would make the learning curve shallower (for example, calls on objects in the DSL are similar to PHP class, and use the "->" separator). None of this should be considered fixed though... It's just one my ideas (emphasis on me, as in individual
Yes, but the DSL is not an exact reflection of the final PHP. Imagine each Description being independent of any one class. When writing a spec for a class, you can import descriptions defined elsewhere, which in turn could be collections of other descriptive behaviour. There's a nesting effect instead of the straight line inheritance that's predominant (usually) in the xUnit world. Resolving the nesting from the DSL into PHP classes can be done, but the resulting PHP code itself is difficult to write without the benefit of the DSL. Not impossible - just more difficult.Jenk wrote:But you'd need to translate into native PHP for the purpose of executing the specs, surely?
Smalltalk would be a fine DSL - but PHP developers wouldn't know it, and the learning curve would drop in again. There's a balancing act I think that's worth following between the need for simplicity and what's familiar to a PHP developer.Jenk wrote:Usually I prefer to just stick to one syntax/DSL for all operations.. and that DSL being Smalltalk as quite frankly, it beats the pants off of everything else anyway.