atherton@unixg.ubc.ca (Bruce Atherton) (04/13/91)
I have only one reason to want both the . and the -> overloaded: To allow for virtual memory so I can get around the revolting 640K limitations imposed by MSDOS. If I write a bunch of classes for distribution, I don't want to insist that anyone who uses my classes has to use pointers. I don't want to force them to have to use "(&struct)->member" either. Another option would be to have every function that uses or calls the member do its check to make sure it is in memory. Yecch! I know you can't design a language around the problems of one operating system, but don't you think if it is useful in this context, it could be useful elsewhere? I haven't paid much attention to this whole discussion concerning the . operator (or whatever you want to call it) because people are becoming so emotional about it, IMHO. I know that I don't absolutely have to have both . and -> overloadable. It sure would make my life a lot easier and my classes more useable, though. If . doesn't become overloadable, things will be more difficult for me but I'll live. What will happen to you if it does become overloadable? Anything negative at all? I doubt it. -- UBC Faculty of Law Artificial Intelligence Research (FLAIR) Project atherton@unixg.ubc.ca or | I can almost taste your dandruff as I reach Bruce_Atherton@mindlink.UUCP | out for your face, and I STRIKE! - The DKs