From Newsgroup: comp.lang.awk
[ I suggest to use a real newsreader to access Usenet newsgroups;
it helps you also with the quoting of information you refer to
in your posts. - Below I fixed it for you. ]
On 05.04.2022 15:46, Digi wrote:
Bruce Horrocks wrote:
..All these ideas are potential options to be included in a future version >> of GAWK. But GAWK isn't a place for any old extra feature - otherwise it
would be bloated.
i understand and that is exactly what i want, thank you =)
but I think I'm not the only one who offers to contribute some new features in gawk.
I am very interested to hear about this. is it possible to read such discussions?
Features have been discussed here in the past. Some requests (that
had been considered by the maintainers to make sense incorporating
into GNU Awk) have made their way into the code base. As was to
expect, many other requests or suggestions have not made it.
may i offering another ideas?
It may help to read "B.4.1 Defining What Is and What Is Not A Bug"
in the GNU Awk manual, which (amongst the bug related stuff) says:
The following things are not bugs, and should not be reported
to the bug mailing list. You can ask about them on the “help”
mailing list (see section Where To Send Non-bug Questions),
but don’t be surprised if you get an answer of the form
“that’s how gawk behaves and it isn’t going to change.” [...]
Missing features, for any definition of feature. [...]
The number of features that gawk does not have is by definition
infinite. It cannot be all things to all people. In short,
just because gawk doesn’t do what you think it should, it’s
not necessarily a bug.
I suppose you understand that stance (also WRT features).
is it good place for this ?
Basically yes. It's in your interest that the intention is clear,
that it's well described, and not just Yet Another Nice Feature
Depending on the type of the feature there's also the possibility
that you write functionality you desire using the Gawk mechanism
"Extension Library". That way it's decoupled from awk's core code
and quality and usefulness of your library will show whether it
gets used or not. Good coding skills and design experiences are
mandatory to be successful, I'd say.
Apart from that mechanism (and provided that a feature request
makes sense); providing quality code for it likely increases the
chance to get added.
A clear feature concept and clear sample code is also a good
base for a discussion here.
--- Synchronet 3.19c-Linux NewsLink 1.113