Prev: Parsing GC Log File
Next: Is it possible to automatically download new software when it's released?
From: bsh on 16 Nov 2009 16:31 Dominic Fandrey <kamik...(a)bsdforen.de> wrote: > ... > Shell scripting often is a purpose of its own. It's really more of an > art form than real programming, yet ridiculously real programs still are > the result. Consider me a wannabe artist who is bad at handling critics. > ... (How is it that your English is so fluent and idiomatic?) Hmmm, interesting. Despite allusions to the code by previous respondents, I had to find it with a Web search to review it. It haven't been able to run it (no shell prompt in front on me these days) but have been personally interested in doing such a thing recently, as a author of an (unreleased) k/sh IDE. I see that Christopher A. Jones'es book "UNIX Shell Objects" has now been introduced, and I need to add nothing about it here, except that it is pdksh, not ksh of any version, in which the scripts are written in -- and it does make a bit of difference, insofar as there are semantic nuances of pdksh which are significant. I would be interested in what you have to saw about your "bsda_obj.sh" in regards to the below list of prior attempts to add an OOP paradigm to k/sh. It is a (mostly) comprehensive list. "<Unix Shell Objects.sh> -- OOP extension to ksh(1) and applications from BOOK: Christopher A. Jones. "UNIX Shell Objects: Developing Multilayered, Distributed, Object-Oriented Applications Using the Korn Shell". ISBN 0-7465-7004-8. "shoop.sh": http://shoop.sf.net http://cvs.sf.net/viewcvs.py/shoop/shoop/ http://telia.dl.sf.net/mirrors/debian/pool/main/s/ "shoop.sh" -- classless object orientation (introspection, finalization, serialization, multiple inheritance) to plain sh(1) same as above?? http://sf.net/projects/shoop/ TRACT: Jeffrey S. Haemer. "A new object-oriented programming language: sh". Proceedings of the USENIX Summer 1994 Technical Conference on USENIX. Summer 1994. Technical Conference, p.1-1, 1994-06-06P06-10, Boston. ^ http://portal.acm.org/citation.cfm?id=1267258&dl=GUIDE&coll=GUIDE&CFID=35669572&CFTOKEN=78909355 ^ QT: Introduces a tiny, object-oriented programming system written entirely in POSIX-conforming shell scripts. "bash++.c" http://sf.net/projects/bashpp/ "Idee Sparse Per Shell Object-Oriented" news:it.comp.os.dibattiti http://risitano.altervista.org http://twiki.dsi.uniroma1.it/twiki/view/Users/NicolRisitano/ "ksh93 OOP using discipline functions" https://mailman.research.att.com/pipermail/ast-developers/2004q3/000079.html https://tugll.tugraz.at/ruedigers/weblog/ "woosh.bash" (NCA?) http://themes.freshmeat.net/projects/woosh/ http://wosx30.eco-station.uni-wuerzburg.de/~martin/download/woosh-0.2.tgz And here are two of my past contributions to C.U.S. that are pertainent: "OO methodology implemented through file system": http://groups.google.com/g/d597fefe/t/ae57ec19ac3b92fb/d/c95776ae4f35d07c "Organization of shell code function library": http://groups.google.com/g/d597fefe/t/fe4bdf10638d6390/d/35510153455b1e3e > I am working on a rather complex application and the cleaner > data structures safe enough computation time to outweigh the > considerable overhead caused by the framework. Because your application is non-trivial, I would myself think to implement it with the robust, if under-documented, O-O capability now built into ksh93t and later. Perhaps you think that to write in sh(1) has the advantage of portability? It used to be so, but now that ksh93(1) is open- source and freely downloadable, and the fact the Bourne shell development lineage has become so "forked" with POSIX compliance and back-implemented, host-specific features, its now impossible to reliably assume a given feature set used in sophisticated scripting. Good luck. Please let C.U.S. know of revisions and comments -- I can say that I understand the general arguments of some previous responents, but I hope that this will not dissuade you from posting any such followups. Good luck! =Brian
From: Janis Papanagnou on 16 Nov 2009 19:35 Dominic Fandrey wrote: > Janis Papanagnou wrote: >> Dominic Fandrey wrote: [...] >>> Inheritance can be VERY useful, but often is not required at all. >> Well, YMMV, but OO just *starts* with inheritance; one of the few basic >> OO features is polymorphism, and inheritance is a precondition for that. > > No it isn't. It only is a precondition if there is type safety. You're again wrong with your claim. Thanks for your time and goodbye. > [...]
From: Janis Papanagnou on 16 Nov 2009 19:42 bsh wrote: > [...] Thanks for the links. > "ksh93 OOP using discipline functions" > https://mailman.research.att.com/pipermail/ast-developers/2004q3/000079.html > https://tugll.tugraz.at/ruedigers/weblog/ The latter link seems either broken or wrong. Any more information about it? Janis > [...]
From: Dominic Fandrey on 17 Nov 2009 06:49 bsh wrote: > Dominic Fandrey <kamik...(a)bsdforen.de> wrote: >> ... >> Shell scripting often is a purpose of its own. It's really more of an >> art form than real programming, yet ridiculously real programs still are >> the result. Consider me a wannabe artist who is bad at handling critics. >> ... > > (How is it that your English is so fluent and idiomatic?) I have no idea what idiomatic means. The explanations I found do not really enlighten me. I glimpse that it might mean that the meaning of my words is clouded. If so I apologize, I am not a native speaker as you no doubt have recognized. In deed, apart from 20 days in Great Britain more than five years ago, I have not been to a country where English or one of its derivatives is the native tongue. > > Hmmm, interesting. Despite allusions to the code by previous > respondents, I had to find it with a Web search to review it. I really should post an updated version somewhere, one that comes with inheritance and serialization. After some fixing up of the documentation I will. > ... > > I would be interested in what you have to saw about your > "bsda_obj.sh" in regards to the below list of prior attempts > to add an OOP paradigm to k/sh. It is a (mostly) comprehensive > list. > ... Pursuing this will take me some time. Maybe as much as two or three weeks. Your list and questions are very appreciated. Be assured, I will not forget to respond when I am ready. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
From: Seebs on 17 Nov 2009 10:49
On 2009-11-17, Dominic Fandrey <kamikaze(a)bsdforen.de> wrote: > I have no idea what idiomatic means. The explanations I found > do not really enlighten me. "Idioms" are patterns of usage which aren't directly derived from the grammar or semantics of individual words. "Idiomatic" writing in any language (even a computer language) is language which conforms to the idioms. > I glimpse that it might mean that > the meaning of my words is clouded. If so I apologize, I am > not a native speaker as you no doubt have recognized. No, it actually means the opposite. Note that "idiomatic" applies to shell, as well. For instance, if I'm modifying IFS, I pretty much always write: save_IFS=$IFS IFS=: (do something using new IFS) IFS=$save_IFS Since I write it the same way every time, anyone reading my scripts knows what I'm doing and how. For instance, consider the occasional portability problem you might encounter writing: if [ "$x" = none ]; then There have been variants of test where some values of $x could cause the test parser to get confused by the expresison. Furthermore, the lack of quotes around "none", while irelevant, can make it harder to see the parallel. Many people use the convention of adding an initial value. Thus, you might see: if [ X"$x" = X"none" ]; then This makes it reasonably easy for the reader to see the difference. Now, imagine that you saw this: if [ $(echo x)"$x" = $(echo X | tr A-Z a-z)'n''o''n''e' ]; then A bit of examination reveals that they're equivalent, I think -- but it's a lot harder to tell. The first usage is considered "idiomatic" -- it is the solution to that particular problem that users are most likely to be familiar with. There are some cases where an idiom is unclear. Consider: x=$(eval echo foo_$y) eval x=\$foo_$y The former is a pretty widely-used idiom, but the latter is actually noticably superior in terms of how it handles special characters, etcetera. -s -- Copyright 2009, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! |