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.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ac39a12d5faf5b14 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-04-25 18:16:11 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!paloalto-snf1.gtei.net!crtntx1-snh1.gtei.net!nycmny1-snf1.gtei.net!news.gtei.net!easynet-tele!easynet-melon!easynet.net!psiuk-p2!psiuk-p3!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: Grace and Maps (was Re: Development process in the Ada community) Date: Thu, 25 Apr 2002 09:35:30 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: References: <3CB46975.90408@snafu.de> <4519e058.0204180800.44fac012@posting.google.com> <3CBF0341.8020406@mail.com> <4519e058.0204190529.559a47ae@posting.google.com> <3CC1C6B3.6060306@telepath.com> <3CC21747.5000501@telepath.com> <3CC59ED2.1000803@home.com> <3CC5B286.6FE61551@san.rr.com> <3CC5B9EE.32F3060@san.rr.com> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1019741732 20025 136.170.200.133 (25 Apr 2002 13:35:32 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 25 Apr 2002 13:35:32 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:23125 Date: 2002-04-25T13:35:32+00:00 List-Id: What I imagine is that a Map package spec can be designed that basically allows for insertion, deletion & update of individual elements and contains some kind of abstraction to walk through the elements of the map and some means of making the data persistent. I imagine that the Version-1.0 implementation will be something that supports reasonable access time for average use. There can be 1024 different implementations behind it that satisfy any particular implementor's desires if some vendor or some user wants to do something totally different for whatever reasons. The Mark 1, Mod 0 Grace implementation just needs to be *an* implementation that works reasonably well. The danger is that this discussion is going to drift off expounding endlessly on the relative merits of hash tables versus b-trees versus who-knows-what. The mission was to come up with a specification that would present the developer with something consistent with the spec for Grace.Lists, yet provided the operations that would be needed & expected for a map. It doesn't need to be perfect. It doesn't need to be optimal for all uses. It doesn't need to be the final word on indexed data structures. It needs to *exist* and be acceptable to a reasonably large majority of Ada users. After that, it can be polished and polished and polished until it shines like the sun. After that, any number of variations on a theme can be composed to satisfy whatever different criteria someone may have. That's the beauty of being able to create child packages or utilize inheritance - we can create those variations easily. Maybe this is an ongoing problem we Ada programmers have - we so much want to find the perfect solutions that we tend to forget some important practical concerns. Lots of competing languages *already* have libraries full of stuff - including Maps. Those competing languages don't present every possible implementation or even an optimal implementation. What they present is something that an implementor will find useful *today* to get their job done. If all Ada can promise is "One day, its going to be really, really great!!!" developers are going to continue to choose C++, Java, etc., where the promise is: "Here's the leverage you need to get an app built fast right now..." Sorry. I'm not intending to criticize anyone in particular. Its one of those "We're all guilty..." kind of situations. My concern is that if this language wants to have a bigger, better, brighter future, it needs to provide things that are bigger, better and brighter than what other languages already offer. It cannot continue to lag behind what developers can get elsewhere and expect to attract new adherents. In that sense, we've got a lot of catching up to do and that will require staying focused on what's important to moving the mission forward. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Georg Bauhaus" wrote in message news:aa8ssi$qjr$1@a1-hrz.uni-duisburg.de... > > Wouldn't you want, in a language like Ada, the programmer to be > able to choose an appropriate specific map implementation and > use that for the real thing behind a declared map, and _then_ > FORGET about it most of the time. No need to think about the > general solution, because you will still be writing programs AS IF > there is a general solution, namely by using an interface, > the Map interface. And if there _is_ a standardised Map > interface, implementors, producers, vendors can glue their > specific implemention(s) to that interface, and you as a > programmer will still be writing essentially portable code, > since only the few lines where a specific container that offers > the Map interface is chosen. >