On Sun, 2012-06-17 at 18:06 +0200, Emil Lenngren wrote: > Instead of overriding, why not simply create a module that does things with > your array instead? > > Instead of > Public Function Decode(ivar as String[], pattern as Integer[]) as > Variant[] > > in some new array-class, > > you can simply have > Public Function Decode(array As Variant[], ivar as String[], pattern as > Integer[]) as > Variant[] > > in the new module. > > /Emil Yes, that's a good observation. In this case however, it was doing something like that that has got me the mess I am now trying to unravel.
This particular project is huge, over 18,000 lines of code, 16 modules and 35 classes. It has become that way because there was a fundamental design error made when it first started, that error was no-one did any design work on it. We have been patching and adding to it for the last 4 years (yes it started out as a gb2 project) instead of fixing the real problem. Executionally is is pretty simple. It takes a large unstructured text file and parses it, returning a structured set of extracted data and some information regarding bits that it could not handle but "look" interesting. For example, the input might be the content of a newsletter from one of the horse auctioneers listing upcoming auctions. Because these are written by different people each time, we get different token strings each time. So, for example, it tries to recognize and decode series of tokens that may represent a date. Things like "next Tuesday", "Tuesday next" "this Tuesday", etc. It also reports things that it cannot handle, say "at Tuesday next week's ..." would get reported as "Found occurrence of (date)(date) at token 234", since someone has coded a rule that two concurrent (date) tokens are not "sensible". Structurally, it is a mess. Different classes contain inline code to do the same things and, even worse, different classes use different modules containing functions that do the same thing. Recently we finally hit the inheritance tree depth limit. So we can no longer do what we have been doing, which is tack on another class to handle some newly discovered rules. One of our people has taken on the job of designing the whole thing from scratch as a rule based parser. I as punishment for my original sin, have taken on the task of trying to clean up the existing code so we can see what it is really doing in terms of token series analysis and parsing rules. So what I was looking for was a way to simply pull out the "mechanical" bits of the inline code (and module function calls) that obfuscate the real intent of a specific method. At several points in this monster's history, we have tried to do things like rationalise the set of modules into one super-module. Unfortunately, that resulted in sets of functions ("Decode1(int,int,int) as Date", "Decode2(int,str,int) as Date",.... "Decode39(str,int,str,int) as Date) all doing slightly different things, which just made things worse. And I haven't mentioned parsing peoples names yet! ("MacDonald", "McDonald","Mac Donald", etc) Anyway, thanks everyone for your input. Bruce ------------------------------------------------------------------------------ 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/ _______________________________________________ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user