Re: Re: Driver Interface and protected properties

Hi Mark, Mark Wiesemann wrote: > Olivier Guilyardi wrote: > >> Because drivers are considered user-space code, I am worried about these >> properties : do you think that all interactions between the base class >> and >> drivers should be method-based, and all properties made private ? > > I would differ between real user-space code (i.e. code that _uses_ SDG) > and code that extends SDG for usage in user-space code. Therefore, I > would stay with the current situation. Which properties could be > accessed or changed is clearly stated in the phpdoc comments. As you have recently seen, we've spent a lot of time trying to adress the BC problems that the SDG::renderer public property caused, and we just chose to break BC about this. This would have been avoided if this property had always been private, and only available through the public SDG::getRenderer() method. I've just checked the DB, MDB2 and LiveUser packages and their drivers make use of some protected properties that come from the base class. The thing is that it isn't as much expected from users to write a DB or MDB2 driver as it is in DataGrid, especially with renderers. Once most of the majors RDBMs are supported, people just don't need to write their drivers. But with DataGrid it is different, especially because writing a driver, or extending an existing one, is very recommended to users in order to answer a wide range of specific needs, without us having to implement a thousand of options into SDG. This is somewhat similar to LiveUser, although I think that LiveUser's storage drivers are doing a simpler job. So in addition to the difference you make between "real" user-space code and user-made drivers, I would also differ between : - the driver layers for which drivers are usually written by package developers, such as DB and MD2 - the driver layers which are designed for users to write a driver as often/easily as they would usually call a method Many SDG drivers may pop here and there, and these drivers we'll never hear about because they'll answer a specific need in a specific application somewhere specific on earth. If we need to change something in the core renderer layer we may then cause BC breaks for such users, exactly as what's happening with the SDG::renderer property. For now SDG is beta, but think of tomorrow when it will be stable. We may have a great idea, but these properties may forbid us to code it, because they'll put heavy BC constraints on us. The same thing may happen to LiveUser. The alternative I'm thinking about is simply to let the driver call some protected methods in order to get what it needs, and to make a better use of the arguments that are passed to the protected methods which are part of the driver interface. It's nothing very complex to do, although it will not be as light as using properties directly. Regards, -- og