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=-0.3 required=5.0 tests=BAYES_00,LOTS_OF_MONEY, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6f69b1cf0f02b9ac X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-01-20 17:28:58 PST Path: supernews.google.com!sn-xit-02!sn-xit-01!supernews.com!newsfeed.stanford.edu!headwall.stanford.edu!feeder.via.net!newshub2.rdc1.sfba.home.com!news.home.com!news1.sttls1.wa.home.com.POSTED!not-for-mail Reply-To: "DuckE" From: "DuckE" Newsgroups: comp.lang.ada References: <93ti8b$bjpps$1@ID-25716.news.dfncis.de> <9BP86.270637$U46.8654942@news1.sttls1.wa.home.com> <94563n$cb6kp$1@ID-25716.news.dfncis.de> <0Cka6.290338$U46.9207275@news1.sttls1.wa.home.com> <94co6t$v27$1@nnrp1.deja.com> Subject: Re: How can I avoid Using a Semaphore? X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: Date: Sun, 21 Jan 2001 01:28:57 GMT NNTP-Posting-Host: 24.6.221.63 X-Complaints-To: abuse@home.net X-Trace: news1.sttls1.wa.home.com 980040537 24.6.221.63 (Sat, 20 Jan 2001 17:28:57 PST) NNTP-Posting-Date: Sat, 20 Jan 2001 17:28:57 PST Organization: Excite@Home - The Leader in Broadband http://home.com/faster Xref: supernews.google.com comp.lang.ada:4250 Date: 2001-01-21T01:28:57+00:00 List-Id: "Robert Dewar" wrote in message news:94co6t$v27$1@nnrp1.deja.com... > In article <0Cka6.290338$U46.9207275@news1.sttls1.wa.home.com>, > "DuckE" wrote: > > In my opinion this is one of the weak points of Ada 95. It > > would have been better to not have the 'input and 'output > > pre-defined for built in types (as a part of the language) > > but to include a package for defining these > > attributes. That way an arbitrary representation of built in > > types could be used with streams when desired. > > > I don't see your point here. Surely you are not arguing in > favor of REQUIRING people to define their own stream attributes > for types, that would be a huge pain for the most common use > of stream attributes. No I'm not in favor of requiring people to define their own stream attributes. > > There are two possibilities > > 1. You want to control stream behavior on a type by type basis. > This you can do perfectly fine, by just avoiding built in types > like Integer, which is good practice anyway, and then define > the stream attributes to work however you want. > > 2. You want to control stream attributes globally (as is > permitted in GNAT by replacing the System.Stream_Attributes > unit), but you seem to say in the same message that you do NOT > like the fact that in GNAT this approach results in the default > routines applying to everything. > I believe there's a third: 3. You want to control stream behavior on a type by type basis for all types including built in types. You also include a package containing streaming definitions for built in types that may be included using a WITH statement. This behavior would be more consistent with operation of functions like "sin" and "cos" that are not pre-defined, but included in a standard package. > It really seems like Ada 95 does EXACTLY the right think in the > terms you have layed out here, you will have to be a lot > clearer in making your acase that something is missing. Perhaps > you can give at least a sketch of what you would like to see. > Perhaps I would like to see something like: package Ada.Streams.Built_In_Types is -- -- Define 'Input, 'Output for built in types -- end Ada.Streams.Built_In_Types; And then in my code I have the control to create: package Steves_Streaming_For_Built_In_Types is -- -- Define 'Input, 'Output for built in types -- end Steves_Streaming_For_Built_In_Types; > From where I sit, it seems like your problem is reasonable, > and easily addressed with the current language features, and > i can't see any addition to these features which would be > helpful in this particular case. > For me it's easier to just stay away from streaming. For one thing, the behavior is implementation dependent. For another, I have been quite effective at getting things done without it. > > Sent via Deja.com > http://www.deja.com/