object oriented shell scripts
in [Shell]
|
Prev: Parsing GC Log File
Next: Is it possible to automatically download new software when it's released?
From: Stachu 'Dozzie' K. on 11 Nov 2009 16:23 On 11.11.2009, Dominic Fandrey wrote: [...] > I am here to discuss shell scripting. I created something crazy yet still > useful, because I wanted to, because I can and because I need it. > > Why do you keep insisting that I shouldn't have done it? Do you grudge > me the joy of achieving what few have achieved before me? OK, great job, good work, the king rules and so on. But what is it for? You know, I tend to use the appropriate tool for the job. I drop the shell if the job requires more sophisticated text processing. I drop scripting languages when I need fast computation or something from deep system (SUID binaries, PAM libraries or something). If your system needs OOP, then just drop the shell and go get some language supporting that paradigm. That's simply clearer and easier approach (both for you and people using your work). -- Stanislaw Klekot
From: Janis Papanagnou on 11 Nov 2009 17:33 Dominic Fandrey wrote: > Janis Papanagnou wrote: >> Dominic Fandrey wrote: >>> I have written a framework for object oriented shell scripting. >>> It doesn't provide type safety or inheritance or access control, >>> but it has classes, objects and some other nice features like >>> automatic creation of getters and setters or return by reference. >> I think the getter and setter is the most unimportant feature in an >> object based approach. And all the Real OO Features are missing? > > To me inheritance and access control are only useful tools, not > necessary for the concept to work. Especially access control is > not required at all, it can completely be substituted with discipline. (Even all Object Oriented or Object Based programming concepts can be substituted with discipline in programming; not a convincing argument, BTW.) > 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. (Ed suggested to use another term to be clear about your framework's range and intention.) I sort of agree with you statement about access control to a certain degree. > Though it's not supported by my little framework, you can at least > reuse methods from other classes simply by creating an alias or > directly calling them as a static function. In that case, they > won't get their own stack layer, though and everything they return > by reference will not be returned to you, but to whomever called > your method. > >> BTW, you may want to have a look into a newer ksh93 and its typeset >> builtin command with its options... > > Those really sound like interesting options. ksh is not part of > the FreeBSD base system, can you name a system where it is? The situation is not that simple - well, maybe it is. Ksh is part of most (every?) commercial Unix that was shipped the last 20+ years, and there's a PD ksh on Linux systems. Bad news is that those are mostly ksh88 based versions, and the above quoted features are from newer ksh93. Good news is that ksh93 is available (source and binary for many platforms) from kornshell.com. > Do you > think it's possible to port Bourne Shell code or even write code > that works on both shells? Yes and no, depending on how your question is interpreted. Ksh is (as far as possible) an extension of Bourne shell (as is bash, for example), so quite all bourne shell programs should also work on ksh (or bash). Ksh also conforms to the POSIX standard. But, of course, backwards is not guaranteed; you cannot run a ksh program using e.g. the discipline function feature on a Bourne shell; Bourne shell is a more primitive predecessor. > Or do those features make my framework entirely obsolete for > this shell? Well, I suppose so, but from the interface usage example you posted I cannot tell for sure, to be honest. One additional question resp. remark to your posted code; you are using the 'local' keyword, could it be that the freeBSD sh is actually a bash? You might get portability problems if you run your programs on a real sh in this case. Or is 'local' a keyword introduced and supported by your framework? Janis
From: stan on 12 Nov 2009 18:27 Dominic Fandrey wrote: <snip> > The proper way of showing me your disinterest is leaving me alone. I see you're new to usenet. Welcome.
From: Charles Polisher on 13 Nov 2009 12:37 On 2009-11-11, Janis Papanagnou <janis_papanagnou(a)hotmail.com> wrote: > Dominic Fandrey wrote: >> Janis Papanagnou wrote: >>> Dominic Fandrey wrote: >>>> I have written a framework for object oriented shell scripting. >>>> It doesn't provide type safety or inheritance or access control, >>>> but it has classes, objects and some other nice features like >>>> automatic creation of getters and setters or return by reference. >>> I think the getter and setter is the most unimportant feature in an >>> object based approach. And all the Real OO Features are missing? <snip> Cf. "UNIX Shell Objects", Christopher A. Jones, ISBN 0-7465-7004-8 subtitled "Developing Multilayered, Distributed, Object-Oriented Applications Using the Korn Shell". Best of luck, -- Charles Polisher
From: Janis Papanagnou on 13 Nov 2009 13:04
Charles Polisher wrote: > On 2009-11-11, Janis Papanagnou <janis_papanagnou(a)hotmail.com> wrote: >> Dominic Fandrey wrote: >>> Janis Papanagnou wrote: >>>> Dominic Fandrey wrote: >>>>> I have written a framework for object oriented shell scripting. >>>>> It doesn't provide type safety or inheritance or access control, >>>>> but it has classes, objects and some other nice features like >>>>> automatic creation of getters and setters or return by reference. >>>> I think the getter and setter is the most unimportant feature in an >>>> object based approach. And all the Real OO Features are missing? > <snip> > > Cf. "UNIX Shell Objects", Christopher A. Jones, ISBN 0-7465-7004-8 > subtitled "Developing Multilayered, Distributed, Object-Oriented > Applications Using the Korn Shell". And what exactly will we find in this book? (Descriptions of the new typeset -T features? Emulating OO by disciplined programming? A more elaborated framework to support OO better than in an object based approach?) Being a bit more verbose would help. Thanks. > > Best of luck, |