Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 0.7.0

Request #4036 Implement Parser with Bridge design pattern
Submitted: 2005-04-03 05:07 UTC
From: epte at ruffdogs dot com Assigned:
Status: Closed Package: SQL_Parser
PHP Version: Irrelevant OS: Linux/Gentoo
Roadmaps: (Not assigned)    
Subscription  


 [2005-04-03 05:07 UTC] epte at ruffdogs dot com
Description: ------------ Conceivably, the Parser may differ behavior-wise between different dialects. For example, if one dialect allows FROM clauses within UPDATE statements, another might not. A bridge design pattern would fit this problem space well, allowing a Parser abstract class, with {MySQL,MSSQL,ANSI,etc} derived classes, each calling functions from a Parser_Implementation. Then you have different implementation derived classes for each dialect. This pattern is flexible enough to handle any differences between dialects, including changes in policy. The current setup only handles differences in allowed symbols.

Comments

 [2005-04-03 05:44 UTC] epte at ruffdogs dot com
Wow, was I thinking about that wrong. You wouldn't have MySQL_Abstract_Parser <-> MySQL_Parser_Implementation split, because you would never want to do MySQL_Abstract_Parser <-> MSSQL_Parser_Implementation. A bridge makes no sense in this scenario. But something does need to happen to make this code closed against policy changes. Probably making the dialects full-fledged subclasses with template methods is the way to go.
 [2005-04-06 04:40 UTC] busterb
I think we can safely stick with setting little behavior change flags in the dialect files for now. The differences in behavior are so minor.