stuart@cs.rochester.edu (Stuart Friedberg) (05/26/88)
In article <8805252116.AA21083@gilroy.dec.com> haynes@WSL.DEC.COM writes: >This is one of the reasons I hate C. In a reasonable language you would >have module initialization happen automatically at program startup. >Since C doesn't do this, you have to do your own initialization >MANUALLY. > [...] So I'm afraid you're stuck with >either initializing all of your classes manually, and registering the >type converter in the class initialization code, or providing an >explicit intializer for your stuff, and requiring your clients to call it. Nonsense. It is VERY EASY to write a module that does first time initialization in C. It adds maybe 10 lines of code to the module. There is no reason to either (A) require your clients to call an explicit initializer, or (B) initialize any class before a client wants to use it. To wit: static int module_initialized = 0; static void module_initialization() { /* initialize the module */ module_initialized = 1; } /* publically accessible creation routine */ module_create_a_widget() { if (!module_initialized) module_initialization(); /* create a widget or whatever */ } Stu Friedberg {ames,cmcl2,rutgers}!rochester!stuart stuart@cs.rochester.edu
haynes@WSL.DEC.COM (05/26/88)
> >This is one of the reasons I hate C. In a reasonable language you would > >have module initialization happen automatically at program startup. > >Since C doesn't do this, you have to do your own initialization > >MANUALLY. > > [...] So I'm afraid you're stuck with > >either initializing all of your classes manually, and registering the > >type converter in the class initialization code, or providing an > >explicit intializer for your stuff, and requiring your clients to call it. > > Nonsense. It is VERY EASY to write a module that does first time > initialization in C. It adds maybe 10 lines of code to the module. > There is no reason to either (A) require your clients to call an > explicit initializer, or (B) initialize any class before a client > wants to use it. To wit: Nonsense yourself. Go back and read the original statement of the problem. The problem is that you want to define your own resource type converter, and have it automatically registered. You could do it by registering the type converter in the class_initialize proc of some class that uses the new resource type (as Ray Hill, the original poster, points out) but that may be too late, since you may want to pass one of these things in the arglist to the create call for creating the first widget of that class. This is before the class is initialized. The convert proc (via XtConvert) may be the only way of getting resources of the required type, or may simply be the most convenient method. A reasonable language would provide automatic static intialization sections for exporting modules. This initialization section would get called by the initialization section of any module importing something from the exporting module. Some care must be taken to deal with the inevitable initialization cycles that recursive dependencies cause. This is effectively requiring the compiler to do the bookeeping that your example does explicitly. Of course C, lacking the notion of a module, or exports, or imports, can't provide the needed support; leaving it to the programmer. We have attempted in the toolkit to do some of this for you, with static class initialization. We can't do it all, as much as we would like to. -- Charles [If else anyone wants to debate the merits of C as a modern programming language, I suggest that they, and I, do it somewhere other than "xpert/comp.windows.x".]
chan@hpfcmr.HP.COM (Chan Benson) (05/28/88)
> [If else anyone wants to debate the merits of C as a modern programming > language, I suggest that they, and I, do it somewhere other than > "xpert/comp.windows.x".] I've been trying to restrain myself.... I don't really want to debate the merits of C. I don't really care whether you think C is modern or not. I want to know why (given that C was the language chosen) Xtk was not designed with the limitations of C in mind. Did it not occur to you that if you had to build another language on top of C to do what you wanted, that you were doing the wrong thing? This continual whining from the Xtk developers about the language they were "forced" to use does not help the advancement of Xtk. Can you imagine Sun employees posting bits like "Well, if Bill Joy had let us use a real language rather than this primitive PostScript stuff, we could have really made wonderful NeWS." -- Chan Benson HP Fort Collins Does this mean there won't be any Xtk Fortran bindings?
hyland@esosun.UUCP (Steve Hyland) (05/30/88)
In article <1210005@hpfcmr.HP.COM> chan@hpfcmr.HP.COM (Chan Benson) writes: >> [If else anyone wants to debate the merits of C as a modern programming >> language, I suggest that they, and I, do it somewhere other than >> "xpert/comp.windows.x".] > >I've been trying to restrain myself.... > >I don't really want to debate the merits of C. I don't really care >whether you think C is modern or not. I want to know why (given that >C was the language chosen) Xtk was not designed with the limitations >of C in mind. > >Did it not occur to you that if you had to build another language >on top of C to do what you wanted, that you were doing the wrong thing? > >This continual whining from the Xtk developers about the language >they were "forced" to use does not help the advancement of Xtk. Can >you imagine Sun employees posting bits like "Well, if Bill Joy had >let us use a real language rather than this primitive PostScript >stuff, we could have really made wonderful NeWS." > > -- Chan Benson > HP Fort Collins > >Does this mean there won't be any Xtk Fortran bindings? Actually, I find myself in agreement with both Charles Haynes and Chan Benson. I'm no great fan of C but I won't insult C programmers. I've had a number of C programmers question my sanity because I write X clients in Ada. Fine. I won't ask C programmers to use my binding. I think the binding you use should reflect the language your client will be written in. At the same time, each language binding must recognize that, in the best of all possible worlds, a client shouldn't know or care what language a server is written in. Additionally, no server should make assumptions about the language used to write the client. As we embark upon our second phase of development, that of writing all of Xlib in Ada, we try to keep this in mind. I hope those who work in C have a similar world view. Similarly, moaning about the limitations that C imposed upon Xtk or that Xtk imposes upon clients is unproductive. Xtk represents a lot of work and a test of a lot of interesting ideas. If I were to slavishly follow the design of Xtk in our toolkit work, I would be limiting myself to only a part of what Ada is capable of, not to mention producing some ugly code. If, however, I follow the spirit of Xtk - which I happen to like - then the Ada toolkit will be both similar to Xtk as well as capable of handling issues like tasking. I guess my point is, those of us who work in other languages won't criticize C if those who work in C don't assume that everyone using X works in C. 'Nuff said. I've either made my point or hopelessly insulted everyone. Steve Hyland SAIC