[Gambas-user] C like #include for Gambas

jm joem at ...2671...
Sat Jun 9 14:51:35 CEST 2012


On Sat, 2012-06-09 at 02:45 +0300, Jussi Lahtinen wrote:
> Maybe I'm just too tired, but I don't understand the point.
> 
> If you have huge program that needs to be expended just a little bit,
> then why don't you just add new class/module/piece of code/etc which holds
> that new thing to the program?
> 
> Or if you need something from the program like "#include yourmodule" then
> just write "yourmodule.whateveryouneed".
> 
> This sounds more like design problem of the code, than limitation of Gambas.
> 
> Jussi
> 
> 

C thrives on #include without showing signs of design problems.
Tens of thousands of external lines of code can be pulled in with
a dozen #include statements, leaving the code completely manageable,
readable and a lot more powerful than any other competing method.

The nearest competing method is use of modules and classes but these
are nowhere near as powerful for the simple reason explained previously
which is that large versions of these objects cannot be initialised
without expending large amounts of effort at initialising them.

For example, in module_a.module you might have

  PRIVATE CONST MAXIMUM_CSV_PARAMETERS AS Integer = 100
  PRIVATE WordMarker1 AS Integer
  :
  '200 further variable declarations and initialisations
  :
  PRIVATE sParameterNameArray AS NEW String[MAXIMUM_CSV_PARAMETERS]
  PRIVATE sParameterValueArray AS NEW String[MAXIMUM_CSV_PARAMETERS]
  '
  'add more code specific to module_a

In module_b.module you might have

  PRIVATE CONST MAXIMUM_CSV_PARAMETERS AS Integer = 300
  PRIVATE WordMarker1 AS Integer
  :
  '200 further variable declarations and initialisations
  :
  PRIVATE sParameterNameArray AS NEW String[MAXIMUM_CSV_PARAMETERS]
  PRIVATE sParameterValueArray AS NEW String[MAXIMUM_CSV_PARAMETERS]
  '
  'add more code specific to module_b


It would be simpler to have C like # include to increase
the programming power. So in module_a.module the program would
read like a C #include:

  PRIVATE CONST MAXIMUM_CSV_PARAMETERS AS Integer = 100
  #include "initialise_csv_variables.include"
  '
  'add more code specific to module_a

and in module_b.module it would read: 

  PRIVATE CONST MAXIMUM_CSV_PARAMETERS AS Integer = 300
  #include "initialise_csv_variables.include"
  '
  'add more code specific to module_b


and in a file called initialise_csv_variables.include it would contain:

  PRIVATE WordMarker1 AS Integer
  :
  '200 further variable declarations and initialisations
  :
  PRIVATE sParameterNameArray AS NEW String[MAXIMUM_CSV_PARAMETERS]
  PRIVATE sParameterValueArray AS NEW String[MAXIMUM_CSV_PARAMETERS]

The #include files can contain any amount of well trodden
proven gambas code which is maintained in only one file.

I will argue that adding C like #include functionality saves a ton of
work in mega programs which are already working well, but now
needs to be expanded even further.


Any chance of sneaking in this productivity enhancing feature? :-)


> 
> 
> On 9 June 2012 01:16, jm <joem at ...2671...> wrote:
> 
> > C like #include files for gambas?
> >
> > Sounds a bit harsh I know, but is it possible to add a feature
> > that functions like a C #include?
> >
> > The logic behind is to address programs that are growing
> > out of control in size. These are working megalithic programs that
> > have had years of code piled on top of other code.
> > The code has lost none of their lustre and needs to be
> > expanded even more and that bit is being held up
> > by this issue:
> >
> > If I break down programs into modules, then there is a huge
> > overhead in passing parameters.
> >
> > If I break it down into classes, there is still a huge overhead
> > in setting up classes and passing data around.
> >
> > These are programs that require hundred(s) of parameters to be
> > set up if they are to pass data around to do one simple thing
> > correctly.
> >
> > I have no problems doing it, but its boring and now becoming
> > prone to mistakes in the way the parameters are being set up,
> > and the order in which objects are being created.
> > It is difficult to keep track of thousands of things at the
> > same time.
> >
> > So I was thinking, it would be better to allow gambas programs
> > to grow in size to reduce the number of different ways the
> > objects are set up. But that is fatal, because you just can't find stuff
> > quickly enough when you got tens of thousands of lines.
> >
> > I also program in C, and #include is a common way to
> > pull in stuff from all over the place. It is a way to
> > pull in mega numbers of .h and .c program files from all over the place
> > and make a huge program without actually writing uneditable huge
> > programs.
> >
> > The individual .c and .h programs make life so easy to debug
> > and mix and match files as you need it by using a #include
> > at the time and place you need it.
> > Each of the .h and .c programs are separately maintained.
> > Because there is only one .h file or one .c file,
> > there is never any mistakes during duplication.
> >
> > If gambas supported #include, it would be possible
> > to use #include to pull in variable declarations,
> > and snippets of well trodden code as needed without having
> > to copy and paste that would otherwise end up with numerous copies
> > of similar code. Instead there will be just a couple
> > of files that gets pulled in as needed with a #include.
> >
> > Any chance of sneaking in this productivity enhancing feature? :-)
> >
> >
> >
> >
> > ______________________________________________________________________________
> > This message has been checked for viruses and spam by Corpex using
> > the ArmourPlate Anti Virus and Anti Spam Scanning Service.
> > To find out more and see our email archiving service see
> > http://www.armourplate.com or call Corpex on UK 0845 050 1898.
> >
> >
> > ------------------------------------------------------------------------------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond. Discussions
> > will include endpoint security, mobile security and the latest in malware
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > Gambas-user mailing list
> > Gambas-user at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/gambas-user
> >
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Gambas-user mailing list
> Gambas-user at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-user
> ______________________________________________________________________________
> This message has been checked for viruses and spam by Armourplate
> http://www.armourplate.com, the email archiving, anti virus and anti spam
> service from Corpex.


______________________________________________________________________________
This message has been checked for viruses and spam by Corpex using
the ArmourPlate Anti Virus and Anti Spam Scanning Service.
To find out more and see our email archiving service see
http://www.armourplate.com or call Corpex on UK 0845 050 1898.




More information about the User mailing list