chip@tct.uucp (Chip Salzenberg) (03/02/91)
According to pcg@cs.aber.ac.uk (Piercarlo Grandi): pcg> 1) Objective C does allow you to declare explicitly the type of objects, pcg> via a cast like notation. chip> Allow, yes, but not require. pcg> Just like C++, in the opposite direction. C++ requires _some_ type information before any member functions (either virtual or non-virtual) can be called. As I understand it, Objective C does not require any type information whatever to send a message. Reasonable people can disagree on the correct alternative between these two. For my part, I prefer the C++ solution. I believe it to be a natural consequence of forest-vs-tree inheritance, which I also prefer. chip> Besides, as far as I know, there is no guarantee that the message chip> set supported by a given class will not expand after the users of chip> that class have already been compiled. pcg> The idea in Objective C is that you resolve statically what you can, and pcg> turn to dynamic overloading for what you cannot. But the Objective C compiler never knows when you have made an error by sending a message that the recipient cannot understand. That error is impossible in a C++ program. pcg> ... [in Objective C, a message] just gets resolved dynamically instead of pcg> statically. In C++ you simply don't have this option in the general case. True. I consider this omission a feature, personally; it keeps me from discovering at run-time that I have requested an impossible operation -- an error the compiler could have detected. (Issues of efficiency of virtual vs. non-virtual C++ member functions have been deleted from the quoted article. If you can't stand the cost of one add and one indirection during function call, you should be writing assembler. ;-)) pcg> Objective C has to use hash tables or caching, hinting, and the like. pcg> [3] Does it make a large difference to the overall runtime? pcg> [3] For most applications, a quite small difference. I can believe it. The cost doesn't bother me that much. After all, were I a real speed freak, I'd still be hacking assember code. pcg> Efficiency advantages that are important for systems programming, but pcg> not for most applications, are C++ support for inline functions and pcg> objects. These are IMNHO far more important than the relative speed of pcg> relatively infrequent dynamic overload resolution. Agreed, though my applications programs just might be noticably slower if inline functions for key objects such as Buffer and String were not available. pcg> I am not very current on Objective C ... Hopefully the new Objective C pcg> book will come out eventually. Neither am I, and I look forward to the same book. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip>
gwu@nujoizey.tcs.com (George Wu) (03/08/91)
In article <27CE9C05.4F64@tct.uucp>, chip@tct.uucp (Chip Salzenberg) writes: |> According to pcg@cs.aber.ac.uk (Piercarlo Grandi): |> chip> Besides, as far as I know, there is no guarantee that the message |> chip> set supported by a given class will not expand after the users of |> chip> that class have already been compiled. |> |> pcg> The idea in Objective C is that you resolve statically what you can, and |> pcg> turn to dynamic overloading for what you cannot. |> |> But the Objective C compiler never knows when you have made an error |> by sending a message that the recipient cannot understand. That error |> is impossible in a C++ program. |> |> pcg> ... [in Objective C, a message] just gets resolved dynamically instead of |> pcg> statically. In C++ you simply don't have this option in the general case. |> |> True. I consider this omission a feature, personally; it keeps me |> from discovering at run-time that I have requested an impossible |> operation -- an error the compiler could have detected. I would consider this sort of run-time error checking inadvisable for commercial products, to say nothing of mission critical applications, although I'm sure there are people out there using Objective C and Smalltalk for commercial systems. It simply isn't a good idea for a sold product in customer hands to crash with an error. (Yeah, I've seen commercial systems core dump, too. :-) It's just easier to have high confidence in software which does as much error checking as possible at compile time. Of course, if one just performed exhaustive testing before releasing a product . . . . George ---- George J Wu, Software Engineer | gwu@tcs.com or uunet!tcs!gwu Teknekron Communications Systems, Inc.| (415) 649-3752 2121 Allston Way, Berkeley, CA, 94704 | Quit reading news. Get back to work.
gwu@nujoizey.tcs.com (George Wu) (03/09/91)
-
Please forgive me if this message appears twice. My machine croaked at
precisely the wrong time. I'll ignore the hint, if you don't mind. :-)
In article <27CE9C05.4F64@tct.uucp>, chip@tct.uucp (Chip Salzenberg) writes:
|> According to pcg@cs.aber.ac.uk (Piercarlo Grandi):
|>
|> chip> Besides, as far as I know, there is no guarantee that the message
|> chip> set supported by a given class will not expand after the users of
|> chip> that class have already been compiled.
|>
|> pcg> The idea in Objective C is that you resolve statically what you
can, and
|> pcg> turn to dynamic overloading for what you cannot.
|>
|> But the Objective C compiler never knows when you have made an error
|> by sending a message that the recipient cannot understand. That error
|> is impossible in a C++ program.
|>
|> pcg> ... [in Objective C, a message] just gets resolved dynamically
instead of
|> pcg> statically. In C++ you simply don't have this option in the
general case.
|>
|> True. I consider this omission a feature, personally; it keeps me
|> from discovering at run-time that I have requested an impossible
|> operation -- an error the compiler could have detected.
For commercial systems, to say nothing of mission critical
applications, run-time error generation is a drawback. I'm sure there are
poeple out there using Objective-C, Smalltalk, and Lisp to develop
commercial systems, and what's a core dump but a run-time error, but it is
always better to get as much error checking done at the compile stage. The
mere potential for run-time errors implies more testing and less overall
confidence in the stability of an application, to be avoided where possible
for commercially delivered applications.
George
----
George J Wu, Software Engineer | gwu@tcs.com or uunet!tcs!gwu
Teknekron Communications Systems, Inc.| (415) 649-3752
2121 Allston Way, Berkeley, CA, 94704 | Quit reading news. Get back to work.carroll@cis.udel.edu (Mark Carroll) (03/12/91)
In article <1860@news.tcs.com> gwu@nujoizey.tcs.com (George Wu) writes: ]In article <27CE9C05.4F64@tct.uucp>, chip@tct.uucp (Chip Salzenberg) writes: ]|> According to pcg@cs.aber.ac.uk (Piercarlo Grandi): ]|> chip> Besides, as far as I know, there is no guarantee that the message ]|> chip> set supported by a given class will not expand after the users of ]|> chip> that class have already been compiled. ]|> ]|> pcg> The idea in Objective C is that you resolve statically what you ]can, and ]|> pcg> turn to dynamic overloading for what you cannot. ]|> ]|> But the Objective C compiler never knows when you have made an error ]|> by sending a message that the recipient cannot understand. That error ]|> is impossible in a C++ program. ]|> ]|> pcg> ... [in Objective C, a message] just gets resolved dynamically ]instead of ]|> pcg> statically. In C++ you simply don't have this option in the ]general case. ]|> ]|> True. I consider this omission a feature, personally; it keeps me ]|> from discovering at run-time that I have requested an impossible ]|> operation -- an error the compiler could have detected. ] ] I would consider this sort of run-time error checking inadvisable for ]commercial products, to say nothing of mission critical applications, ]although I'm sure there are people out there using Objective C and Smalltalk ]for commercial systems. It simply isn't a good idea for a sold product in ]customer hands to crash with an error. (Yeah, I've seen commercial systems ]core dump, too. :-) It's just easier to have high confidence in software ]which does as much error checking as possible at compile time. Of course, ]if one just performed exhaustive testing before releasing a product . . . . ] I think that you're missing something fairly important here. The fact that Objective-C is primarily dynamically bound does not mean that it is any less safe than a fully statically bound language in the general case. Most of the time, Objective-C is used in a way which could be trivially translated into a fully static language like C++. In those cases, Objective-C COULD catch any of the errors which C++ could catch. (I don't know if the Stepstone compiler actually does, but by using dataflow analysis to bind statically whenever possible, any of the errors that could be caught statically in C++ could be caught statically in Objective-C. Objective-C just transfers the burden to the compiler, rather than the programmer.) In other cases, when you are expressing something as a message pass that could not be expressed as a member function call in C++ (i.e., using the perform: method), you are doing something "less safe" than you would in C++. But those cases are easy to identify in the code, and by scaffolding them inside of a safety test (low budget assertion testing...), you can insure that they will indeed execute safely. Basically, I think this whole mess comes down to this: Static versus dynamic binding is a matter of personal taste. I personally very much prefer to work with a more dynamic language. I think that my programs are much more elegant written in a dynamic style, and I think that my code written in a dynamic language is much better than my code written in a static language. So, when I need to use a C-family language, I'll stick with Objective-C. If you like static programming, you'll think that I'm out of my gourd, that I'm a fool, or whatever, and you'll stick with your static language. ] George <MC> -- ---------------------- Mark Craig Carroll: <MC> ------------------------ ------ U of Del. Grad Student in CIS ------ EE/CIS LabStaff Hacker ------ -- Resident Wierdo @ 105 E Cleveland Ave, Newark DE - carroll@udel.edu -- ---------------------- Shalom Achshav - Peace NOW! ----------------------
cox@stpstn.UUCP (Brad Cox) (03/12/91)
In article <1861@news.tcs.com> gwu@nujoizey.tcs.com (George Wu) writes: >always better to get as much error checking done at the compile stage. The >mere potential for run-time errors implies more testing and less overall >confidence in the stability of an application, to be avoided where possible >for commercially delivered applications. I heard this so often that I suppose you must all be right. All right, you win, you win! I surrender. I'll embrace fabrication-time binding and forget about dynamic assembly of pre-fabricated off-the-shelf components, where the only type safety is provided by us dumb old fallible humans. I'll have the dynamic binding on my ski boots welded to remove any possibility of run-time errors. Or better yet, since I might forget to close the boot snaps, or even wear the wrong boots. How'd we apply compile-time binding strong type-checking, and inheritance latices to that? I know! Fabrication-time binding...at conception time! No more ski binding errors! (Of course, my reusability for other than skiing would suffer... but won't the strong type-checking be wonderful! I'll only buy electronics that are completely wafer scale integration, to remove any possibility of assembly-time misconnections. Can anybody recommend a good place to buy wafer-scale CD players; wafer-scale hi-fi sets, cars, and living rooms? A wafer-scale universe? I'll only fly on airplanes that were cast as a unit from a mold, since assembly-time binding might cause core dumps (or worse ;-) ) No sirree, none of that bad old dynamic assembly-time binding for me. I'm going to settle on fabrication technologies where the parts and the whole come into existence simultaneously, to make dynamic (assembly-time) binding errors will be a thing of the past. Anyone else want to join me in this perfectly type-safe world? -- Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875 The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482
tynor@hydra.gatech.edu (Steve Tynor) (03/12/91)
In article <6648@stpstn.UUCP> cox@stpstn.UUCP (Brad Cox) writes:
...
No sirree, none of that bad old dynamic assembly-time binding for me.
I'm going to settle on fabrication technologies where the parts and the
whole come into existence simultaneously, to make dynamic (assembly-time)
binding errors will be a thing of the past.
Anyone else want to join me in this perfectly type-safe world?
Strong typing does NOT imply static binding - It's possible to be type
safe AND completely avoid static binding. Check out Eiffel. Heck, it
can even be done in C++ if you're careful to specify that all your
methods are 'virtual'.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Language is a virus from outer space" - William S. Burroughs
Steve Tynor
Georgia Tech Research Institute
tynor@prism.gatech.edugwu@nujoizey.tcs.com (George Wu) (03/15/91)
In article <47199@nigel.ee.udel.edu>, carroll@cis.udel.edu (Mark Carroll) writes: |> In article <1860@news.tcs.com> gwu@nujoizey.tcs.com (George Wu) writes: |> ] I would consider this sort of run-time error checking inadvisable for |> ]commercial products, to say nothing of mission critical applications, |> ]although I'm sure there are people out there using Objective C and Smalltalk |> ]for commercial systems. It simply isn't a good idea for a sold product in |> ]customer hands to crash with an error. (Yeah, I've seen commercial systems |> ]core dump, too. :-) It's just easier to have high confidence in software |> ]which does as much error checking as possible at compile time. Of course, |> ]if one just performed exhaustive testing before releasing a product . . . . |> ] |> |> I think that you're missing something fairly important here. |> |> The fact that Objective-C is primarily dynamically bound does not mean |> that it is any less safe than a fully statically bound language in the |> general case. |> |> Most of the time, Objective-C is used in a way which could be trivially |> translated into a fully static language like C++. In those cases, Objective-C |> COULD catch any of the errors which C++ could catch. (I don't know if the |> Stepstone compiler actually does, but by using dataflow analysis to bind |> statically whenever possible, any of the errors that could be caught statically |> in C++ could be caught statically in Objective-C. Objective-C just transfers |> the burden to the compiler, rather than the programmer.) |> |> In other cases, when you are expressing something as a message pass that |> could not be expressed as a member function call in C++ (i.e., using the |> perform: method), you are doing something "less safe" than you would in |> C++. You understand the crux of my concerns, but you fail to address them. It is the fact that there *are* (exist) "less safe" capabilities is what makes dynamic binding objectionable. |> But those cases are easy to identify in the code, and by scaffolding |> them inside of a safety test (low budget assertion testing...), you can |> insure that they will indeed execute safely. This too only skirts the real issue. It is my contention the user of a commercial product should never encounter an "assertion failed at . . ." or "internal error" message. So the product doesn't dump a core file, great, but if this code had been statically bound and checked, the entire situation would never have arisen! |> Basically, I think this whole mess comes down to this: |> Static versus dynamic binding is a matter of personal taste. It is, at that. |> I personally very much prefer to work with a more dynamic language. I think |> that my programs are much more elegant written in a dynamic style, and I |> think that my code written in a dynamic language is much better than my |> code written in a static language. So, when I need to use a C-family language, |> I'll stick with Objective-C. If you like static programming, you'll think |> that I'm out of my gourd, that I'm a fool, or whatever, and you'll stick |> with your static language. I think your priorities are different. One's mental state is rarely indicated by choice of programming language . . . usually. :-) George PS: This line of argument does not contend that C++ applications never encounter run-time errors. If only . . . . :-) ---- George J Wu, Software Engineer | gwu@tcs.com or uunet!tcs!gwu Teknekron Communications Systems, Inc.| (415) 649-3752 2121 Allston Way, Berkeley, CA, 94704 | Quit reading news. Get back to work.
chip@tct.uucp (Chip Salzenberg) (03/16/91)
According to carroll@cis.udel.edu (Mark Carroll): >Most of the time, Objective-C is used in a way which could be trivially >translated into a fully static language like C++. In those cases, Objective-C >COULD catch any of the errors which C++ could catch. The key difference, as I understand it, is that the Objective-C language does not require the programmer to make available to the compiler that information that would make possible a complete check of message vs. object type. >... by using dataflow analysis to bind statically whenever possible, >any of the errors that could be caught statically in C++ could be caught >statically in Objective-C. I think that the above statement is incorrect. The C++ language is incapable of compiling a program that results in an object receiving a message it can't handle. Objective-C, on the other hand, is. Whether a given Objective-C compiler can sometimes, or even usually, notice that error is beside the point. In Objective-C the error is possible; in C++ it isn't. > Static versus dynamic binding is a matter of personal taste. That's an important issue, and one that doesn't get a lot of air time. But it's a significant factor in the early success or failure of any language. >I think that my programs are much more elegant written in a dynamic style ... I am not willing to sacrifice type safety for elegance. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "Most of my code is written by myself. That is why so little gets done." -- Herman "HLLs will never fly" Rubin
chip@tct.uucp (Chip Salzenberg) (03/16/91)
According to cox@stpstn.UUCP (Brad Cox): >I'll have the dynamic binding on my ski boots welded to remove any >possibility of run-time errors. ... A fine example of an analogy run amok. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "Most of my code is written by myself. That is why so little gets done." -- Herman "HLLs will never fly" Rubin
rkitts@netcom.COM (Rick Kitts) (03/20/91)
There seems to be some lack of "real world" in this conversation. The contention that Objective-C allows for errors at run time is obviously correct, however if someone can point out a language which prevents run time errors I would be very interested to know of it :-). Before you say, "But C++ can't get an error because it can't find a method!", please consider that Objective-C can't get an error because it inserted a copy constructor under your nose which has an incorrect behavior. The point being that each language (perhaps *every* language, but I don't want to generalize) has its own domain of problem areas. You can't look at Objective-C and say it is deficient compared to C++ because of this potential for error. Because if you do, you have to turn right around and say that C++ is deficient compared to (just about every other language in the world) Objective-C because it has the potential to generate an incorrect copy constructor. ---Rick
connolly@livy.cs.umass.edu (Christopher Connolly) (03/20/91)
In article <27E17FD1.7241@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >According to carroll@cis.udel.edu (Mark Carroll): >>... by using dataflow analysis to bind statically whenever possible, >>any of the errors that could be caught statically in C++ could be caught >>statically in Objective-C. > >I think that the above statement is incorrect. The C++ language is >incapable of compiling a program that results in an object receiving a >message it can't handle. I don't know much about Objective-C, so I can't say anything about Mark Carroll's statement. On the other hand, the AT&T version 2.1 C++ translator will successfully compile this program: ///////////////////////////////////////////////////////////////////// #include <stream.h> struct junk { int foo; virtual int barf() { cout << "Bandaged Knuckles.\n" << flush; return(foo); } }; struct eat_me { int foo; }; main() { junk* fool_me_once; eat_me* fool_me_twice; void* bar; cout << "Let the festivities begin.\n"; fool_me_once = new junk; fool_me_once->foo = 1; fool_me_once->barf(); fool_me_twice = new eat_me; fool_me_twice->foo = 2; bar = (void*) fool_me_twice; fool_me_once = (junk*) bar; fool_me_once->barf(); } ///////////////////////////////////////////////////////////////////// The resulting executable (a.out) prints this: sunbeam% a.out Let the festivities begin. Bandaged Knuckles. Segmentation fault (core dumped) sunbeam% This is a case where an object is "receiving a message it can't handle", the result being a segmentation fault. Nicht wahr? >I am not willing to sacrifice type safety for elegance. I'd like both, with an order of magnitude to go, please. -C. Connolly
carroll@cis.udel.edu (Mark Carroll) (03/21/91)
In article <27E17FD1.7241@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >According to carroll@cis.udel.edu (Mark Carroll): >>Most of the time, Objective-C is used in a way which could be trivially >>translated into a fully static language like C++. In those cases, Objective-C >>COULD catch any of the errors which C++ could catch. > >The key difference, as I understand it, is that the Objective-C >language does not require the programmer to make available to the >compiler that information that would make possible a complete check of >message vs. object type. > You're not listening to what I said: "Most of the time, Objective-C is used in a way which could be trivially translated... IN THOSE CASES, Obj-C COULD catch any of the errors. If Objective-C is used to do things in the same way in which they would be done in C++, the necessary information to perform error checking is available. It's not explicitly available as in C++ - but a good compiler, by using dataflow, could gather the same information that the C++ compiler has, and could catch any error that the C++ compiler could catch. But note the condition: "If Obj-C is used to do things the same as C++"! >>... by using dataflow analysis to bind statically whenever possible, >>any of the errors that could be caught statically in C++ could be caught >>statically in Objective-C. > >I think that the above statement is incorrect. The C++ language is >incapable of compiling a program that results in an object receiving a >message it can't handle. Objective-C, on the other hand, is. Whether >a given Objective-C compiler can sometimes, or even usually, notice >that error is beside the point. In Objective-C the error is possible; >in C++ it isn't. > The question isn't: is the error possible. Certainly, it's possible to write erroneous code in ANY language. The question is, when is the error going to be caught, and how is it going to be handled? C++ specifies that most errors be caught at compile time. Objective-C doesn't specify when they are caught. Is that a reason to believe that C++ is a "better" language than Objective-C? No. Is that a reason to believe that C++ is a "safer model" that Objective-C? Again, no. Because there is not any safety check possible in the C++ model that could not be performed in the Objective-C model. >> Static versus dynamic binding is a matter of personal taste. > >That's an important issue, and one that doesn't get a lot of air time. >But it's a significant factor in the early success or failure of any >language. > >>I think that my programs are much more elegant written in a dynamic style ... > >I am not willing to sacrifice type safety for elegance. But is that really what's going on? Or are you really just saying that you're willing to sacrifice elegance for compiler simplicity? >Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> <MC> -- ---------------------- Mark Craig Carroll: <MC> ------------------------ ------ U of Del. Grad Student in CIS ------ EE/CIS LabStaff Hacker ------ -- Resident Wierdo @ 105 E Cleveland Ave, Newark DE - carroll@udel.edu -- ---------------------- Shalom Achshav - Peace NOW! ----------------------
chip@tct.uucp (Chip Salzenberg) (03/22/91)
According to connolly@livy.cs.umass.edu (Christopher Ian Connolly): > bar = (void*) fool_me_twice; > fool_me_once = (junk*) bar; Any safety feature can be subverted. Objective-C, as I understand the language, doesn't require the programmer to write a cast (or even its moral equivalent) in order to get an "I can't deal with that" error. If you lie to your compiler, you get what you deserve. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "All this is conjecture of course, since I *only* post in the nude. Nothing comes between me and my t.b. Nothing." -- Bill Coderre
chip@tct.uucp (Chip Salzenberg) (03/22/91)
According to rkitts@netcom.COM (Rick Kitts): >Before you say, "But C++ can't get an error because it can't find a method!", >please consider that Objective-C can't get an error because it inserted >a copy constructor under your nose which has an incorrect behavior. That each language has flaws is not contested by anyone here. To say, "So what if my language has problem X? Yours has problem Y!" is poor form at best, unless problems X and Y are somehow connected. Method lookup and copy constructors have nothing to do with each other. Let's concentrate on the subject at hand, shall we? -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "All this is conjecture of course, since I *only* post in the nude. Nothing comes between me and my t.b. Nothing." -- Bill Coderre
chip@tct.uucp (Chip Salzenberg) (03/23/91)
According to carroll@cis.udel.edu (Mark Carroll): >You're not listening to what I said: "Most of the time, Objective-C is used >in a way which could be trivially translated... IN THOSE CASES, Obj-C COULD >catch any of the errors." Actually, I am listening (or reading, as the case may be). Meanwhile, I think that my basic point has been lost: Objective-C the language does NOT allow the compiler to catch those errors, unless "catch" is defined as: "Output a warning that might well be spurious." To make "no such message" a fatal error would break the language, because the language allows class extension without recompilation of clients. Or am I all wet here? >... a good compiler, by using dataflow, could gather the same information >that the C++ compiler has ... Dataflow analysis of that caliber is impossible. A complete knowledge of all object types would require solving the halting problem. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "All this is conjecture of course, since I *only* post in the nude. Nothing comes between me and my t.b. Nothing." -- Bill Coderre
connolly@livy.cs.umass.edu (Christopher Connolly) (03/23/91)
Chip, could we get a little more consistency in the arguments here? In article <27E17FD1.7241@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >I think that the above statement is incorrect. The C++ language is >incapable of compiling a program that results in an object receiving a >message it can't handle. In article <27E8E12E.2D2A@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >According to connolly@livy.cs.umass.edu (Christopher Ian Connolly): >> bar = (void*) fool_me_twice; >> fool_me_once = (junk*) bar; >Any safety feature can be subverted. All I'm saying is that we should be careful about the claims we make about C++ (or any other language, for that matter). >If you lie to your compiler, you get what you deserve. Clearly. It's likely that many people will "lie" without knowing it, though. >Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> -C. Connolly
chip@tct.uucp (Chip Salzenberg) (03/25/91)
According to connolly@livy.cs.umass.edu (Christopher Ian Connolly): >Chip, could we get a little more consistency in the arguments here? In the interest of brevity, I omitted a qualifier from my first quoted statement. Here is the corrected version: The C++ language is incapable of compiling a program that results in an object receiving a message it can't handle, *unless* the programmer lies to the compiler about the object's type. >It's likely that many people will "lie" without knowing it, though. In my experience, this error is not "likely" at all. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "All this is conjecture of course, since I *only* post in the nude. Nothing comes between me and my t.b. Nothing." -- Bill Coderre
glang@Autodesk.COM (Gary Lang) (04/01/91)
>or am I all wet here?
Sigh. Yes you are. Obj-C supports static AND dynamic typing.
Pretend that you program in C++ using an Object class at the root
of everything and that you virtualize all functions ever defined
in all classes of your application. A ridiculous design scenario
but bear with me.
You could type everything Object, but you probably wouldn't because
you'd lose the benefits of static type checking for those places
where you don't want "board level" interfaces to classes.
The same applies to Obj-C.
God I wish people would at least program in it before they make
statements like this in public.
-g
--
Gary T. Lang (415)332-2344 x2702
Autodesk, Inc.
Sausalito, CA.
MCI: 370-0730chip@tct.com (Chip Salzenberg) (04/02/91)
According to glang@Autodesk.COM (Gary Lang): >>or am I all wet here? > >Sigh. Yes you are. Obj-C supports static AND dynamic typing. [towelling off] Thanks much. >God I wish people would at least program in it before they make >statements like this in public. I've read a lot about Objective-C. Apparently I've missed some developments since the original language definition was published. I know that static typing wasn't in the original version. -- Chip Salzenberg at Teltronics/TCT <chip@tct.com>, <uunet!pdn!tct!chip> "All this is conjecture of course, since I *only* post in the nude. Nothing comes between me and my t.b. Nothing." -- Bill Coderre