Another #include proposition

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Another #include proposition

Martijn Loots
Hi.

Reading through the mailing archives, I saw that this subject was
discussed before, but I still like to propose it once more... I'll
explain why:

My application is based on a 2 step approach (by means of a helper
script), like:

  Phase 1) handling inputs, filling my data structures and serializing
           this as haXe code specific for the task at hand

  Phase 2) compile the generated haXe code to create a flash movie

  (next: handover the flash movie to clients).


In this scenario, both phase 1) and 2) have large code pieces in
common (the data structures), while phase 1) specifically targets
file handling, XML etc. and phase 2) targets flash mainly.

For sake of reducing code size and keeping the code clean, I'd
would very much like to put the specific code for phase 1) resp.
phase 2) into different subdirectories, while keeping the common
part in its own package directory.

In my view, the perfect way to handle this, for example with a
file like 'testMe.hx':

   #if phase1 include subdir1 #end

and

   #if phase2 include subdir2 #end

where the include statement will look for a file with the same
name in the subdirs, e.g. subdir1/testMe.hx and subdir2/testMe.hx
respectively.

Anyone supporting this or is it just unnecessary ? (if so, please
explain...)

--
-Martijn    @..@    ( Martijn Loots       -  Hengelo  [NL] )
-          (`--')   ( martijn<@>cosix.com -  www.cosix.com )
-         ( >__< )  ----------------------------------------
-         ^^^  ^^^  (   Netwerken, Security, Open Source   )

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Another #include proposition

Ian Martins
can you move the code common to phase 1 and 2 into a third directory add
it to the classpaths of both programs (with the -cp compiler option)?

Martijn Loots wrote:

> Hi.
>
> Reading through the mailing archives, I saw that this subject was
> discussed before, but I still like to propose it once more... I'll
> explain why:
>
> My application is based on a 2 step approach (by means of a helper
> script), like:
>
>  Phase 1) handling inputs, filling my data structures and serializing
>           this as haXe code specific for the task at hand
>
>  Phase 2) compile the generated haXe code to create a flash movie
>
>  (next: handover the flash movie to clients).
>
>
> In this scenario, both phase 1) and 2) have large code pieces in
> common (the data structures), while phase 1) specifically targets
> file handling, XML etc. and phase 2) targets flash mainly.
>
> For sake of reducing code size and keeping the code clean, I'd
> would very much like to put the specific code for phase 1) resp.
> phase 2) into different subdirectories, while keeping the common
> part in its own package directory.
>
> In my view, the perfect way to handle this, for example with a
> file like 'testMe.hx':
>
>   #if phase1 include subdir1 #end
>
> and
>
>   #if phase2 include subdir2 #end
>
> where the include statement will look for a file with the same
> name in the subdirs, e.g. subdir1/testMe.hx and subdir2/testMe.hx
> respectively.
>
> Anyone supporting this or is it just unnecessary ? (if so, please
> explain...)
>



--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Another #include proposition

Robin Palotai
In reply to this post by Martijn Loots
Don't really get what you want to do. If this wants to be something
like C# partial classes, where you generate one part of the class, and
generate/manually write an other, then you could achieve quite the
same by subclassing.

Put the common code in a class in a package, then just subclass that
class with the custom/generated code.

Robin

On Tue, Apr 14, 2009 at 4:43 PM, Martijn Loots <[hidden email]> wrote:

> Hi.
>
> Reading through the mailing archives, I saw that this subject was
> discussed before, but I still like to propose it once more... I'll explain
> why:
>
> My application is based on a 2 step approach (by means of a helper
> script), like:
>
>  Phase 1) handling inputs, filling my data structures and serializing
>          this as haXe code specific for the task at hand
>
>  Phase 2) compile the generated haXe code to create a flash movie
>
>  (next: handover the flash movie to clients).
>
>
> In this scenario, both phase 1) and 2) have large code pieces in
> common (the data structures), while phase 1) specifically targets
> file handling, XML etc. and phase 2) targets flash mainly.
>
> For sake of reducing code size and keeping the code clean, I'd
> would very much like to put the specific code for phase 1) resp.
> phase 2) into different subdirectories, while keeping the common
> part in its own package directory.
>
> In my view, the perfect way to handle this, for example with a
> file like 'testMe.hx':
>
>  #if phase1 include subdir1 #end
>
> and
>
>  #if phase2 include subdir2 #end
>
> where the include statement will look for a file with the same
> name in the subdirs, e.g. subdir1/testMe.hx and subdir2/testMe.hx
> respectively.
>
> Anyone supporting this or is it just unnecessary ? (if so, please
> explain...)
>
> --
> -Martijn    @..@    ( Martijn Loots       -  Hengelo  [NL] )
> -          (`--')   ( martijn<@>cosix.com -  www.cosix.com )
> -         ( >__< )  ----------------------------------------
> -         ^^^  ^^^  (   Netwerken, Security, Open Source   )
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Another #include proposition

Martijn Loots
On Tue, 14 Apr 2009, Robin Palotai wrote:

> Don't really get what you want to do. If this wants to be something
> like C# partial classes, where you generate one part of the class, and
> generate/manually write an other, then you could achieve quite the
> same by subclassing.
>
> Put the common code in a class in a package, then just subclass that
> class with the custom/generated code.
>
See, that's what I mean... I'm a bit 'rusty' in OO and more familiar
with procedural programming. I will consider this, as it really seems
to tick all the boxes and more...

Thanks.

--
-Martijn    @..@    ( Martijn Loots       -  Hengelo  [NL] )
-          (`--')   ( martijn<@>cosix.com -  www.cosix.com )
-         ( >__< )  ----------------------------------------
-         ^^^  ^^^  (   Netwerken, Security, Open Source   )

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Another #include proposition

Kostas Michalopoulos
In reply to this post by Martijn Loots
I think you can use GNU C Preprocessor (cpp) manually to preprocess .hx
files.

http://gcc.gnu.org/onlinedocs/cpp/

--------------------------------------------------
From: "Martijn Loots" <[hidden email]>
Sent: Tuesday, April 14, 2009 5:43 PM
To: "The haXe compiler list" <[hidden email]>
Subject: [haXe] Another #include proposition

> Hi.
>
> Reading through the mailing archives, I saw that this subject was
> discussed before, but I still like to propose it once more... I'll explain
> why:
>
> My application is based on a 2 step approach (by means of a helper
> script), like:
>
>  Phase 1) handling inputs, filling my data structures and serializing
>           this as haXe code specific for the task at hand
>
>  Phase 2) compile the generated haXe code to create a flash movie
>
>  (next: handover the flash movie to clients).
>
>
> In this scenario, both phase 1) and 2) have large code pieces in
> common (the data structures), while phase 1) specifically targets
> file handling, XML etc. and phase 2) targets flash mainly.
>
> For sake of reducing code size and keeping the code clean, I'd
> would very much like to put the specific code for phase 1) resp.
> phase 2) into different subdirectories, while keeping the common
> part in its own package directory.
>
> In my view, the perfect way to handle this, for example with a
> file like 'testMe.hx':
>
>   #if phase1 include subdir1 #end
>
> and
>
>   #if phase2 include subdir2 #end
>
> where the include statement will look for a file with the same
> name in the subdirs, e.g. subdir1/testMe.hx and subdir2/testMe.hx
> respectively.
>
> Anyone supporting this or is it just unnecessary ? (if so, please
> explain...)
>
> --
> -Martijn    @..@    ( Martijn Loots       -  Hengelo  [NL] )
> -          (`--')   ( martijn<@>cosix.com -  www.cosix.com )
> -         ( >__< )  ----------------------------------------
> -         ^^^  ^^^  (   Netwerken, Security, Open Source   )
>
> --
> haXe - an open source web programming language
> http://haxe.org 


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Another #include proposition

Martijn Loots
On Tue, 14 Apr 2009, Kostas Michalopoulos wrote:

> I think you can use GNU C Preprocessor (cpp) manually to preprocess .hx
> files.
>
Yes, thought about that too. Using Linux or MacOSX that would be
the natural thing to do and I would not have even asked the question,
but I'm developing on Windows right now...

I think Robin Palotai's class/subclass solution is more appropriate.

Robins "correct" OO approach did not come into my mind when I asked
the question, but in the end, it's so much cleaner.

--
-Martijn    @..@    ( Martijn Loots       -  Hengelo  [NL] )
-          (`--')   ( martijn<@>cosix.com -  www.cosix.com )
-         ( >__< )  ----------------------------------------
-         ^^^  ^^^  (   Netwerken, Security, Open Source   )

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Another #include proposition

edA-qa mort-ora-y
In reply to this post by Martijn Loots
haXe supports the #line directive (at least partially) which means any
preprocessor (such as M4 or CPP) can be used.

In fact the entire DHLIB project uses M4 are a preprocessor which allows
any number of includes, macros, etc.

I have a standard m4haxe script which makes it easy by enabling some
default settings, include directories, and other things.  Once using
this you can easily do your #include, in M4 this looks like
        include(otherfile.ihx)

"ihx" is the extension I use to note an included M4-haxe file (and mhx
is then the main file)

Since I need DHLIB to work with plain haXe as well the "make" target
simple produces the non-M4Haxe versions of everything.  Which may also
be what you need to handover the code to clients.

The only improvement haXe needs is to support the "filename" argument to
the #line directive.



Martijn Loots wrote:

> Hi.
>
> Reading through the mailing archives, I saw that this subject was
> discussed before, but I still like to propose it once more... I'll
> explain why:
>
> My application is based on a 2 step approach (by means of a helper
> script), like:
>
>  Phase 1) handling inputs, filling my data structures and serializing
>           this as haXe code specific for the task at hand
>
>  Phase 2) compile the generated haXe code to create a flash movie
>
>  (next: handover the flash movie to clients).
>
>
> In this scenario, both phase 1) and 2) have large code pieces in
> common (the data structures), while phase 1) specifically targets
> file handling, XML etc. and phase 2) targets flash mainly.
>
> For sake of reducing code size and keeping the code clean, I'd
> would very much like to put the specific code for phase 1) resp.
> phase 2) into different subdirectories, while keeping the common
> part in its own package directory.
>
> In my view, the perfect way to handle this, for example with a
> file like 'testMe.hx':
>
>   #if phase1 include subdir1 #end
>
> and
>
>   #if phase2 include subdir2 #end
>
> where the include statement will look for a file with the same
> name in the subdirs, e.g. subdir1/testMe.hx and subdir2/testMe.hx
> respectively.
>
> Anyone supporting this or is it just unnecessary ? (if so, please
> explain...)
>

--
edA-qa mort-ora-y
http://disemia.com/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

Have a look in my brain:
        http://brainbrain.eu/
       
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sign: Please digitally sign your emails.
Encrypt: I'm also happy to receive encrypted mail.


--
haXe - an open source web programming language
http://haxe.org

signature.asc (260 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Another #include proposition

edA-qa mort-ora-y
In reply to this post by Martijn Loots
Martijn Loots wrote:
>> I think you can use GNU C Preprocessor (cpp) manually to preprocess
>> .hx files.
> Yes, thought about that too. Using Linux or MacOSX that would be the
> natural thing to do and I would not have even asked the question,
> but I'm developing on Windows right now...

M4 and CPP are both available in the cygwin package, so are thus still
an option for windows.


--
edA-qa mort-ora-y
http://disemia.com/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

Have a look in my brain:
        http://brainbrain.eu/
       
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sign: Please digitally sign your emails.
Encrypt: I'm also happy to receive encrypted mail.


--
haXe - an open source web programming language
http://haxe.org

signature.asc (260 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Another #include proposition

Martijn Loots
On Tue, 14 Apr 2009, edA-qa mort-ora-y wrote:

> Martijn Loots wrote:
>>> I think you can use GNU C Preprocessor (cpp) manually to preprocess
>>> .hx files.
>> Yes, thought about that too. Using Linux or MacOSX that would be the
>> natural thing to do and I would not have even asked the question,
>> but I'm developing on Windows right now...
>
> M4 and CPP are both available in the cygwin package, so are thus still
> an option for windows.
>
M4 seems a bit overkill and I'm an experienced Cygwin user, but I'd
prefer a GnuWin32 version of CPP to be used standalone in a .bat
file ("my own little framework": click (compile), click (observe swf),
edit, etc.).

GnuWin32 publishes the M4 package, but no CPP as far as I can see..

--
-Martijn    @..@    ( Martijn Loots       -  Hengelo  [NL] )
-          (`--')   ( martijn<@>cosix.com -  www.cosix.com )
-         ( >__< )  ----------------------------------------
-         ^^^  ^^^  (   Netwerken, Security, Open Source   )

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Another #include proposition

edA-qa mort-ora-y
Martijn Loots wrote:
> M4 seems a bit overkill and I'm an experienced Cygwin user, but I'd
> prefer a GnuWin32 version of CPP to be used standalone in a .bat
> file ("my own little framework": click (compile), click (observe swf),
> edit, etc.).

Well, you don't need to use every feature of M4, though really there
aren't that many once you really get used to it -- simply includes and
defines.  Most of the functions are just combinations of define and ifdef.

--
edA-qa mort-ora-y
http://disemia.com/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

Have a look in my brain:
        http://brainbrain.eu/
       
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sign: Please digitally sign your emails.
Encrypt: I'm also happy to receive encrypted mail.


--
haXe - an open source web programming language
http://haxe.org

signature.asc (260 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Another #include proposition

Justin Donaldson
It would be nice to have #define for variables/functions in haxe.  With a signal/slot class or any other type of IOC, you want to pass control of a given function to some other class.
it's currently necessary to use some static function to send the original object, function name, and argument so that everything can be handled by the main IOC class (I have a signal/slot class called Haxle).  However, since you can't determine the object or the method name of the calling reference (as you could in javascript, etc),  you'd end up having to specify this every time you signal your IOC handler. for instance:


function someFunction(){
    Haxle.signal(this, here.methodName, [arg1, arg2]);
}

the first two arguments should always be "this", and "here.methodName" in my case, so It would be nice to define an inline closure that calls a helper function (signalFuncGen() for instance) that sets up a function that automatically fills these values in, and just expects the third array variable:

__signal([arg1, arg2]);

would be defined (in the Haxle class) as:

#define __signal = Haxle.signalFuncGen(this, here.methodName);

and then the signalFuncGen would look like:

public static function signalFuncGen(obj:Dynamic, func:String) : Array<Dynamic> -> Void{
   return function(arr:Array<Dynamic>){ Haxle.signal(obj, func, arr);}
}

All that over specification would be shoved under the carpet of the #define-d closure, would only get 'turned on' if you include the relevant Class, and if you are careful with how you handle naming, etc. wouldn't affect anything else.  I would imagine this would be useful for many other types of IOC as well.

Best,
-Justin




On Tue, Apr 14, 2009 at 4:50 PM, edA-qa mort-ora-y <[hidden email]> wrote:
Martijn Loots wrote:
> M4 seems a bit overkill and I'm an experienced Cygwin user, but I'd
> prefer a GnuWin32 version of CPP to be used standalone in a .bat
> file ("my own little framework": click (compile), click (observe swf),
> edit, etc.).

Well, you don't need to use every feature of M4, though really there
aren't that many once you really get used to it -- simply includes and
defines.  Most of the functions are just combinations of define and ifdef.

--
edA-qa mort-ora-y
http://disemia.com/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

Have a look in my brain:
       http://brainbrain.eu/

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sign: Please digitally sign your emails.
Encrypt: I'm also happy to receive encrypted mail.


--
haXe - an open source web programming language
http://haxe.org



--
Justin Donaldson
PhD Candidate, Informatics
Indiana University
http://www.scwn.net
aim: iujjd

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Another #include proposition

Kostas Michalopoulos
In reply to this post by Martijn Loots
> GnuWin32 publishes the M4 package, but no CPP as far as I can see..

It is included with MinGW.
 

--
haXe - an open source web programming language
http://haxe.org