#664 A noop ::end directive

[Ruurd Idenburg]

For code editors that have fold/unfold capabilities for structured blocks, like the one I use: Notepad++, it would be nice for rexx code developers to allow a directive to end a method, routine or class etc. to improve readability and overview. The directive would have no functional property at all and would have the restriction that it has to be followed by another directive or the end of the file just like other directives.

The attached patch files do the job (I think). Tested with a windows build and invalidly placed ::end directives as well as well placed ::end directives

[Rick McGuire]

Not what I'd consider an acceptable patch. There's no syntax checking of the directive (e.g., for extra stuff) nor any checking that this appears in a context where it is acceptable.

[Ruurd Idenburg]

Ok, thanks for the reaction Rick, I'll see if I can improve on it.
What do you think of the idea tho?

[Rick McGuire]

Only so-so on it. I think you need to flesh out the definition of where the directive is allowed first before proceeding with the code. I don't really think it is needed, but if done, it needs to be done properly. For example, for matching purposes, it should probably allow a matching name to be included.

[Erich]

Ruurd, can you make your build public, so we can test too?

::END is already used to end a (new in 5.0) ::resource directive, so both usages for ::END should still work, e.g.

 ::resource "brown fox"
 The quick brown fox jumps over the lazy dog
 ::END

[Rick McGuire]

Oh, I forgot about ::END for the ::resource directive. That complicates things because that one needs to operate by a different set of syntax rules (e.g. case sensitive and no real syntax checking. It is not really a directive, just a marker string.

[LesK]

But Ruurd's suggestion was exactly that: A 'marker' directive that was effectively just a noop. Seems to me that what's already in 5.0 is missing what you suggested that Ruurd add to his patch, or am I missing something?

[Anonymous]

Frankly Les, you're missing everything. I don't find a NOOP directive just for the effect of making an editor working correctly to be a desirable addition to the language. This, if added, needs to be done as a real part of the syntax with real error checking. But I'm no longer involved with ooRexx, so I'm no longer the decision maker here.

[Jon Wolfers]

Hi All,

It is desirable for ooRexx to interact with editors and hopefully
eventually IDE's, and meta-data is often included in programs for the
purpose of facilitating this.

However, it is common to provide this meta-data in comment lines. These
are optional and passive to the interpreter, as would the proposed ::end
directive be.

Therefore, it seems to me that in the long-run it would be desirable to
have some conventions for providing meta-data that would allow editors
and/or ides to 'understand' the code.

I'm not familiar with notepad++, but it seems that it might be more
desirable to supply such meta-data comments at the start and end of
routines etc.. to allow for the folding. If there was a standardisation to
these customs, it would be better in the long run in my opinion if they
were based on standards that eclipse or visual-studio could understand (or
both).

In the short term I wonder if that doesn't render Ruurd's feature an
interesting exercise, but not a desirable addition to the language.

thoughts?

Jon

On 21 April 2015 at 22:44, noreply@in.sf.net wrote:

Frankly Les, you're missing everything. I don't find a NOOP directive just
for the effect of making an editor working correctly to be a desirable
addition to the language. This, if added, needs to be done as a real part
of the syntax with real error checking. But I'm no longer involved with
ooRexx, so I'm no longer the decision maker here.

---

• [feature-requests:#664]
  http://sourceforge.net/p/oorexx/feature-requests/664 A noop ::end
  directive*

Status: unread
Milestone: 5.0.0
Created: Tue Apr 21, 2015 11:45 AM UTC by Ruurd Idenburg
Last Updated: Tue Apr 21, 2015 09:40 PM UTC
Owner: nobody

For code editors that have fold/unfold capabilities for structured blocks,
like the one I use: Notepad++, it would be nice for rexx code developers to
allow a directive to end a method, routine or class etc. to improve
readability and overview. The directive would have no functional property
at all and would have the restriction that it has to be followed by another
directive or the end of the file just like other directives.

The attached patch files do the job (I think). Tested with a windows build
and invalidly placed ::end directives as well as well placed ::end
directives

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/oorexx/feature-requests/664/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[Rick McGuire]

Well, you certainly can easily replace ::END with --END and get the same
result without needing to enhance the language.

Rick

On Wed, Apr 22, 2015 at 8:55 AM, Jon Wolfers sahananda@users.sf.net wrote:

Hi All,

It is desirable for ooRexx to interact with editors and hopefully
eventually IDE's, and meta-data is often included in programs for the
purpose of facilitating this.

However, it is common to provide this meta-data in comment lines. These
are optional and passive to the interpreter, as would the proposed ::end
directive be.

Therefore, it seems to me that in the long-run it would be desirable to
have some conventions for providing meta-data that would allow editors
and/or ides to 'understand' the code.

I'm not familiar with notepad++, but it seems that it might be more
desirable to supply such meta-data comments at the start and end of
routines etc.. to allow for the folding. If there was a standardisation to
these customs, it would be better in the long run in my opinion if they
were based on standards that eclipse or visual-studio could understand (or
both).

In the short term I wonder if that doesn't render Ruurd's feature an
interesting exercise, but not a desirable addition to the language.

thoughts?

Jon

On 21 April 2015 at 22:44, noreply@in.sf.net wrote:

Frankly Les, you're missing everything. I don't find a NOOP directive
just
for the effect of making an editor working correctly to be a desirable
addition to the language. This, if added, needs to be done as a real part
of the syntax with real error checking. But I'm no longer involved with
ooRexx, so I'm no longer the decision maker here.

---

• [feature-requests:#664]
  http://sourceforge.net/p/oorexx/feature-requests/664 A noop ::end
  directive*

Status: unread
Milestone: 5.0.0
Created: Tue Apr 21, 2015 11:45 AM UTC by Ruurd Idenburg
Last Updated: Tue Apr 21, 2015 09:40 PM UTC
Owner: nobody

For code editors that have fold/unfold capabilities for structured
blocks,
like the one I use: Notepad++, it would be nice for rexx code developers
to
allow a directive to end a method, routine or class etc. to improve
readability and overview. The directive would have no functional property
at all and would have the restriction that it has to be followed by
another
directive or the end of the file just like other directives.

The attached patch files do the job (I think). Tested with a windows
build
and invalidly placed ::end directives as well as well placed ::end
directives

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/oorexx/feature-requests/664/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

---

[feature-requests:#664] A noop ::end directive

Status: unread
Milestone: 5.0.0
Created: Tue Apr 21, 2015 11:45 AM UTC by Ruurd Idenburg
Last Updated: Tue Apr 21, 2015 09:44 PM UTC
Owner: nobody

For code editors that have fold/unfold capabilities for structured blocks,
like the one I use: Notepad++, it would be nice for rexx code developers to
allow a directive to end a method, routine or class etc. to improve
readability and overview. The directive would have no functional property
at all and would have the restriction that it has to be followed by another
directive or the end of the file just like other directives.

The attached patch files do the job (I think). Tested with a windows build
and invalidly placed ::end directives as well as well placed ::end
directives

---

Sent from sourceforge.net because you indicated interest in <
https://sourceforge.net/p/oorexx/feature-requests/664/>

To unsubscribe from further messages, please visit <
https://sourceforge.net/auth/subscriptions/>

[Ruurd Idenburg]

Had some other things to do.

@erich, the patch is/are public itthey is/are attached, you should apply them to the main/trunk/etc

@rick, no longer involved or no longer the decision maker, doesn't imply I'm no longer interested in your opinion. 8-) And it's certainly not something I would start a rjiRexx fork for, see below. And maybe you should stay on as THE DECISIONMAKER and nothing more?

@jon, It is meant as an exercise to see if I am confident to find my way in existing C++ code ( I know that I'm not equipped to start from scratch, except for some basic stuff)

@all, I've made some changes:

Alternative 1. ::end may optionally be followed by a symbol or literal to allow for optical matching, but no requirement on the value of the symbol/literal.

Alternative 2. ::end may optionally be followed by a symbol/literal and the value should be the classname/methodname

In my tests there is no conflict with the ::RESOURCE default ::END marker.

Patch(es) in a coming episode.

Further step would be to limit ::END to directives that (may) have body text,i.e. code.

How would one distinguish --END metadata from a comment? Just curious

[Rick McGuire]

On Wed, Apr 22, 2015 at 12:35 PM, Ruurd Idenburg idenburg@users.sf.net
wrote:

Had some other things to do.

@erich, the patch is/are public itthey is/are attached, you should apply
them to the main/trunk/etc

@rick, no longer involved or no longer the decision maker, doesn't imply
I'm no longer interested in your opinion. 8-) And it's certainly not
something I would start a rjiRexx fork for, see below. And maybe you should
stay on as THE DECISIONMAKER and nothing more?

@jon, It is meant as an exercise to see if I am confident to find my way
in existing C++ code ( I know that I'm not equipped to start from scratch,
except for some basic stuff)

@all, I've made some changes:

Alternative 1. ::end may optionally be followed by a symbol or literal to
allow for optical matching, but no requirement on the value of the
symbol/literal.

I would not find that acceptable. It should match just like one on an END
instruction.

Alternative 2. ::end may optionally be followed by a symbol/literal and
the value should be the classname/methodname

or routine name.

In my tests there is no conflict with the ::RESOURCE default ::END marker.

Patch(es) in a coming episode.

Further step would be to limit ::END to directives that (may) have body
text,i.e. code.

I'd say that would be an absolute requirement for inclusion. The
processing of this directive (except for class closure ones) should be in
the code that handles method/routine bodies rather than processed in the
directive section.

How would one distinguish --END metadata from a comment? Just curious

You wouldn't, It is a comment, that's the point. If just happens to be a
special comment that an editor could recognize as metadata, which was Jon's
point.

---

[feature-requests:#664] A noop ::end directive

Status: unread
Milestone: 5.0.0
Created: Tue Apr 21, 2015 11:45 AM UTC by Ruurd Idenburg
Last Updated: Tue Apr 21, 2015 09:44 PM UTC
Owner: nobody

For code editors that have fold/unfold capabilities for structured blocks,
like the one I use: Notepad++, it would be nice for rexx code developers to
allow a directive to end a method, routine or class etc. to improve
readability and overview. The directive would have no functional property
at all and would have the restriction that it has to be followed by another
directive or the end of the file just like other directives.

The attached patch files do the job (I think). Tested with a windows build
and invalidly placed ::end directives as well as well placed ::end
directives

---

Sent from sourceforge.net because you indicated interest in <
https://sourceforge.net/p/oorexx/feature-requests/664/>

To unsubscribe from further messages, please visit <
https://sourceforge.net/auth/subscriptions/>

[Ruurd Idenburg]

On 22-4-2015 19:01, Rick McGuire wrote:

Patch(es) in a coming episode.

Further step would be to limit ::END to directives that (may) have
body
text,i.e. code.

I'd say that would be an absolute requirement for inclusion. The
processing of this directive (except for class closure ones) should be in
the code that handles method/routine bodies rather than processed in the
directive section.

After looking at the code again, I agree, a better and easier approach,
so ::END can optionally appear after code blocks (i.e. ooRexx code), may
optionally be followed by a symbol/literal that should match the name of
the class, method (including getter and setter ooRexx code blocks for
::attribute) or routine.

I'll see if I can produce something in that order, so no alternatives 1
and 2 anymore.

--
Ruurd Idenburg

[Ruurd Idenburg]

Well, a night's sleep convinced me that alternative 1 is the one I would like:

1. Minimal impact/effort on code and language
2. maximum freedom for the programmer

So, ::END must be followed by another directive or EOF and may optionally have a symbol or literal after the ::END (e.g. ::END myMethod) and nothing more.

3 attachments:

1. parser.patch - all the code changes for the interpreter parser code
2. rexxmsgs.xml.patch - new messages due to ::END directive see "Ad2" below
3. testenddirective.rex - superficial test of ::END directive

Ad2:

when rexxmsgs.xml is being changed, you are supposed to run genmsgs.bat, which is not in the main trunk but you can find it in Rick's sandbox (sandbox/rick/newsource/platform/windows). There doesn't seem to be a nix variant, so either do this under windows or create a nix alternative. You also need xalan/xerces (see https://xml.apache.org/xalan-c/). Once done you can build ooRexx from the updated working copy in Windows as well as *nix.

Let the review board decide. 8-)

[Rick McGuire]

I certainly find this solution unacceptable. Having a directive that can appear anywhere without validation of placement or naming makes this extremely problematic for future extension. I'd recommend rejecting this extension outright. A poorly thought out and implemented language change should not be crammed in because you can't be troubled to fully implement it. Those types of things will always come back to bite you.

[Rick McGuire]

Already done in commit 10902

[Rick McGuire]

Oops, posted on the wrong tab.

[Moritz Hoffmann]

I don't think this is a valuable addition to the ooRexx language as it does not add any functionality but restricts future enhancements. Especially the fact that ::end is already used for resource blocks, this would cause unnecessary keyword overloading. Only adding it to aid development using some editor is not enough for a language change. I vote for closing this feature request.

[Rick McGuire]

I would leave the question of the ::END marker default separate from the discussion of whether the feature should be added. The choice of the marker string was somewhat arbitrary and since the ::resource feature has not shipped in a release yet, it can be easily changed to something else. This is feature is actually a pretty good argument that this string not start with "::" at all.

There is some usefulness in having this, but in my opinion, ONLY if it is implemented properly (e.g., proper placement checking and validity checking. Also questions like can it be used to close a ::class directive and ensuring that it actually functions as a closure (i.e., all subsequent methods until the next ::class directive are "unattached").

[Ruurd Idenburg]

My intention was a to have a directive that has no function (though the title doesn't make that very clear), my choice for ::END seems to be a bit controversial, would changing ::END in e.g. ::REM(ark) make the whole thing less disapprovable? And I agree ::END should be used for more meaningfull things like CLASS closure, which then brings up if any other directives than ::METHOD would be allowed within the ::CLASS definition?

[Rick McGuire]

My objection is to the concept if a directive with no function and no rules. No amount of renaming will fix that.

[Ruurd Idenburg]

Like /.../ and -- ?

[Jon Wolfers]

Hi Ruurd,

Like /.../ and -- ?

I'm not sure I understand what you are asking here, care to try again please,

Jon

[Anonymous]

Jon, just like comments have no function and rules languagewise, I think.