Plex 2E

All,

When building an abstract function, I'll make use of the standard pattern subroutine structure:

+++Define Field: FIELDS/+Subroutine
Edit Point Start mySubroutine
If  Field: FIELDS/Subroutine
Edit Point End mySubroutine
+++Undefine Field: FIELDS/+Subroutine

Question: Does anybody use the same structure for subroutines in implemented (non-abstract) functions?

I don't see any benefit to doing so, seems to just add noise to the AD.

Thanks!
Charles

HI Charles,

I use the same for both. I like noise though :)

Bottom line, eventually you are going to find a situation where you're going to wish you had done it consistently...

Crispin.

Hi Charles,

we always use this structure for all subroutines abstract or not.

We use a keyboard macro tool (KeyText) to automate many of the developer tasks that we do a lot like the subroutine structure.

E.g. If I in the action diagram editor write 'sub the KeyText asked for a subroutine name and automatically generates the sub and the required structure and ends up pointing to the if field subroutine for me to add my code.

I would strongly recommend looking into KeyText to automated tedious developer tasks - this will also help you to "remember" to do it!

Some examples of these automations:
1) Create subroutine with required structure
2) Have all calls validated by checking call status and returning status
3) Create the correct while loop for doing calls to BlockFetch functions

And another thing you might not have thought of a function being abstract but at one point someone might do a is a :-)

Niels P.
Websydian

Nielsp wrote:

And another thing you might not have thought of a function being abstract but at one point someone might do a is a :-)

Niels,

True, but we are not supposed to inherit from an implemented function :smile

Though it would seem to me that using the pattern subroutine structure would make it easier to do so... which is maybe why we shouldn't use it!

My thinking is that if I need to abstract out the functionality in an existing implemented function, it wouldn't be a big deal to add the subroutine structure at that time to the abstract version.

Which ties back to Crispin's post...adding it if needed is easy to do without effecting functionality...I can't imagine a scenario where I'd regret not having it in the first place...

I guess for me, when I see a subroutine with the pattern structure, I expect it to have been inherited from somewhere and used in more than one place such that there's a good chance I'm familiar with what it does. Thus, may not even need to open it up.

With local subroutines, I can't say the same. Even with a decent name, I'm going to need to open them up to understand them, having the extra, unneeded depth doesn't seem to add value.

Charles

Charles,

I very ralrey have subroutines that are truly local to a function. If I'm creating a subroutine, I tend towards creating a standalone function that contains as much as the subroutine needs to be written (but does not actually call the subroutine) and then inherit from that function. That way, if I need to use the same thing again, I already have it. Obviously this could become tricky to manage, so at some point you have to decide one way or the other.

I know this was discussed on the EDGE forums years ago...

With a local subriutine, you don't really have that much added depth, because the collection points aren't available, so it's only a few extra lines of code.

Anyway, it seems to me that you had already decided that it was bad form (sorry, I mean unneeded noise) to add the same structure in a local subroutine, so it's obviously your choice :)

Oh, one more thought. Making the local code look like inherited code helps dispel the "black art" feeling that people new to Plex tend to get when it comes to the shipped patterns. If it all looks the same, I think it's easier to gain the confidence that it is all the same. One of the biggest hurdles when starting to learn Plex is getting over the fact that the Patterns are really created in Plex, and not some magicians workshop :)

Crispin.

Crispin wrote:

Anyway, it seems to me that you had already decided that it was bad form (sorry, I mean unneeded noise) to add the same structure in a local subroutine, so it's obviously your choice :)

lol...true, I don't like at first glance...but I realize I've been working with Plex for a lot less time than others....so I'm willing to be convinced of it's usefulness. :smile

You've given me some points to ponder....hopefully some others will jump in with their thoughts.

Charles

You said it in another part of this thread, but my position on this is that it is bad form to inherit from implemented functions. I have had to go back too many times to correct something caused by changing an implemented function only to find that it has also been inherited from, and the downstream function doesn't want that change. I like Crispin's idea of keeping subroutines in their own function, and inherit them in. That sort of structure worked well for the pattern we did for importing interface files. I can envision a whole utility library of this type of function. In some cases I can see the usefulness of a function that does nothing but bring in a set of related options.

Along this line, I would like to see a triple that prevents implementation such as ... FUN abstraction SYS abstract/final. Abstract would not allow the pattern to be implemented directly, and final would not allow the pattern to be inherited from.

CharlesWilt wrote:

All,

When building an abstract function, I'll make use of the standard pattern subroutine structure:

+++Define Field: FIELDS/+Subroutine
Edit Point Start mySubroutine
If  Field: FIELDS/Subroutine
Edit Point End mySubroutine
+++Undefine Field: FIELDS/+Subroutine

Question: Does anybody use the same structure for subroutines in implemented (non-abstract) functions?

I don't see any benefit to doing so, seems to just add noise to the AD.

Thanks!
Charles

Always. It's become an automatic habit I've got into and not one I want to break. But I wouldn't stress over it too much.

Regards,
Jeremy Hutchinson
Desynit Limited
:: Plex Wiki :: 2E Wiki ::
:: Plex/2E Feed Aggregator ::
:: Edge Forum Archive ::