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.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.182.76.65 with SMTP id i1mr22609670obw.5.1401895501333; Wed, 04 Jun 2014 08:25:01 -0700 (PDT) X-Received: by 10.182.236.73 with SMTP id us9mr100475obc.19.1401895501121; Wed, 04 Jun 2014 08:25:01 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!c1no23035170igq.0!news-out.google.com!gi6ni19621igc.0!nntp.google.com!h18no315215igc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 4 Jun 2014 08:25:00 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=71.252.147.203; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 71.252.147.203 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <3bf7907b-2265-4314-a693-74792df531d1@googlegroups.com> Subject: Re: a new language, designed for safety ! From: "Dan'l Miller" Injection-Date: Wed, 04 Jun 2014 15:25:01 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:20132 Date: 2014-06-04T08:25:00-07:00 List-Id: On Monday, June 2, 2014 8:37:12 PM UTC-5, Nasser M. Abbasi wrote: > Fyi, for those who like safe languages, watch out Ada and >=20 > Spark, Apple introduced new "safe" language today, meant > to replace objective-C: >=20 > "In addition, Apple notes how the language was designed for > safety, with variables that have to be initialized before > use , arrays and integers that are checked for > overflow and automatic memory management." One major category of Objective-C unsafety that Swift apparently does absol= utely nothing to prevent (until fatal error at runtime, hence the unsafety)= is whether an object actually provides a method for a given selector or wh= ether an object actually provides a forwarding to another object for a give= n selector or is handled by a per-class or per-object-instance error handle= r or none of the above, which precipitates the fatal error at runtime. Except when an iPhone or iPad or iPod or MacOSX app presents to the human u= ser a roulette wheel of all object instances or of all class names to choos= e an object instance or class to extend dynamically at runtime, the program= mer certainly knows at source-code-editing time which categories of object = instances or which class name is to have additional methods or forwardings= for a given selector--and hence when to create some overtly-declared-at-co= mpile-time categorization (e.g., subclass) of a class or of a categorizatio= n of object-instance. Hence, the vast vast vast majority of so-called dyna= mic extension of an object instance or of a class is actually an engineerin= g-time decision (i.e., prior to compile-time). Therefore, Objective-C and = Swift both provide no compile-time-assured mechanism to 100% assure that a = given class (or a given object instance) will able to successfully invoke a= method or forwarding when "sent" a "message" for a given selector. This i= s not surprising for the 1980s-vintage Objective-C, back when Smalltalk was= often held up as the ultimate state-of-the-art in OO; Smalltalk had much t= he same fundamental unsafety, due in turn much the same selector mechanisms= as Objective-C. But almost 3 decades later, Swift has the same fundamenta= l unsafety at its core and throughout all nontrivial source code, when foll= owing Apple's advice regarding when so-called dynamic extension of a class = or of a object-instance is to be utilized. Or in short, Swift's so-called safety is much more like swiss cheese (Swift= cheese?) than Ada's higher expectations of what constitutes safety.