Bug #4036

Implement Parser with Bridge design pattern

Details

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

Comments

[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.

[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.