moving from 2.7b to 2.8 - fixing compiler errors
in [Visual Objects]
|
Prev: Application Icon
Next: VO on a stick
From: E®!k /!sser on 19 Oct 2009 05:56 Hi Geoff, >> 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. Well I must say I use this 'for ages' now, but at the time I started it , I had the idea my code compiles faster and the executionspeed has improved. > >> 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 would not want to force anybody into my 'rules'. And I am not sure if 'rule of thumb' is the right expression, I did not want to suggest I use it always and everywhere. But in most cases it is my prefered scenario, even for simple calculations. My idea is something can always go wrong. I have learned the hard way if I cannot think of a way how it can go wrong today, that does not mean it will never fail.... Even simple arithmatic can fail, a zero division, or an integer overflow etc. >> 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. Well let me say I would have prefered a default OFF, than you can switch it ON in three seconds..... >> And again, nobody ever asked here for a mandatory return statement in the >> last line. > > Yes they did and I am among them. If you say so, I am sure you asked for it, but it was never discussed here (before it was implemented) > >> 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. No need to make big changes to the compiler. If you can generate an error/warning message, you can also add it to the code. >> 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>. You would make me more than happy if you (or anybody else) showed me some code that can reproduce a 5333. Cheers, Erik
From: Geoff Schaller on 19 Oct 2009 18:00 Hi Erik. > Well I must say I use this 'for ages' now, but at the time I started it , I > had the idea my code compiles faster and the executionspeed has improved. No to both <g>. Sorry to be the bearer of bad news <g>. > I would not want to force anybody into my 'rules'. > it can go wrong today, that does not mean it will never fail.... Even > simple arithmatic can fail, a zero division, or an integer overflow etc. But this is not true and the reason for my dilemma. As I said, the calling code is made more complex for the fact you now need to pass items by reference. What about Access and Assign code that has computational logic behind it? It wouldn't make sense to force all these to revert to passing a logic. Hence I don't find the need consistent at all. I am draw to the consistency argument but repelled by the complexity issues. > Well let me say I would have prefered a default OFF, than you can switch it > ON in three seconds..... But that defeats the aim of these compiler warnings and that is to improve and tighten code. It would be ignored mostly if applied your way. > If you say so, I am sure you asked for it, but it was never discussed here > (before it was implemented) Wrong. It absolutely was discussed. > No need to make big changes to the compiler. If you can generate an > error/warning message, you can also add it to the code. Yes, but are you and I in a position to assess this? That is why I asked for Robert's comment on the matter. Perhaps it is easy and perhaps it isn't. I suspect it is not. > You would make me more than happy if you (or anybody else) showed me some > code that can reproduce a 5333. I don't understand. You are not able to write code that creates a memory access error? How about you ask all those folks who post notices here of problems they have which cause 5333's that they ask help with? Geoff
From: Phil Turner on 20 Oct 2009 04:25 Thanks for all the comments guys. Looks like our daily 5333's might get cleaned up. I would really like to join the elite 'I have no 5333 errors' club. Looks like we have to just trawl through them all .... time to get the coffee injection!!
From: E®!k /!sser on 20 Oct 2009 04:52 Hi Geoff, >> Well I must say I use this 'for ages' now, but at the time I started it , >> I >> had the idea my code compiles faster and the executionspeed has improved. > > No to both <g>. Sorry to be the bearer of bad news <g>. Wouldn't be so sure about that. Here is a part of a message from Robert, where you discussed this subject: <snip message 09-06-2007 RvdH> - Because Classmate declares most of the method as 'onlyearly' classmate apps load faster (they don't create the method tables in the runtime that are needed in latebound code). </snip> >> I would not want to force anybody into my 'rules'. >> it can go wrong today, that does not mean it will never fail.... Even >> simple arithmatic can fail, a zero division, or an integer overflow etc. > > But this is not true and the reason for my dilemma. As I said, the calling > code is made more complex for the fact you now need to pass items by > reference. What about Access and Assign code that has computational logic > behind it? It wouldn't make sense to force all these to revert to passing > a logic. Hence I don't find the need consistent at all. I am draw to the > consistency argument but repelled by the complexity issues. Well I would strongly advise everybody _not_ to use 'computational logic ' inside an ssign or access. At least I would never use this. In fact, since a strong typed Assign-method cannot return another valuetype than the one passed, all my (new) assigns are declared as VOID. Benifit in my appproach is I do not have to check for invalid returnvalues. > >> Well let me say I would have prefered a default OFF, than you can switch >> it >> ON in three seconds..... > > But that defeats the aim of these compiler warnings and that is to improve > and tighten code. It would be ignored mostly if applied your way. I guess we have different opinions on this. > >> If you say so, I am sure you asked for it, but it was never discussed >> here >> (before it was implemented) > > Wrong. It absolutely was discussed. > >> No need to make big changes to the compiler. If you can generate an >> error/warning message, you can also add it to the code. > > Yes, but are you and I in a position to assess this? That is why I asked > for Robert's comment on the matter. Perhaps it is easy and perhaps it > isn't. I suspect it is not. > >> You would make me more than happy if you (or anybody else) showed me some >> code that can reproduce a 5333. > > I don't understand. You are not able to write code that creates a memory > access error? How about you ask all those folks who post notices here of > problems they have which cause 5333's that they ask help with? Geoff, as I wrote before, I do not see 5333's. and I wonder why. It do not assume it is because of my suberb coding style :). Erik
From: Karl Faller on 20 Oct 2009 05:33
On Tue, 20 Oct 2009 10:52:25 +0200, E�!k \\/!sser <nospam(a)nospam.com> wrote: >Well I would strongly advise everybody _not_ to use 'computational logic ' >inside an ssign or access. then why bother writing them at all? curious Karl |