From: Nat Pryce Date: 2001-10-16T00:41:04+09:00 Subject: [ruby-talk:22572] Re: OSSL opinion In Ruby, a class *is* a factory, because it is an object. As long as you define a common protocol that is implemented by all classes to create new objects, you can parameterise objects by references to the class that they should use to create new objects. In this way the class (aka factory) is being used as a strategy of the object. Cheers, Nat. ----- Original Message ----- From: "Sean Russell" Newsgroups: comp.lang.ruby To: "ruby-talk ML" ; Sent: Monday, October 15, 2001 4:24 PM 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! ==----- >