M
marian.edu
Guest
Stefan, he only seems to have one character parameter as input to that method so I would find it hard to extract that to a ‘parameter object’ 
With OO addition to 4GL the compiler have to become smarter to cope with the strong typing feature that’s expected at compile time, thing is this is probably not an easy task when there are cross references so the compiler need to be able to check if every object referenced compiles. It might just be a bug on that specific environment although there might just be a simple PROPATH issue, there are also ways to help the compiler if you really need to run with compile on-the-fly although doing that in ‘production’ doesn’t sounds like a good idea. To start with I wouldn’t use a namespace like ‘app.Production’, the ‘app’ prefix doesn’t serve any purpose and having the ‘environment’ part of the namespace just doesn’t make any sense - use PROPATH for that if need be. Creating classes with the same name in different packages (especially if one inherits the other) in almost never a good idea, you can’t import both so one will have to be fully referenced making it easier for the fellow developers to get confused and mix them Programming to the interface is not a bad idea either, since there is no additional logic there the compiler usually finds it easier to compile interfaces so instead of using classes for parameters define interfaces and use those as parameters in methods definition. Marian Edu Acorn IT www.acorn-it.com www.akera.io +40 740 036 212
Continue reading...
With OO addition to 4GL the compiler have to become smarter to cope with the strong typing feature that’s expected at compile time, thing is this is probably not an easy task when there are cross references so the compiler need to be able to check if every object referenced compiles. It might just be a bug on that specific environment although there might just be a simple PROPATH issue, there are also ways to help the compiler if you really need to run with compile on-the-fly although doing that in ‘production’ doesn’t sounds like a good idea. To start with I wouldn’t use a namespace like ‘app.Production’, the ‘app’ prefix doesn’t serve any purpose and having the ‘environment’ part of the namespace just doesn’t make any sense - use PROPATH for that if need be. Creating classes with the same name in different packages (especially if one inherits the other) in almost never a good idea, you can’t import both so one will have to be fully referenced making it easier for the fellow developers to get confused and mix them Programming to the interface is not a bad idea either, since there is no additional logic there the compiler usually finds it easier to compile interfaces so instead of using classes for parameters define interfaces and use those as parameters in methods definition. Marian Edu Acorn IT www.acorn-it.com www.akera.io +40 740 036 212Continue reading...