From: Stachu 'Dozzie' K. on
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
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
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
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
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,