moving from 2.7b to 2.8 - fixing compiler errors
in [Visual Objects]
|
Prev: Application Icon
Next: VO on a stick
From: Karl Faller on 17 Oct 2009 16:29 Chris, >It's because your method has CLIPPER calling convention and must return >something (a USUAL). >The methods Erik listed are strongly typed AS VOID methods, that do not >return anything anyway. ah, i see. But then there's a compatibility gap ;-), as VO rises a warning here... Good night! Karl
From: Geoff Schaller on 17 Oct 2009 19:46 Erik, My take on all this is a little more pragmatic. I believe all VO'ers should turn off this warning and fix all methods and functions to have an explicit return method. I have stopped many 5333's this way because I found a lot of methods that sometimes returned NIL and other times some value, from the same method. Enforcing this compiler setting meant that all such things were picked up. Strongly typing all methods that had a return value helped even more (but took more effort). I think it is worth doing for VO's sake, not just for 'good form' or Vulcan. Geoff "ER!k \/!sser" <nospam(a)nospam.com> wrote in message news:7jtd6sF365b87U1(a)mid.individual.net: > > VO can turn off most of those warnings so to help, list the types > > involved, turn them all off and then turn them back on one by one, fixing > > as you go. > > > > Some of the warnings are important to fix and you should. > > > > Others are warnings on code style that are needed if you want to go to > > Vulcan. But even if you don't these, are good practice things to fix > > anyhow so I recommend you do them. And then if you do want to try Vulcan, > > you are better positioned to do so. > > > Yeh, we have been told a lot of rubish. > Like we need return statements to make our code Vulcan ready. > But like other .NET languages, Vulcan accepts methods without a return > statement perfectly. . > I guess this mandatory return statement is only there for the transporter. > If this is the reason, it says a lot of the 'intelligence' of the > transporter. > > > Erik > > > > > > > > > > > > > Geoff > > > > > > > > "John Martens" <adsl672100(a)tiscali.nl> wrote in message > > news:4ad8ade7$0$28156$5fc3050(a)news.tiscali.nl: > > > > >> Just by the return lines in a method you will get loads of errors. > >> Going through them one by one is possibly just the best thing to do. > >> > >> > >> Phil Turner schreef: > >> > > >> > I posted a while ago but my post has gone, so here's the main part > >> > again. > >> > > >> > > >> > We finally got around to upgrading to 2.8 but have thousands of > >> > compilation errors. > >> > Is there a list anywhere of all the typical changes required? > >> > We are picking through these very slowly right now and a handful of > >> > global changes might make a big difference in our workload. > >> > > > >
From: Willie Moore on 17 Oct 2009 20:10 Geoff, I agree. Regards, Willie __________ Information from ESET NOD32 Antivirus, version of virus signature database 4518 (20091017) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
From: E®!k /!sser on 18 Oct 2009 04:03 Hi Geoff, For the record, all (most) of my methods are strong typed and I am using the -onlyearly- pragma whereever I can. My rule of thumb is that methods are of the boolean type, returning succeded or not. If I want another return value(s), I use a parameter(s) by reference. But my contribution was not about what I do or don't, but what VO forces me to do or don't and for what reason. I just prefer not to be forced into anything, and that goes even more if the reason for it is a lie. And for new features in VO I would prefer 'opting in' in stead of 'opting out' And again, nobody ever asked here for a mandatory return statement in the last line. And lots of things that have been asked and make more sense still didn't make it. Like the need for explicitly declaring strong typed methods. I really do not see any reason for that, and the compiler can just as easy add it himself as producing the errormessage. You mention 5333's . Haven't seen those often. Could you show me a piece of code that compiles but crashes with a 5333? Erik > My take on all this is a little more pragmatic. > > I believe all VO'ers should turn off this warning and fix all methods and > functions to have an explicit return method. I have stopped many 5333's > this way because I found a lot of methods that sometimes returned NIL and > other times some value, from the same method. Enforcing this compiler > setting meant that all such things were picked up. > > Strongly typing all methods that had a return value helped even more (but > took more effort). > > I think it is worth doing for VO's sake, not just for 'good form' or > Vulcan. > > Geoff > > > > "ER!k \/!sser" <nospam(a)nospam.com> wrote in message > news:7jtd6sF365b87U1(a)mid.individual.net: > >> > VO can turn off most of those warnings so to help, list the types >> > involved, turn them all off and then turn them back on one by one, >> > fixing >> > as you go. >> > >> > Some of the warnings are important to fix and you should. >> > >> > Others are warnings on code style that are needed if you want to go to >> > Vulcan. But even if you don't these, are good practice things to fix >> > anyhow so I recommend you do them. And then if you do want to try >> > Vulcan, >> > you are better positioned to do so. >> >> >> Yeh, we have been told a lot of rubish. >> Like we need return statements to make our code Vulcan ready. >> But like other .NET languages, Vulcan accepts methods without a return >> statement perfectly. . >> I guess this mandatory return statement is only there for the >> transporter. >> If this is the reason, it says a lot of the 'intelligence' of the >> transporter. >> >> >> Erik >> >> >> >> >> >> >> >> >> >> > >> > Geoff >> > >> > >> > >> > "John Martens" <adsl672100(a)tiscali.nl> wrote in message >> > news:4ad8ade7$0$28156$5fc3050(a)news.tiscali.nl: >> > >> >> >> Just by the return lines in a method you will get loads of errors. >> >> Going through them one by one is possibly just the best thing to do. >> >> >> >> >> >> Phil Turner schreef: >> >> >> >> >> > I posted a while ago but my post has gone, so here's the main part >> >> > again. >> >> > >> >> > >> >> > We finally got around to upgrading to 2.8 but have thousands of >> >> > compilation errors. >> >> > Is there a list anywhere of all the typical changes required? >> >> > We are picking through these very slowly right now and a handful of >> >> > global changes might make a big difference in our workload. >> >> > >> >> > >
From: Geoff Schaller on 18 Oct 2009 17:11
HI Erik, > the -onlyearly- pragma whereever I can. Ah... this I avoid 100%. Just strongly type your methods. You get nothing more important or useful going that extra step except a pain in the neck to code. > My rule of thumb is that methods are of the boolean type, returning succeded > or not. If I want another return value(s), I use a parameter(s) by > reference. This is actually a very useful concept but also a pain in the neck. I have a lot of methods which perform simple calculations that need several parameters. Returning a logic is often useless because the process has no point of failure and it just complicates the calling code. I am in two mids about this, whether it be VO or C#. And then there a methods that return arrays. I am still thinking through this one (10 years on... <g>) > I just prefer not to be forced into anything, and that goes even more if the > reason for it is a lie. You are not forced to do anything. You can in fact turn all these off in a matter of about 3 seconds so honestly, I don't see the big deal. And my preference is that they should be ON by default so you can gain some gravity about the circumstances your code finds itself under. > And again, nobody ever asked here for a mandatory return statement in the > last line. Yes they did and I am among them. > And lots of things that have been asked and make more sense still didn't > make it. Like the need for explicitly declaring strong typed methods. This is a language decision you will have to ask Sabo about and it is one aspect I would be happy to see disappear but I doubt Robert has the time and money from Brian to do much about. Maybe Robert can comment on whether it is easy or hard or what functionality it actually provides. > You mention 5333's . Haven't seen those often. > Could you show me a piece of code that compiles but crashes with a 5333? I don't have any right now but I can easily generated them. All I have to do is code for three days and I'll get one sooner or later. I'll be sure to send you a picture on my next occurrence <g>. Geoff |