From: Sean Russell Date: 2001-10-16T00:24:40+09:00 Subject: [ruby-talk:22570] Re: OSSL opinion Frykholm, Niklas wrote: >>please, avoid the pitfall, common in Java APIs, of obscuring the starting .... > I agree, it is horrible, but in all fairness you probably end up with > something like this if you try to define a completely general crypto > interface that: Yeah, I know... I had to use an explicit factory in REXML. What I really wanted was a way for a base class to return an instance of a subclass; this would have been the ideal solution: x = Source.new(someobject) # -> StringSource, IOSource, ... I'm sure there's an obvious Ruby solution, but I haven't had time to look into it too much. > Java is enterprise-level "programming in the large" taken to its extreme. > All cases are covered: "OK, so you want a checkbox label which mixes > cyrillic, arabic (running in the opposite direction), kanji and braille > with a different font for each character --- we can do that." This > over-generality makes it awkward for simpler projects (and 98 % of the > projects are simpler). And since everything is provided in one big honking > runtime environment instead of in small loadable modules, it is impossible > to escape it. Hm. I don't know if it is *impossible*. Ruby stresses PoLS, but I believe an equally important motto is: "Make the common case easy, and the uncommon case possible." Ruby supports this extremely well, but it is up to the API developers to make sure this happens. The problem with Java is that often the uncommon case is possible, but the common case is not easy, and any deviation from the common case requires you to dive fully into a difficult API that allows you to do the uncommon. A really nice API will provide for a sort of scaled approach, shielding the programmer from the stuff they don't need to worry about. I suppose it is a little late, but I'd like to provide the caveat here that I'm only down on Java in comparison to Ruby. I am a Java developer by trade, and have been doing it professionally since it was pre-1.0 alpha software. I'm a bit soured by having to watch the API grow from something small, easy, and useful to something bloated and with a steep learning curve. I don't know about you folks, but I just *can't* remember all of the Java core API... and I used to be able to. This hasn't all been bad; Swing was, in general, an vast improvement over AWT. Take the SQL API, though. Originally, you could implement a subclass of ResultSet with a little effort. They doubled the number of method calls in 2.0(?), which makes the interface a bit unweildy, IMHO. I just don't want to have to watch that kind of bloat happen to Ruby (or common Ruby libraries), and I like to stress KISS in my own applications. Electric XML (the Java library) is a perfect example. XML APIs got bloated and obtuse with DOM and SAX compliance; I use XML in almost every project, and I've *yet* to see a case where I need, or where my job is made easier rather than harder, by a DOM or SAX compliant toolkit. In fact, I've gone so far as to retrofit most of my applications with Electric XML which has uniformly made my own code more readable. This isn't to say that DOM and SAX aren't a good idea; it is simply my opinion that they over-generalized it. You can't just make a new Element with "new Element()"... you have to use factories for *everything*, which is tedious. > In Ruby we can provide both a simple Blowfish.(rb|so) which is as simple > as > > cipher_text = Blowfish.encrypt(plain_text, key) > > for those who want that and a huge over-generalized CSP, if there ever is > a need for that. The only thing we need to fear are namespace collisions. This is good. --- SER -----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! Check out our new Unlimited Server. No Download or Time Limits! -----== Over 80,000 Newsgroups - 19 Different Servers! ==-----