Roman Neuhauser wrote: > # jochem@xxxxxxxxxxxxx / 2007-01-16 13:56:01 +0100: >> my gut says that it would be easiest to just keep to seperate copies of >> the utility class(es) one for each project, although it kind of depends >> on how large & complicated the utlity is ... this would remove all the described >> problems and leave you with only the 'slightly' inelegant situation where you >> have to, internally, sync the [relevant parts of the] 2 codebases now and again. >> >> given that there is a possibility of different version of the utility being >> required (as per you 'That is evil' reply) the '2 seperate copies of the codebase' >> approach might be simplest and most reliable way of tackling the problem ... >> again (AFAIKT) this mostly comes down to you personally being able to accept >> the relative inelegance of the solution. > > It's two if you only count Amock, but I already have another potential > use. If PHP had namespaces, I'd be happy. If PHP had a preprocessor, > I'd use that to get around the lack of namespaces and give each client > a non-conflicting, private version of the utility. Simple "copy&rename" > as you suggest would seem to lead to maintenance hell (read: bugs). if your utility implemented a mechanism to tell the using code it's version couldn't the using code use that to determine whether the minimum utility package version was available and simply bail out with suitable message if not ... again given that the utility class is exactly that it would be reasonable to assume that is be sufficiently simple to maintain BC, then again maybe not. could you point me at the svn web view that shows the utility code in question? it might give me some ideas. > >> I'm trying to act as an extra braincell here - forgive me if what I'm >> saying is way too simple to be worthwhile :-) > > Don't worry, I'm grateful for the input! And no, not too simple. After > all I'm not looking for something "sufficiently complicated", I'm > looking for something so easy even I won't screw it! okay then :-) > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
