From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,63a41ccea0fc803a X-Google-Attributes: gid103376,public From: doylep@ecf.toronto.edu Subject: Re: Naming of Tagged Types and Associated Packages Date: 1998/08/10 Message-ID: <6qnbms$ld7$1@nnrp1.dejanews.com>#1/1 X-Deja-AN: 379758625 References: <6qfp80$p0u$1@nnrp1.dejanews.com> Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Mon Aug 10 17:47:09 1998 GMT Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.03 [en] (Win95; I) Date: 1998-08-10T00:00:00+00:00 List-Id: In article , Brian Rogoff wrote: > > Thanks for bringing this back to c.l.a, Patrick. I was loathe to respond > to this in c.l.e., as I remember several language wars starting from > c.l.ada/eiffel crossposting, and I just don't care for them. Yes, that's the same reason I am usually too afraid to venture into c.l.a. :-) > On Fri, 7 Aug 1998 doylep@ecf.toronto.edu wrote: > > > 1. Nothing's stopping you from making yourself use different names for > > everything. > > True, but I can't stop other programmers from doing it Good point. > > 2. It allows you to avoid contrivances by permitting things like this: > > > > class CAR > > > > feature > > steering_wheel : STEERING_WHEEL > > > > end > > > > What else are you going to call the steering wheel? A > > direction_control_device? I think any other name would be contrived. > > Call the steering wheel Steering_Wheel, and call the type something like > Steering_Wheel_Type, or Steering_Wheel_T. Personally, I like type names > and variable names to be lexically distinguished, so the EuLisp/Dylan > convention, which would be to name it something like , > would be my choice if I could do it all myself, but I don't think the > _Type convention is bad at all, and its used widely in my Ada reference > of choice (Ada as a Second Language). The Eiffel convention is to use uppercase for class names and lowercase for feature names. Does this fit the bill? Some compilers won't even accept source code that does not follow this convention, so other programmers not conforming is not an issue. > If you want to talk about having to create contrived names, be careful, > Eiffel doesn't have overloading, which is far worse IMO. Apparently the > Sather designers agreed, when they decided to "fix" Eiffel, they added > overloading. Other languages, like OCaml, do away with most of the need > to name types altogether, so the antiredundantists should consider such > languages before disparaging the Ada way in deference to Eiffel way. Perhaps, but preventing redundancy is still a good thing, so the fact that a language is redundant in one sense doesn't change the fact that eliminating redundancy in another sense is a Good Thing. > pragma Rant(On); > > The truth is I don't think I'll use Eiffel again, because I don't think > its a very good language design. I think OO is overrated, and languages > that try to enforce OO as the *only* programming tool are not for me. I > like Eiffel's assertion mechanisms (though I'm not sure they belong in the > language or would be better left as a tool) but I think its type system is > hopelessly broken, it *requires* whole-program analysis due to covariance; > bye-bye separate compilation! Fair enough. I don't like covariance either. But as for whole-program analysis... First, this is not necessary if you're satisfied with some type checking being done at runtime. So the accurate assessment would be that whole-program analysis is required for static type safety, rather than to make Eiffel usable at all. Second, SmallEiffel is a compiler which has dived whole-heartedly into a system-wide approach, and as such is able to make *massive* optimisations which produce excellent executables. Since the compiler is compiled by itself, it makes use of these optimisations to provide system-wide compilation which is of comparable speed to module-wise compilation systems. In fact, because SmallEiffel compiles to C, it is possible to compare the system-wide approach to the module-wise approach directly, and the Eiffel-to-C phase of compilation is invariably faster than the C-to-native phase, often by an order of magnitude, despite the fact that the C-to-native phase only compiles the portions that have changed. It is dangerous to draw too many conclusions from this, but one thing that is clear is that the system-wide approach does not have a significant impact on compile time. > Obviously, people are free to have different opinions, and I wouldn't want > to start another Eiffel/Ada flamefest, so I generally avoid posting my > opinion on the Eiffel ng. That's probably the safest thing to do. :-) -PD -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum