STUBS vs. ABSTRACT vs. INTERFACE Classes

[ThSITC]

When trying to deliver all of my Soft, to *open Source*, at
www.Kenai.com, ...

*I* am still having a *fundamental* lack of knowledge, I'll have to
close ASAP, as follows:

*I* did implement a multi-lingual Scanner, Parser, Anaylser, etc etc,
*and* Program Generator.

*I* did, however, always use a technique that I can re-use already
*existing classes*
to *REDEFINE them*  (as Rene did point out, correctly, a year ago, with
my packages
*donated* to RexxLA, namely the former Rexx2Nrx run-time package, and
the utils package.

Now, in an attempt to RE-COMPILE everything from scratch, I am focussing
a copule of problems.

What I did, has been:


*Write a STUB*
*Use this STUB*
*Implement this STUB*
*Use this new, implemented STUB, in turn*

This is now causing me a headache, sorry to say!

I'm, now, wondering, whether I shall replace those *ancient* program
development technology
of myself, to a *better technology*.

What shall I have to use:

a) Abstract Classes & Methods
     *or*
b) Interface Classes & Methods

As I am *not yet* fluent with OO principles of program development,

*I am simply asking the knowledgablel people*
(without GOOGLE'NG, sorry to say, again :-()

Wouldn't know what to GOOGLE to Xplain to me the change of program
development techniques
I did use *very successfully* for decenniums now :-(

Thomas Schneider.
========================================================================

.


--
Thomas Schneider, IT Consulting; http://www.thsitc.com; Vienna, Austria,
Europe

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[rvjansen]

Thomas,

that is a good question and I doubt that Googling would have brought you very much regarding the NetRexx specifics in this case. I am also inviting others to add to/correct this answer, in order to come to some design for a future version.

1) Compiling mutually dependent classes together alwaysworks in NetRexx - as long as they are all written in NetRexx - the translator will look at them all at once and resolve the dependencies. What not to do, as I have stated a number of times, is to link to older versions of your code in jars; you will then be at the hands of the runtime resolution of classpath, and the alphabetic sequence of your classnames. But what will always work, is deleting all classes (including the ones in jars on your classpath) and sending them all at once to the translator - if they are all NetRexx source.

2) This is not always what you want: I favour the approach of only recompiling changed code while developing. It is a matter of principle, and becomes a reality when having systems with a large number of classes (we once had some 8000 when code generation was used), and/or slow processors - I fixed a makefile on the Raspberry Pi yesterday evening because my patience for running a full build ran out - usually I cross compile with NetRexx on the fastest machine I have and push a jar, but this is a special case involving tricky firewall settings). Here the problem is, that you will need to find out the dependencies; while not as bad as C++ static code, there are limits to the JVM's dynamic linking and resolving. Here the dependencies will be resolved correctly if you remember to have the classnames that are needed earlier, earlier in the alphabet wrt the names of the classes - I am not sure if this goes for all platforms and all globbing mechanisms. I have made a habit of naming the top level class that uses everything, starting with a z. So you can see a zAllTests.nrx nowadays in the codebase. Sometimes I forget and depending on the mood (and if I checked in already or like a particular name) I rename or put the classname in front of the rest in the make target.

3) I am of the opinion that NetRexx should look for the source of unresolved references on the classpath instead of giving up, and should construct proxies for classes provably written in other languages. Cross language dependencies have cost me more time than I am willing to admit - over the period 2002-2007 this is measured in hours rather than minutes.

4) A architecturally elegant solution to the problem is to define interfaces, and have all calls going through the interfaces. If you compile the interfaces first, you have less of a problem with dependencies, and you have more decoupling in your system, which you can use to your advantage. The layering of the code will be better if you have thought it through in advance; or at least when you encounter the first problems with it. I always have interfaces in a separate make target, which is compiled first. There is something with NetRexx and changed interfaces which is hard to lay my hand on, but it exists. I tend to use more interfaces than abstract classes, but it is a matter of taste I guess. You can include implementation in abstract classes but not in interfaces; when I see abstract classes I always get the impression of pedantic oo-people; it might be a personal matter. There will be use cases for one or the other.

best regards,

René.


On 7 dec. 2012, at 09:48, Thomas Schneider <[hidden email]> wrote:

> When trying to deliver all of my Soft, to *open Source*, at www.Kenai.com, ...
>
> *I* am still having a *fundamental* lack of knowledge, I'll have to close ASAP, as follows:
>
> *I* did implement a multi-lingual Scanner, Parser, Anaylser, etc etc, *and* Program Generator.
>
> *I* did, however, always use a technique that I can re-use already *existing classes*
> to *REDEFINE them*  (as Rene did point out, correctly, a year ago, with my packages
> *donated* to RexxLA, namely the former Rexx2Nrx run-time package, and the utils package.
>
> Now, in an attempt to RE-COMPILE everything from scratch, I am focussing a copule of problems.
>
> What I did, has been:
>
>
> *Write a STUB*
> *Use this STUB*
> *Implement this STUB*
> *Use this new, implemented STUB, in turn*
>
> This is now causing me a headache, sorry to say!
>
> I'm, now, wondering, whether I shall replace those *ancient* program development technology
> of myself, to a *better technology*.
>
> What shall I have to use:
>
> a) Abstract Classes & Methods
>    *or*
> b) Interface Classes & Methods
>
> As I am *not yet* fluent with OO principles of program development,
>
> *I am simply asking the knowledgablel people*
> (without GOOGLE'NG, sorry to say, again :-()
>
> Wouldn't know what to GOOGLE to Xplain to me the change of program development techniques
> I did use *very successfully* for decenniums now :-(
>
> Thomas Schneider.
> ========================================================================
>
> .
>
>
> --
> Thomas Schneider, IT Consulting; http://www.thsitc.com; Vienna, Austria, Europe
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[ThSITC]

Hi Rene, *and all* !

Thanks, Rene, then I will *Proceed* To DEFINE now *new interface NetRexx
classes*
  *on TOP* of my (cyclic now) own Code!

Thank you so much, for this advise!
Thomas .... (still alive, but living at the bottom, currently)

PS: Sorry soo much for any & all Delays in the promised deliveries, by
the way, Walter Pachl, and all ...
================================================================================
PPS: I am thinking, at the minute, that I did *understand* Rene Vincent
Jansen's reply!

Any other opinions, plz. do simply *reply here* :-)

Thomas Schneider.
================================================================================


Am 07.12.2012 16:37, schrieb René Jansen:
> interfaces. If you compile the interfaces first, you have less of a problem with dependencies, and you have more


--
Thomas Schneider, IT Consulting; http://www.thsitc.com; Vienna, Austria,
Europe

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Kermit Kiser]

René --

I have a couple of questions inline below.

-- Kermit

On 12/7/2012 5:37 AM, René Jansen wrote:
> Thomas,
>
> that is a good question and I doubt that Googling would have brought you very much regarding the NetRexx specifics in this case. I am also inviting others to add to/correct this answer, in order to come to some design for a future version.
>
> 1) Compiling mutually dependent classes together alwaysworks in NetRexx - as long as they are all written in NetRexx - the translator will look at them all at once and resolve the dependencies. What not to do, as I have stated a number of times, is to link to older versions of your code in jars; you will then be at the hands of the runtime resolution of classpath, and the alphabetic sequence of your classnames. But what will always work, is deleting all classes (including the ones in jars on your classpath) and sending them all at once to the translator - if they are all NetRexx source.
>
> 2) This is not always what you want: I favour the approach of only recompiling changed code while developing. It is a matter of principle, and becomes a reality when having systems with a large number of classes (we once had some 8000 when code generation was used), and/or slow processors - I fixed a makefile on the Raspberry Pi yesterday evening because my patience for running a full build ran out - usually I cross compile with NetRexx on the fastest machine I have and push a jar, but this is a special case involving tricky firewall settings). Here the problem is, that you will need to find out the dependencies; while not as bad as C++ static code, there are limits to the JVM's dynamic linking and resolving. Here the dependencies will be resolved correctly if you remember to have the classnames that are needed earlier, earlier in the alphabet wrt the names of the classes - I am not sure if this goes for all platforms and all globbing mechanisms. I have made a habit of naming the top level class that uses everything, starting with a z. So you can see a zAllTests.nrx nowadays in the codebase. Sometimes I forget and depending on the mood (and if I checked in already or like a particular name) I rename or put the classname in front of the rest in the make target.
>
> 3) I am of the opinion that NetRexx should look for the source of unresolved references on the classpath instead of giving up, and should construct proxies for classes provably written in other languages.
How would this work? Would NetRexx have to be able to read and interpret
Java source code?
>   Cross language dependencies have cost me more time than I am willing to admit - over the period 2002-2007 this is measured in hours rather than minutes.
>
> 4) A architecturally elegant solution to the problem is to define interfaces, and have all calls going through the interfaces. If you compile the interfaces first, you have less of a problem with dependencies, and you have more decoupling in your system, which you can use to your advantage. The layering of the code will be better if you have thought it through in advance; or at least when you encounter the first problems with it. I always have interfaces in a separate make target, which is compiled first. There is something with NetRexx and changed interfaces which is hard to lay my hand on, but it exists.
Is the interface issue a NetRexx bug? I had to add some patches for
interface handling to the advanced NetRexx after3.01 branch. Perhaps
those and the updated method resolution algorithms would help?
>   I tend to use more interfaces than abstract classes, but it is a matter of taste I guess. You can include implementation in abstract classes but not in interfaces; when I see abstract classes I always get the impression of pedantic oo-people; it might be a personal matter. There will be use cases for one or the other.
>
> best regards,
>
> René.
>
>


_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[ThSITC]

Hi Kermit, and all:

    *I* am working here on my *PP Machine*, which is aimed (when ready,
only), to build a
*Double* ***Weighted Graph*** of dependecies.

    *I* do call this the *CRAPH* Theory.

    A *CRAPH* is a *coloured GRAPH*.

*A* coloured Graph (called CRAPH, for shortness) does and did have a so
called
*TURAN NUMBER* (upper Limit for CHI, the Chromatic number of a Graph)),
and a never yet determined *lower limit* (as far as I do know, at least)

The CHROMATIC Number (named XI in the Greek alphabet, old Mathematic
sciences)
has been never detected, in GRAPH Theory), exactly.

Now, Fortune, as we do have:

A CRAPH is a double sided, double weightef, COLOURED Graph!

Formulas do (and/or might) exist to COLOUR this CRAPH (formerly called
Coloured Graph)

Ok?

Massa Thomas ... ;-)
===================================================================
Am 08.12.2012 01:14, schrieb Kermit Kiser:

> René --
>
> I have a couple of questions inline below.
>
> -- Kermit
>
> On 12/7/2012 5:37 AM, René Jansen wrote:
>> Thomas,
>>
>> that is a good question and I doubt that Googling would have brought
>> you very much regarding the NetRexx specifics in this case. I am also
>> inviting others to add to/correct this answer, in order to come to
>> some design for a future version.
>>
>> 1) Compiling mutually dependent classes together alwaysworks in
>> NetRexx - as long as they are all written in NetRexx - the translator
>> will look at them all at once and resolve the dependencies. What not
>> to do, as I have stated a number of times, is to link to older
>> versions of your code in jars; you will then be at the hands of the
>> runtime resolution of classpath, and the alphabetic sequence of your
>> classnames. But what will always work, is deleting all classes
>> (including the ones in jars on your classpath) and sending them all
>> at once to the translator - if they are all NetRexx source.
>>
>> 2) This is not always what you want: I favour the approach of only
>> recompiling changed code while developing. It is a matter of
>> principle, and becomes a reality when having systems with a large
>> number of classes (we once had some 8000 when code generation was
>> used), and/or slow processors - I fixed a makefile on the Raspberry
>> Pi yesterday evening because my patience for running a full build ran
>> out - usually I cross compile with NetRexx on the fastest machine I
>> have and push a jar, but this is a special case involving tricky
>> firewall settings). Here the problem is, that you will need to find
>> out the dependencies; while not as bad as C++ static code, there are
>> limits to the JVM's dynamic linking and resolving. Here the
>> dependencies will be resolved correctly if you remember to have the
>> classnames that are needed earlier, earlier in the alphabet wrt the
>> names of the classes - I am not sure if this goes for all platforms
>> and all globbing mechanisms. I have made a habit of naming the top
>> level class that uses everything, starting with a z. So you can see a
>> zAllTests.nrx nowadays in the codebase. Sometimes I forget and
>> depending on the mood (and if I checked in already or like a
>> particular name) I rename or put the classname in front of the rest
>> in the make target.
>>
>> 3) I am of the opinion that NetRexx should look for the source of
>> unresolved references on the classpath instead of giving up, and
>> should construct proxies for classes provably written in other
>> languages.
> How would this work? Would NetRexx have to be able to read and
> interpret Java source code?
>>   Cross language dependencies have cost me more time than I am
>> willing to admit - over the period 2002-2007 this is measured in
>> hours rather than minutes.
>>
>> 4) A architecturally elegant solution to the problem is to define
>> interfaces, and have all calls going through the interfaces. If you
>> compile the interfaces first, you have less of a problem with
>> dependencies, and you have more decoupling in your system, which you
>> can use to your advantage. The layering of the code will be better if
>> you have thought it through in advance; or at least when you
>> encounter the first problems with it. I always have interfaces in a
>> separate make target, which is compiled first. There is something
>> with NetRexx and changed interfaces which is hard to lay my hand on,
>> but it exists.
> Is the interface issue a NetRexx bug? I had to add some patches for
> interface handling to the advanced NetRexx after3.01 branch. Perhaps
> those and the updated method resolution algorithms would help?
>>   I tend to use more interfaces than abstract classes, but it is a
>> matter of taste I guess. You can include implementation in abstract
>> classes but not in interfaces; when I see abstract classes I always
>> get the impression of pedantic oo-people; it might be a personal
>> matter. There will be use cases for one or the other.
>>
>> best regards,
>>
>> René.
>>
>>
>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
>

--
Thomas Schneider, IT Consulting; http://www.thsitc.com; Vienna, Austria,
Europe

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[rvjansen]

Kermit,

further inline.

On 7 dec. 2012, at 20:14, Kermit Kiser <[hidden email]> wrote:

> René --
>
> I have a couple of questions inline below.
>
> -- Kermit
>
> On 12/7/2012 5:37 AM, René Jansen wrote:
>> Thomas,
>>
>> that is a good question and I doubt that Googling would have brought you very much regarding the NetRexx specifics in this case. I am also inviting others to add to/correct this answer, in order to come to some design for a future version.
>>
>> 1) Compiling mutually dependent classes together alwaysworks in NetRexx - as long as they are all written in NetRexx - the translator will look at them all at once and resolve the dependencies. What not to do, as I have stated a number of times, is to link to older versions of your code in jars; you will then be at the hands of the runtime resolution of classpath, and the alphabetic sequence of your classnames. But what will always work, is deleting all classes (including the ones in jars on your classpath) and sending them all at once to the translator - if they are all NetRexx source.
>>
>> 2) This is not always what you want: I favour the approach of only recompiling changed code while developing. It is a matter of principle, and becomes a reality when having systems with a large number of classes (we once had some 8000 when code generation was used), and/or slow processors - I fixed a makefile on the Raspberry Pi yesterday evening because my patience for running a full build ran out - usually I cross compile with NetRexx on the fastest machine I have and push a jar, but this is a special case involving tricky firewall settings). Here the problem is, that you will need to find out the dependencies; while not as bad as C++ static code, there are limits to the JVM's dynamic linking and resolving. Here the dependencies will be resolved correctly if you remember to have the classnames that are needed earlier, earlier in the alphabet wrt the names of the classes - I am not sure if this goes for all platforms and all globbing mechanisms. I have made a habit of naming the top level class that uses everything, starting with a z. So you can see a zAllTests.nrx nowadays in the codebase. Sometimes I forget and depending on the mood (and if I checked in already or like a particular name) I rename or put the classname in front of the rest in the make target.
>>
>> 3) I am of the opinion that NetRexx should look for the source of unresolved references on the classpath instead of giving up, and should construct proxies for classes provably written in other languages.
> How would this work? Would NetRexx have to be able to read and interpret Java source code?

Yes, amongst others - it should be able to start a java compile and retry after that succeeds if it determines that there is a java source corresponding to the missing class file. It also might be groovy - scala - jruby of course, but java for starters would be excellent.

>> Cross language dependencies have cost me more time than I am willing to admit - over the period 2002-2007 this is measured in hours rather than minutes.
>>
>> 4) A architecturally elegant solution to the problem is to define interfaces, and have all calls going through the interfaces. If you compile the interfaces first, you have less of a problem with dependencies, and you have more decoupling in your system, which you can use to your advantage. The layering of the code will be better if you have thought it through in advance; or at least when you encounter the first problems with it. I always have interfaces in a separate make target, which is compiled first. There is something with NetRexx and changed interfaces which is hard to lay my hand on, but it exists.
> Is the interface issue a NetRexx bug? I had to add some patches for interface handling to the advanced NetRexx after3.01 branch. Perhaps those and the updated method resolution algorithms would help?

Not sure if it is a bug, I just have a funny feeling after encountering many interface related (also: exception signatures) 'issues'. If I can every lay my hand on it, then I will make a testcase out of it.

>> I tend to use more interfaces than abstract classes, but it is a matter of taste I guess. You can include implementation in abstract classes but not in interfaces; when I see abstract classes I always get the impression of pedantic oo-people; it might be a personal matter. There will be use cases for one or the other.
>>
>> best regards,
>>
>> René.
>>
>>
>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Kermit Kiser]

René --

I have been trying to get time between programming bursts to respond to
your earlier question about dependency analysis and it's relationship to
the reflection compiler experiment. This issue of NetRexx looking for
non NetRexx modules seems related to that one. While the dependency
issue is somewhat related to the goal of replacing "pre-reading"with
reflection class loading, they are different issues and separate
projects in my view.

As you may have guessed, I wrote the new JSR223 script engine for
NetRexx largely because I could not find any way to make Ant do the
complex build process I needed for NetRexx Android projects that use
Android shared "library projects". I was just trying to update the
NetRexx Android IDE to support those shared library projects but I was
stumped by the lack of variables and iterative processing in Ant. Ant
has support for BSF and JSR223 so being able to run NetRexx scripts as
part of Ant builds solved the problem for me. If I had known about the
JSR223 hook in Ant back then, I probably would have finished the JSR223
project three years ago. (Of course it works a lot better now that we
have program interpretation from memory strings available!)

What does this have to do with dependency issues? Well, in the course of
the above project, I found a major logic flaw in the distributed Android
build process and reported it to the Google tool development guys. Their
response admitted that it was a fixable bug but that I should not expect
it to be fixed any time soon because they are currently developing a
completely new Android build process to replace the existing Eclipse and
Ant processes. That project apparently has priority for them. So I
looked into the new build approach they are working on. It uses a build
system called "Gradle" which I had never heard about before. It appears
that in order to use the Gradle system, you must know the Groovy
programming language. That disturbs me greatly! If I wanted to use
something with that horrible Java style of brace filled syntax, I would
not be programming in NetRexx!

I was already speculating about the possibility of developing our own
NetRexx centric build system but some comments by the Gradle developers
caught my eye. They say it integrates well with Ant and even with Maven.
I tolerate Ant and I kind of know what Maven is and when I research
online lots of comparisons of Maven vs Ant vs Gradle pop up. What do the
Maven fans hate about Gradle? "It is too flexible" - it allows you to do
things however you need or want to do them. That is the same complaint
they have about Ant. Well, inflexibility in Ant is what just stumped me,
so that is a big strike against Maven and a big boost to Gradle in my
opinion. I am pretty sure Maven is not going to handle any complex
NetRexx based builds without major effort. (They say you have to write a
plugin to do anything Maven is not already familiar with.)  The thing
that stopped me from even suggesting a NetRexx based build system in the
past was the complexity of the dependency system we would need to build.
But the Gradle developers make an interesting comment on their product
overview page (http://www.gradle.org/overview):

"The Gradle design is well-suited for creating another build script
engine in JRuby or Jython. It just doesn't have the highest priority for
us at the moment. We happily support any community effort to create
additional build script engines."

Whoa?! Does that mean we could create a NetRexx version of Gradle which
could script NetRexx builds in NetRexx with full dependency management
and integration with Ant/Ivy/Maven? I think it is worth researching
especially if we will have to learn Gradle for Android development anyway.

Just my thoughts on this subject. Does anyone else have any?

-- Kermit

On 12/7/2012 3:10 PM, René Jansen wrote:

> Kermit,
>
> further inline.
>
> On 7 dec. 2012, at 20:14, Kermit Kiser <[hidden email]> wrote:
>
>> René --
>>
>> I have a couple of questions inline below.
>>
>> -- Kermit
>>
>> On 12/7/2012 5:37 AM, René Jansen wrote:
>>> Thomas,
>>>
>>> that is a good question and I doubt that Googling would have brought you very much regarding the NetRexx specifics in this case. I am also inviting others to add to/correct this answer, in order to come to some design for a future version.
>>>
>>> 1) Compiling mutually dependent classes together alwaysworks in NetRexx - as long as they are all written in NetRexx - the translator will look at them all at once and resolve the dependencies. What not to do, as I have stated a number of times, is to link to older versions of your code in jars; you will then be at the hands of the runtime resolution of classpath, and the alphabetic sequence of your classnames. But what will always work, is deleting all classes (including the ones in jars on your classpath) and sending them all at once to the translator - if they are all NetRexx source.
>>>
>>> 2) This is not always what you want: I favour the approach of only recompiling changed code while developing. It is a matter of principle, and becomes a reality when having systems with a large number of classes (we once had some 8000 when code generation was used), and/or slow processors - I fixed a makefile on the Raspberry Pi yesterday evening because my patience for running a full build ran out - usually I cross compile with NetRexx on the fastest machine I have and push a jar, but this is a special case involving tricky firewall settings). Here the problem is, that you will need to find out the dependencies; while not as bad as C++ static code, there are limits to the JVM's dynamic linking and resolving. Here the dependencies will be resolved correctly if you remember to have the classnames that are needed earlier, earlier in the alphabet wrt the names of the classes - I am not sure if this goes for all platforms and all globbing mechanisms. I have made a habit of naming the top level class that uses everything, starting with a z. So you can see a zAllTests.nrx nowadays in the codebase. Sometimes I forget and depending on the mood (and if I checked in already or like a particular name) I rename or put the classname in front of the rest in the make target.
>>>
>>> 3) I am of the opinion that NetRexx should look for the source of unresolved references on the classpath instead of giving up, and should construct proxies for classes provably written in other languages.
>> How would this work? Would NetRexx have to be able to read and interpret Java source code?
> Yes, amongst others - it should be able to start a java compile and retry after that succeeds if it determines that there is a java source corresponding to the missing class file. It also might be groovy - scala - jruby of course, but java for starters would be excellent.
>
>>> Cross language dependencies have cost me more time than I am willing to admit - over the period 2002-2007 this is measured in hours rather than minutes.
>>>
>>> 4) A architecturally elegant solution to the problem is to define interfaces, and have all calls going through the interfaces. If you compile the interfaces first, you have less of a problem with dependencies, and you have more decoupling in your system, which you can use to your advantage. The layering of the code will be better if you have thought it through in advance; or at least when you encounter the first problems with it. I always have interfaces in a separate make target, which is compiled first. There is something with NetRexx and changed interfaces which is hard to lay my hand on, but it exists.
>> Is the interface issue a NetRexx bug? I had to add some patches for interface handling to the advanced NetRexx after3.01 branch. Perhaps those and the updated method resolution algorithms would help?
> Not sure if it is a bug, I just have a funny feeling after encountering many interface related (also: exception signatures) 'issues'. If I can every lay my hand on it, then I will make a testcase out of it.
>
>>> I tend to use more interfaces than abstract classes, but it is a matter of taste I guess. You can include implementation in abstract classes but not in interfaces; when I see abstract classes I always get the impression of pedantic oo-people; it might be a personal matter. There will be use cases for one or the other.
>>>
>>> best regards,
>>>
>>> René.
>>>
>>>
>>
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
>
>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[ThSITC]

Hi Kermit, and all,

*there does exist* an Algorithm do *colour* a double weighted, double
sided, Graph!

In German, it is called the so called *Minimal-Grad-Folge*.

This is actually a methud, to determine a very quick *decision tree* to
find the Lower limit
for the so-called CHI-Number,

The upper limit is the TURAN NUMBER.

I do have, however, to admit, that this statement has been true:

40 years past (when I did write my master Thesis in Mathematics)

Deepest pure Mathemathics (GRAPH Theory).

Sorry to say,

Thomas.
=======================================================================

Am 08.12.2012 08:37, schrieb Kermit Kiser:

> René --
>
> I have been trying to get time between programming bursts to respond
> to your earlier question about dependency analysis and it's
> relationship to the reflection compiler experiment. This issue of
> NetRexx looking for non NetRexx modules seems related to that one.
> While the dependency issue is somewhat related to the goal of
> replacing "pre-reading"with reflection class loading, they are
> different issues and separate projects in my view.
>
> As you may have guessed, I wrote the new JSR223 script engine for
> NetRexx largely because I could not find any way to make Ant do the
> complex build process I needed for NetRexx Android projects that use
> Android shared "library projects". I was just trying to update the
> NetRexx Android IDE to support those shared library projects but I was
> stumped by the lack of variables and iterative processing in Ant. Ant
> has support for BSF and JSR223 so being able to run NetRexx scripts as
> part of Ant builds solved the problem for me. If I had known about the
> JSR223 hook in Ant back then, I probably would have finished the
> JSR223 project three years ago. (Of course it works a lot better now
> that we have program interpretation from memory strings available!)
>
> What does this have to do with dependency issues? Well, in the course
> of the above project, I found a major logic flaw in the distributed
> Android build process and reported it to the Google tool development
> guys. Their response admitted that it was a fixable bug but that I
> should not expect it to be fixed any time soon because they are
> currently developing a completely new Android build process to replace
> the existing Eclipse and Ant processes. That project apparently has
> priority for them. So I looked into the new build approach they are
> working on. It uses a build system called "Gradle" which I had never
> heard about before. It appears that in order to use the Gradle system,
> you must know the Groovy programming language. That disturbs me
> greatly! If I wanted to use something with that horrible Java style of
> brace filled syntax, I would not be programming in NetRexx!
>
> I was already speculating about the possibility of developing our own
> NetRexx centric build system but some comments by the Gradle
> developers caught my eye. They say it integrates well with Ant and
> even with Maven. I tolerate Ant and I kind of know what Maven is and
> when I research online lots of comparisons of Maven vs Ant vs Gradle
> pop up. What do the Maven fans hate about Gradle? "It is too flexible"
> - it allows you to do things however you need or want to do them. That
> is the same complaint they have about Ant. Well, inflexibility in Ant
> is what just stumped me, so that is a big strike against Maven and a
> big boost to Gradle in my opinion. I am pretty sure Maven is not going
> to handle any complex NetRexx based builds without major effort. (They
> say you have to write a plugin to do anything Maven is not already
> familiar with.)  The thing that stopped me from even suggesting a
> NetRexx based build system in the past was the complexity of the
> dependency system we would need to build. But the Gradle developers
> make an interesting comment on their product overview page
> (http://www.gradle.org/overview):
>
> "The Gradle design is well-suited for creating another build script
> engine in JRuby or Jython. It just doesn't have the highest priority
> for us at the moment. We happily support any community effort to
> create additional build script engines."
>
> Whoa?! Does that mean we could create a NetRexx version of Gradle
> which could script NetRexx builds in NetRexx with full dependency
> management and integration with Ant/Ivy/Maven? I think it is worth
> researching especially if we will have to learn Gradle for Android
> development anyway.
>
> Just my thoughts on this subject. Does anyone else have any?
>
> -- Kermit
>
> On 12/7/2012 3:10 PM, René Jansen wrote:
>> Kermit,
>>
>> further inline.
>>
>> On 7 dec. 2012, at 20:14, Kermit Kiser <[hidden email]> wrote:
>>
>>> René --
>>>
>>> I have a couple of questions inline below.
>>>
>>> -- Kermit
>>>
>>> On 12/7/2012 5:37 AM, René Jansen wrote:
>>>> Thomas,
>>>>
>>>> that is a good question and I doubt that Googling would have
>>>> brought you very much regarding the NetRexx specifics in this case.
>>>> I am also inviting others to add to/correct this answer, in order
>>>> to come to some design for a future version.
>>>>
>>>> 1) Compiling mutually dependent classes together alwaysworks in
>>>> NetRexx - as long as they are all written in NetRexx - the
>>>> translator will look at them all at once and resolve the
>>>> dependencies. What not to do, as I have stated a number of times,
>>>> is to link to older versions of your code in jars; you will then be
>>>> at the hands of the runtime resolution of classpath, and the
>>>> alphabetic sequence of your classnames. But what will always work,
>>>> is deleting all classes (including the ones in jars on your
>>>> classpath) and sending them all at once to the translator - if they
>>>> are all NetRexx source.
>>>>
>>>> 2) This is not always what you want: I favour the approach of only
>>>> recompiling changed code while developing. It is a matter of
>>>> principle, and becomes a reality when having systems with a large
>>>> number of classes (we once had some 8000 when code generation was
>>>> used), and/or slow processors - I fixed a makefile on the Raspberry
>>>> Pi yesterday evening because my patience for running a full build
>>>> ran out - usually I cross compile with NetRexx on the fastest
>>>> machine I have and push a jar, but this is a special case involving
>>>> tricky firewall settings). Here the problem is, that you will need
>>>> to find out the dependencies; while not as bad as C++ static code,
>>>> there are limits to the JVM's dynamic linking and resolving. Here
>>>> the dependencies will be resolved correctly if you remember to have
>>>> the classnames that are needed earlier, earlier in the alphabet wrt
>>>> the names of the classes - I am not sure if this goes for all
>>>> platforms and all globbing mechanisms. I have made a habit of
>>>> naming the top level class that uses everything, starting with a z.
>>>> So you can see a zAllTests.nrx nowadays in the codebase. Sometimes
>>>> I forget and depending on the mood (and if I checked in already or
>>>> like a particular name) I rename or put the classname in front of
>>>> the rest in the make target.
>>>>
>>>> 3) I am of the opinion that NetRexx should look for the source of
>>>> unresolved references on the classpath instead of giving up, and
>>>> should construct proxies for classes provably written in other
>>>> languages.
>>> How would this work? Would NetRexx have to be able to read and
>>> interpret Java source code?
>> Yes, amongst others - it should be able to start a java compile and
>> retry after that succeeds if it determines that there is a java
>> source corresponding to the missing class file. It also might be
>> groovy - scala - jruby of course, but java for starters would be
>> excellent.
>>
>>>> Cross language dependencies have cost me more time than I am
>>>> willing to admit - over the period 2002-2007 this is measured in
>>>> hours rather than minutes.
>>>>
>>>> 4) A architecturally elegant solution to the problem is to define
>>>> interfaces, and have all calls going through the interfaces. If you
>>>> compile the interfaces first, you have less of a problem with
>>>> dependencies, and you have more decoupling in your system, which
>>>> you can use to your advantage. The layering of the code will be
>>>> better if you have thought it through in advance; or at least when
>>>> you encounter the first problems with it. I always have interfaces
>>>> in a separate make target, which is compiled first. There is
>>>> something with NetRexx and changed interfaces which is hard to lay
>>>> my hand on, but it exists.
>>> Is the interface issue a NetRexx bug? I had to add some patches for
>>> interface handling to the advanced NetRexx after3.01 branch. Perhaps
>>> those and the updated method resolution algorithms would help?
>> Not sure if it is a bug, I just have a funny feeling after
>> encountering many interface related (also: exception signatures)
>> 'issues'. If I can every lay my hand on it, then I will make a
>> testcase out of it.
>>
>>>> I tend to use more interfaces than abstract classes, but it is a
>>>> matter of taste I guess. You can include implementation in abstract
>>>> classes but not in interfaces; when I see abstract classes I always
>>>> get the impression of pedantic oo-people; it might be a personal
>>>> matter. There will be use cases for one or the other.
>>>>
>>>> best regards,
>>>>
>>>> René.
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Ibm-netrexx mailing list
>>> [hidden email]
>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>>>
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>>
>>
>>
>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
>

--
Thomas Schneider, IT Consulting; http://www.thsitc.com; Vienna, Austria,
Europe

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/