Rick McGuire <object.r...@gmail.com> wrote: > And indeed, you could also just change the name of the file used for > ::requires and keep the names the same. That would allow for a pretty > seamless upgrade path and it would still coexist with other programs that > used a different version.
I realise that it's possible that my questions make sense to me (but not, it seems, to you) because I don't properly understand all the ins and outs of the oo stuff. Also the issue is perhaps really a wider one for how ANY extension should be designed, not just the SQLite one, but this is the first such thing I've seen discussed here since joining this mail list. If one has two versions of the ooSQLite DLL and ooSQLite.cls installed, but given separate names (as I outlined earlier), I would expect there would be no problem if one user exec ::requires 'ooSQLite123.cls' and one had altered whatever it is within that cls file which specifies "ooSQLite.dll" and changed it to specify "ooSQLite123.dll", and a second user exec ::requires 'ooSQLite456.cls' (altered to use ooSQLite456.dll) but what happens then if a single user exec has ::requires 'ooSQLite123.cls' ::requires 'ooSQLite456.cls' - if you want in that exec to use several databases, but more than one version of the SQLite engine? How do you code the connection request (or any other method etc) and specify that it goes to the right set of class definitions and hence the right dll? If that's not possible, would you be able to achieve it by encapsulating all SQLite123 processing in one subroutine (with one ::requires) and all SQLite456 processing in a second subroutine (with the other ::requires)? -- Jeremy Nicoll - my opinions are my own ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
